On Fri, Jul 25, 2014 at 05:45:15PM +0200, Frederic Weisbecker wrote: > On Fri, Jul 25, 2014 at 11:14:13AM -0300, Arnaldo Carvalho de Melo wrote: > > Em Fri, Jul 25, 2014 at 01:34:26PM +0200, Jiri Olsa escreveu: > > > On Thu, Jul 24, 2014 at 06:34:51PM -0300, Arnaldo Carvalho de Melo wrote: > > > > I think both changes are OK, but should be split in different patches, > > > > > right, I'll split it > > > > Thanks! > > > > > > [root@zoo /]# perf stat -r 5 perf report --no-ordered-samples > > > > > /dev/null > > > > 101,171,572,553 instructions # 1.10 insns per > > > > cycle > > > > 30.249514999 seconds time elapsed > > > > ( +- 0.48% ) > > > > > > [root@zoo /]# perf stat -r 5 perf report --ordered-samples > /dev/null > > > > 105,982,144,263 instructions # 1.04 insns per > > > > cycle > > > > 32.636483981 seconds time elapsed > > > > ( +- 0.41% ) > > > > > so those 2 extra seconds is the ordering time, right? sounds ok > > > > Yeah, but I think its worth investigating if using it is a strict > > requirement in all cases, i.e. is it possible to receive out of order > > events when sampling on a single CPU? Or a single CPU socket with a > > coherent time source? etc. > > It's theoretically possible to have out of order events if perf_event_output() > is interrupted between perf_prepare_sample() and perf_output_begin() and the > irq > generates an event too. > > So the first event saves its timestamp "t1" from perf_prepare_sample(), gets > interrupted > before perf_output_begin() so it hasn't reserved room in the ring buffer yet. > The > irq generates an event with a timestamp t2 that can be t2 > t1 if the clock > has a > high enough resolution (tsc works there). > > The IRQ write the event in the buffer, returns to the interrupted event which > record after the irq event. > > One possibility to solve this is to fetch perf_clock() only from > perf_output_sample(). > At that time the event has reserved the buffer space so any irq event is > guaranteed > to be written _after_ the interrupted event and thus guarantees some > monotonicity.
No, I think the current code is correct in that t1 actually happens before t2. They end up in the buffer in reverse order but that's unavoidable. Artificially fixing that up doesn't make sense.
pgpyYLcuVlVYg.pgp
Description: PGP signature
