On Thu, Apr 16, 2015 at 02:53:42PM +0200, Peter Zijlstra wrote: > When the PEBS interrupt threshold is larger than one record and the > machine supports multiple PEBS events, the records of these events are > mixed up and we need to demultiplex them. > > Demuxing the records is hard because the hardware is deficient. The > hardware has two issues that, when combined, create impossible scenarios > to demux. > > The first issue is that the 'status' field of the PEBS record is a copy > of the GLOBAL_STATUS MSR at PEBS assist time. To see why this is a > problem let us first describe the regular PEBS cycle: > > A) the CTRn value reaches 0: > - the corresponding bit in GLOBAL_STATUS gets set > - we start arming the hardware assist > > < some unspecified amount of time later -- > this could cover multiple events of interest > > > B) the hardware assist is armed, any next event will trigger it > > C) a matching event happens: > - the hardware assist triggers and generates a PEBS record > this includes a copy of GLOBAL_STATUS at this moment > - if we auto-reload we (re)set CTRn
Is this actually true? Do we reload here or on A ? > - we clear the relevant bit in GLOBAL_STATUS -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
