From: Stephane Eranian <eranian@hpl.hp.com>
To: Christoph Hellwig <hch@infradead.org>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 03/22] 2.6.22-rc3 perfmon2 : new system calls support
Date: Thu, 31 May 2007 08:46:15 -0700 [thread overview]
Message-ID: <20070531154615.GA23939@frankl.hpl.hp.com> (raw)
In-Reply-To: <20070531152134.GA974@infradead.org>
Christoph,
On Thu, May 31, 2007 at 04:21:34PM +0100, Christoph Hellwig wrote:
> On Tue, May 29, 2007 at 06:48:17AM -0700, Stephane Eranian wrote:
> > sys_pfm_create_context():
> > - create a new perfmon2 context and returns a file descriptor in
> > the pfarg_ctx_t parameters. This is the first call an application
> > must make to do monitoring
> > - rewritten to pass sampling format identification as a string
> > - file descriptor is now returned by call
> >
> > sys_pfm_write_pmcs():
> > - program the PMU configuration registers. Accepts vector of arguments
> > of type pfarg_pmc_t
> >
> > sys_pfm_write_pmds():
> > - program the PMU data registers. Accepts a vector of arguments of type
> > pfarg_pmd_t
> >
> > sys_pfm_read_pmds():
> > - read the PMU data registers. Accepts a vector of arguments of type
> > pfarg_pmd_t
>
> This kind of interface doesn't make any sense at all. Information should
> be read and written from filedescriptors using the read and write family
> syscalls and through the VFS instead of adding tons of system calls.
>
They are all using file descriptors already.
We use read() for receiving overflow notifications. Write is not used.
> I fear we need to write down the requirements first and then come up
> with something better. E.g. for per-task sampling an interface centered
> around a few files in /proc/<pid>/ would fit very nicely:
>
> /proc/<pid>/perfmon_pmcs
> /proc/<pid>/perfmon_pmds
> Obvious
> /proc/<pid>/perfmon_ctl
> Can get control commands as ascii sets written to
>
You don't want to do parsing because usually, when sampling, you have
to reprogram the registers on the fly and this is on the critical path.
Information has to be exchanged in binary format.
--
-Stephane
next prev parent reply other threads:[~2007-05-31 15:58 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-29 13:48 Stephane Eranian
2007-05-31 15:21 ` Christoph Hellwig
2007-05-31 15:46 ` Stephane Eranian [this message]
2007-06-04 14:38 ` David Rientjes
2007-06-05 21:17 ` Stephane Eranian
2007-06-06 1:34 ` David Rientjes
2007-06-06 22:27 ` Stephane Eranian
2007-06-06 22:53 ` David Rientjes
2007-06-07 7:15 ` Stephane Eranian
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=20070531154615.GA23939@frankl.hpl.hp.com \
--to=eranian@hpl.hp.com \
--cc=hch@infradead.org \
--cc=linux-kernel@vger.kernel.org \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®