lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 25 Jul 2014 17:45:15 +0200
From:	Frederic Weisbecker <>
To:	Arnaldo Carvalho de Melo <>
Cc:	Jiri Olsa <>, Jiri Olsa <>,,
	Adrian Hunter <>,
	Corey Ashford <>,
	David Ahern <>,
	Ingo Molnar <>,
	Jean Pihet <>,
	Namhyung Kim <>,
	Paul Mackerras <>,
	Peter Zijlstra <>
Subject: Re: [PATCH 17/19] perf tools: Always force

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.

> Providing a way to disable this ordering to be used in corner cases
> where it is not a strict requirement and the volume of samples is so
> high that reducing processing time like shown above seems to be a
> sensible thing to do.
> We're in the business of optimizing stuff, huh? :-)
> - Arnaldo
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists