LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Andrew Morton <akpm@osdl.org>
To: Mikael Pettersson <mikpe@csd.uu.se>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH][1/7] perfctr-2.7.2 for 2.6.6-mm2: core
Date: Sat, 15 May 2004 22:39:37 -0700	[thread overview]
Message-ID: <20040515223937.5488a6ae.akpm@osdl.org> (raw)
In-Reply-To: <200405151440.i4FEeVR1001369@harpo.it.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.

  reply	other threads:[~2004-05-16  5:40 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-05-15 14:40 Mikael Pettersson
2004-05-16  5:39 ` Andrew Morton [this message]
  -- strict thread matches above, loose matches on Subject: below --
2004-05-16 11:52 Mikael Pettersson
2004-05-15 14:39 Mikael Pettersson
2004-05-14 14:09 Mikael Pettersson
2004-05-14 14:40 ` Christoph Hellwig
2004-05-14 22:59 ` Andrew Morton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20040515223937.5488a6ae.akpm@osdl.org \
    --to=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mikpe@csd.uu.se \
    --subject='Re: [PATCH][1/7] perfctr-2.7.2 for 2.6.6-mm2: core' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).