it seems that with every new architecture, it get's harder to count/detect via performance monitoring situations when a bus lock occurs.
Older Intel processors supported counting "bus_lock_clocks" using event number 63H or using a offcore response event with specific request type.
With the 3rd generation, event number 63H can only be used for counting cycles "in which the L1D and L2 are locked, due to a UC lock or split lock". Now with Skylake, the event number 63H is degraded to only count cycles "in which the L1D is locked."
I'm wondering why all this counters disappear, since bus locks are a major issue for performance. Do I miss any new possibilities to count or detect bus locks via performance counters on Skylake?
according to the version 19 and earlier of the event list at https://download.01.org/perfmon/ for Skylake core events there should exist an event BUS_LOCK_CLOCKS.BUS_LOCK_DURATION (63H, Umask 0x01). But the event is not mentioned like the other events, it is in the description of LOCK_CYCLES.CACHE_LOCK_DURATION (63H, Umask 0x02). In newer versions of the event list, this comment is gone. The reason might be that it was a copy&paste error, never existed and is consequently removed. Or the event is not properly validated yet by Intel and therefore not released.
Yesterday I tested some umasks on my Skylake and Umasks 0x4 and 0xE0 increment but the counts are far away from any cycle value, e.g. < 10 for a 10 minutes measurement. Umask 0x01 didn't increment at all.
A copy of version 19: https://github.com/TomTheBear/perfmondb/blob/master/SKL/Skylake_core_V19.json