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

From: Andrew Morton (akpm_at_osdl.org)
Date: 05/16/04

  • Next message: Steven Cole: "Re: 1352 NUL bytes at the end of a page? (was Re: Assertion `s && s->tree' failed: The saga continues.)" 
    Date:	Sat, 15 May 2004 22:39:37 -0700
To: Mikael Pettersson <mikpe@csd.uu.se>

    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.
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  • Next message: Steven Cole: "Re: 1352 NUL bytes at the end of a page? (was Re: Assertion `s && s->tree' failed: The saga continues.)"