linux-kernel - Re: [patch 23/24] perfmon: kernel documentation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 26 Nov 2008 20:34:30 +0100
From:	Andi Kleen <andi@...stfloor.org>
To:	eranian@...il.com
Cc:	Andi Kleen <andi@...stfloor.org>, linux-kernel@...r.kernel.org,
	akpm@...ux-foundation.org, mingo@...e.hu, x86@...nel.org,
	sfr@...b.auug.org.au
Subject: Re: [patch 23/24] perfmon: kernel documentation

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@...stfloor.org> wrote:
> > On Wed, Nov 26, 2008 at 12:43:00AM -0800, eranian@...glemail.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@...ux.intel.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/