Re: [PATCH][1/7] perfctr-2.7.2 for 2.6.6-mm2: core

[Andrew Morton <akpm@osdl.org>]

Mikael Pettersson <mikpe@csd.uu.se> wrote:
>
>  The per-process perfctrs used to be accessed via /proc/pid/perfctr,
>  but the /proc/pid/-now-denotes-that-posixy-process-grop-thingy
>  change in 2.6 broke that, so I went away from /proc/pid/ last year.
> 
>  The per-process perfctrs would need their own file system mount point,
>  with files or directories named by actual kernel task id. readdir()
>  won't be fun to implement. The top-level access point can certainly
>  be in a special fs, the question is whether I must go further and
>  do that also for the individual control data fields?
> 
>  The global-mode perfctrs could be accessed via /dev/cpu/$cpu/gperfctr
>  for per-cpu operations, and /dev/cpu/gperfctr/$file for global
>  operations (like start and stop). However, global-mode perfctrs
>  are considerably less important than per-process perfctrs, and
>  I'd rather remove them until the per-process stuff is done.

Well standing back and squinting at the problem:

As it collects samples globally, oprofile is a system-wide thing.  And a
filesytem is a system-wide thing too, so one maps onto the other nicely.

But perfctr is a *per process* thing, and that doesn't map onto a
filesystem abstraction very well at all.

So unless someone comes up with a cunning way of getting your square peg
into a filesystem's round hole, I'd be inclined to stick with a syscall
interface.  Six syscalls would be preferable to
one-which-contains-a-switch-statement, please.



Enabling perfctr is an unprivileged operation, yes?  So if there are
security holes in your code then this exposes the entire system.  That sets
the bar pretty high.