Peter Zijlstra <[email protected]> writes: > On Tue, Jun 19, 2018 at 01:47:25PM +0300, Alexander Shishkin wrote: >> On Thu, Jun 14, 2018 at 10:20:22PM +0200, Peter Zijlstra wrote: > >> > More yuck... >> > >> > You rreally should not be calling these pmu::methods, they're meant to >> > be used from _interrupt_ not NMI context. Using them like this is asking >> > for tons of trouble. >> >> Right, the SW stuff may then race with event_function_call() stuff. Hmm. >> For the HW stuff, I'm hoping that some kind of a sleight of hand may >> suffice. Let me think some more. > > I currently don't see how the SW driven snapshot can ever work, see my > comment on the last patch.
Unless we explicitly break clone when PERF_SAMPLE_AUX is set. Basically, if you're asking for AUX samples, full perf context switch is not your biggest performance penalty. >> > Why can't you just snapshot the current location and let the thing >> > 'run' ? >> >> Because the buffer will overwrite itself and the location will be useless. > > Not if it's large enough ;-) > >> We don't write the AUX data out in this 'mode' at all, only the samples, >> which allows for much less data in the resulting perf.data, less work for >> the consumer, less IO bandwidth etc, and as a bonus, no AUX-related >> interrupts. >> >> But actually, even to snapshot the location we need to stop the event. > > Maybe new methods that should only be called from NMI context? True. Ideally, the existing ->start()/->stop()/interrupt should already do all necessary internal bookkeeping. Regards, -- Alex
