Linux-kernel mailing list archive 1997-47,: Re: [hardcntr] Harware counter per process support

# Re: [hardcntr] Harware counter per process support

David Mentre (David.Mentre@irisa.fr)
27 Nov 1997 18:18:23 +0100

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Meino Christian Cramer: "joystick driver ...---... ...---... ...---... ...---... ...---..."
- Previous message: Alan Cox: "Re: Bunch of OOPSen in 2.1.65"
- In reply to: Dean Gaudet: "Re: [patch][x86][hardcntr] Harware counter per process support"
- Next in thread: David Mentre: "Re: [hardcntr] Harware counter per process support"
- Reply: David Mentre: "Re: [hardcntr] Harware counter per process support"

Hi Dean, Jakub, Pavel, and the other linux hackers,

Thanks for your comments. It is clear (at least for me ;) that my first
patch was an *attempt* to gather comments and provide improved patch
later.

A few comments:

1. Regarding functionality

a. I'll try to provide support for multi-architecture support
(UltraSparc, Alpha, PPC) and multi-model support (for x86 clones).

b. I'll add a time stamp counter (Dean Gaudet).

c. I also would like to support counters trought clone()/fork(). Any
idea of the Right semantic (copy or reset in cloned task, add to father
on exit) ?

2. Regarding implementation

a. I haven't measured overhead yet (to reply to Pavel Machek). I'll do
it when the patch will be more "clean".

b. I'll implement counter overflow (specially needed for Alphas
limited to 14 or 16 bits counters) (Dean request).

c. I'll try to implement more lazy setting of counters (idea of Dean
Gaudet), if it's possible. BTW, Dean, I have not understand your
code. It seems that you set the counters to the "prev" task settings,
not the "next" settings. I must admit that I'm quite confused. Could you
explain to me your idea in private.

3. Regarding the interface

I'm open to any idea. A syscall (like ptrace as suggested by Jakub
Jelinek) would far more easier to implement, with far less overhead. My
main problem is that I do not know Linus point of view. Would he agree
on such an interface ? And as nobody in the Core Linux Team(tm) seems to
be interested in such a subject, I'm limited to code&critics
development cycle. ;)

4. Regarding userland programs

a. Of course, a multi-architecture library should be provided to deal
with the raw kernel interface.

b. I'm open to any interface with user programs (profiler,
debugger). In fact, I have my own interest in such a subject (monitor my
own programs overhead). It would be nice to have an utility which gives
for a given program the data_miss per source line (hint, hint ;).

To conclude, I'll try to provide an improved patch in a few weeks. I
won't be only next week so don't expect a quick update. I'm still open
to any comment.

Regards,
d.

    --
     David.Mentre@irisa.fr -- CAPS research team - Irisa - France
          Personal info: http://www.irisa.fr/prive/mentre/
      Professional info: http://www.irisa.fr/caps/PEOPLE/David/

- Next message: Meino Christian Cramer: "joystick driver ...---... ...---... ...---... ...---... ...---..."
- Previous message: Alan Cox: "Re: Bunch of OOPSen in 2.1.65"
- In reply to: Dean Gaudet: "Re: [patch][x86][hardcntr] Harware counter per process support"
- Next in thread: David Mentre: "Re: [hardcntr] Harware counter per process support"
- Reply: David Mentre: "Re: [hardcntr] Harware counter per process support"