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

[Clark Williams <williams@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 2673 bytes --]

On Tue, 3 Nov 2009 20:28:39 +0100
Ingo Molnar <mingo@elte.hu> 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. 

Clark



[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]