From: Andi Kleen <andi@firstfloor.org>
To: eranian@gmail.com
Cc: Andi Kleen <andi@firstfloor.org>,
linux-kernel@vger.kernel.org, akpm@linux-foundation.org,
mingo@elte.hu, x86@kernel.org, sfr@canb.auug.org.au
Subject: Re: [patch 23/24] perfmon: kernel documentation
Date: Wed, 26 Nov 2008 20:34:30 +0100 [thread overview]
Message-ID: <20081126193429.GC6703@one.firstfloor.org> (raw)
In-Reply-To: <7c86c4470811261021t5a7da650w95c30a71838172c4@mail.gmail.com>
On Wed, Nov 26, 2008 at 07:21:56PM +0100, stephane eranian wrote:
> Andi,
>
> On Wed, Nov 26, 2008 at 1:21 PM, Andi Kleen <andi@firstfloor.org> wrote:
> > On Wed, Nov 26, 2008 at 12:43:00AM -0800, eranian@googlemail.com wrote:
> >
> > I assume you'll be also submitting manpages with the same information?
> >
> This is on my TODO list. Provide a man page for each new syscall.
There should be a overview manpage as well.
> I have never played with that myself, even with regular file
> descriptors. But I can only
> assume passing a file descriptor increments its refcount. Thus you
> simply get another
> controlling process. There is enough context locking in place in the
> kernel to make this
> work.
Ok as long as it isn't a root hole or similar.
> > ...
> >
> > Some simple syscall examples would be nice. e.g. how to set up a counter
> > that it can be accessed using RDPMC on x86.
>
> I can add this. But why go straight to RDPMC. Most people would want to use
> the syscall instead?
On recent Intel x86 a common simple useful case is to just use RDPMC
with one of the fixed counters, especially the unscaled cycle counter.
The only change needed here is to set the CR bit.
> > to let a driver patch for that adjust it.
> >
> It depends on the number of registers available. It is expected that most tools
> will want to use one call to program the config registers and one to program
> the data registers. Pfmon is able to split vectors according to arg_mem_max.
>
> It is anticipated that newer processors will increase the number of available
> PMU registers. That was the case with Barcelona with the addition of IBS.
> On Intel X86, I am planning on exposing the LBR as part of the PMU registers.
>
> On Itanium, you already have 35 data and 27 config registers.
That is still far less than a 4K page. Also 4K worth of registers would
be a lot. I doubt that will be hit anytime soon.
>
> But I think your suggestion is interesting. When we "register" the new PMU
> mapping table, we can provide a minimal size to fit all PMC or all PMD registers
> in one call. That would remove a control point for the sysadmin, though.
I don't think the sysadmin wants to really know about that.
-Andi
>
--
ak@linux.intel.com
next prev parent reply other threads:[~2008-11-26 19:24 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-26 8:43 [patch 23/24] perfmon: kernel documentation eranian
2008-11-26 12:21 ` Andi Kleen
2008-11-26 16:41 ` Randy Dunlap
2008-11-26 17:00 ` Andi Kleen
2008-11-26 18:21 ` stephane eranian
2008-11-26 19:34 ` Andi Kleen [this message]
2008-11-26 20:24 ` stephane eranian
2008-11-26 20:56 ` Andi Kleen
-- strict thread matches above, loose matches on Subject: below --
2008-11-25 21:36 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=20081126193429.GC6703@one.firstfloor.org \
--to=andi@firstfloor.org \
--cc=akpm@linux-foundation.org \
--cc=eranian@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=sfr@canb.auug.org.au \
--cc=x86@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