Re: [PATCH 3/3] perf latency builtin command

From: Clark Williams
Date: Tue Nov 03 2009 - 17:02:13 EST

On Tue, 3 Nov 2009 20:28:39 +0100
Ingo Molnar <mingo@xxxxxxx> wrote:

> Clark, John,
> I'm wondering whether we could do something perf event based that makes
> 'perf latency' self-sufficient and eliminates the debugfs interface.
> ( We could still merge the first two patches in their current form as
> they are clear improvements in terms of debugfs access within perf -
> so no work is lost and progress is possible. )

Yeah, I figured that the first two patches were improvements. I may
poke around a little more to see if we can factor out some more
duplicate routines.

> Basically hwlat_detector is using stop_machine_run() plus a tight rdtsc
> based loop to sample what is happening in the system. Much of
> hwlat_detector.c deals with getting that information (and parameters)
> back and forth between user space and kernel space.
> Couldnt we move that functionality a bit closer to perf by creating
> special events in a tight loop that generate a stream of perf events,
> and let the rest of perf events take over the details, and do the
> analysis in the user-space builtin-latency.c code?
> Also, do we need stop_machine_run() - couldnt we do the measurement on a
> specific CPU with irqs (and NMIs) disabled [but other CPUs still
> running]?

So what would the source of the event's be and how confident would we
be that they're accurate? Jon used stop_machine() so that *nothing*
under the control of Linux is going to happen during the test; no
C-state changes, no interrupts, nada. The intent is that if there's a
gap seen in the TSC values, it's because something happened that's out
of our control.

> This would all still be possible in the .33 timeframe i suspect, as what
> we need is really just a special event (via TRACE_EVENT() perhaps), and
> a way to trigger it via a 'run this many times' parameter. (i.e. event
> injection - we want to have that kind of support in perf events anyway)

Hmmm, seems like what you're saying is that we'd poll a free running
perf counter (or some equivalent, still learning about the guts of perf
event system), detect a gap at the low level and just send an event
with that info up to user-space? That would work...

What counter(s) would we use for detecting a gap in time?

> This would simplify and standardize hw-latency detection, without losing
> any utility - and we wouldnt have to go via some special debugfs
> interface to access the hwlat_detect module.
> Thoughts?

As long as we feel confident that we can detect temporal gaps with a
performance counter, I'd be ok with it.


Attachment: signature.asc
Description: PGP signature