RFC: Performance Monitor Counters device

[Segher Boessenkool]

Dave Engebretsen wrote:
>
> Segher Boessenkool wrote:
> >
> > David Engebretsen wrote:
>
> > The 64-bit idea is very very nice :)  That'll allow a program to just set
> > the counters at the start of eexecution, and only read them again when it's
> > finished.  Can't get much simpler ;)
>
> Of course this depends on what you are trying to achive.  For profiling
> or when timeslicing the counters, this is not needed generally. If you
> want to just collect a fixed set of values over a long run, it is
> usefull.  This however is not the mode I have generally been finding
> useful.

Well, it's an easy way to see if a change in a program actually did help ;)

Note that the 32-bit (31, actually) counters can already overflow in about
one or two seconds.

> > I don't want to have the profiling buffers in kernel space, as they can very well
> > be bigger than physical memory...  On the other hand, it might be needed for
> > performance (or to avoid races) if doing very fine-grained profiling.  I think
> > I'll just sneak out of this by not allowing so fine-grained stuff ;)
>
> Not sure I follow here - allowing a profiling buffer which is even a
> fraction of total system memory will significantly perturb the data.

Not necessarily, like when counting number of insns completed, or something
like that.  But for most things, yes of course cache effects will be huge
with a profiling buffer >= 10% of L1 cache or so.  Even more so with bigger
buffers.


Cheers,

Segher


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/