Re: [patch 0/3] [Announcement] Performance Counters for Linux

From: Ingo Molnar
Date: Fri Dec 05 2008 - 03:24:58 EST

* David Miller <davem@xxxxxxxxxxxxx> wrote:

> > > These things aren't measuring time, or even just cycles, they are
> > > measuring things like L2 cache misses, cpu cycles, and other
> > > similar kinds of events.
> > >
> > > So these counters are going to measure all of the damn crap
> > > assosciated with doing the read() call as well as the real work the
> > > task does.
> >
> > that's wrong, look at the example we posted - see it pasted below.
> It's still too simple to be useful.
> There are so many aspects other than the immediate PC that monitoring
> tasks want to inspect when a counter overflows.

fully agreed.

While most of the flat profilers like oprofile will be happy with the PC
alone, i do think we want a couple of extended notification types.

Right now we begun with the most trivial ones:

enum perf_record_type {

... but it would be natural to do a PERF_RECORD_GP_REGISTERS as well.
Perhaps even a PERF_RECORD_STACKTRACE using the sysprof facilities, to do
a hierarchic multi-dimension profile that sysprof does so nicely.

Note that the record type is an independent attribute of a counter. It
can be set regardless of the even type - and it can be set independently
for each counter. So you can have say 3 'simple' counters with no irqs
plus one 'all registers' counter which generates an IRQ: and then you can
read out the simple counters at the same type.

We could also perhaps do a PERF_RECORD_ALL: it represents a snapshot of
all active counter values in the task. This is _far_ better than forcibly
scheduling the monitored task.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at