On 14/04/16 12:07, Wangnan (F) wrote: > > > On 2016/4/14 16:30, Adrian Hunter wrote: >> On 14/04/16 10:50, Wangnan (F) wrote: >>> >>> On 2016/4/14 15:15, Adrian Hunter wrote: >>>> On 13/04/16 18:55, Arnaldo Carvalho de Melo wrote: >>>>> Em Wed, Apr 13, 2016 at 08:21:06AM +0000, Wang Nan escreveu: >>>>>> auxtrace_snapshot_enable has only two states (0/1). Turns it into a >>>>>> triple states enum so SIGUSR2 handler can safely do other works without >>>>>> triggering auxtrace snapshot. >>>>> Adrian, can you take a look at this? Is it ok with you? >>>> Please forgive me if these are stupid questions: >>>> >>>> First I am wondering why we wouldn't want to snapshot auxtrace data at the >>>> same time as the perf buffer? >>> This patch doesn't prevent taking snapshot when receiving SIGUSR2. >> So it was a stupid question ;-) > > Still thank you for pointing this. I suddenly realized the > 'switch_output_started' > in patch 5/10 is also need to be turned to a 3 state enum. If not, a SIGUSR2 > incorrectly > triggers output switching even '--switch-output' is not provided when > '--snapshot' exist. > >> >>> If both --snapshot and --switch-outupt is provided, when SIGUSR2 received, >>> perf takes auxtrace snapshot and other perf buffer together. >> How do you keep from losing tracking information like MMAP events? Are they >> is a different buffer? > > Please see patch 8/10 and 9/10. MMAP events are resynthesized each time > when output file switched, so at the *head* of each 'perf.data' you can find > many MMAP/COMM/FORK... events.
OK, I see. > > After overwritable ring buffer is supported, there is a more aggresive > patch [1] resynthesize tracking events and put them at the *end* of > perf.data. > > [1] > https://git.kernel.org/cgit/linux/kernel/git/pi3orama/linux.git/commit/?h=perf/overwrite&id=747e10300397b9c28b01bca5bfad943c8cf2dcce > Thanks for the information. Auxtrace really needs complete MMAP information, so I would probably need to look at other options as well. Anyway for this patch: Acked-by: Adrian Hunter <adrian.hun...@intel.com>
