linux-kernel - Re: Performance counter API review was [patch] Performance Counters for Linux, v3

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Wed, 4 Feb 2009 13:18:12 +1100
From:	Paul Mackerras <paulus@...ba.org>
To:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Cc:	Corey Ashford <cjashfor@...ux.vnet.ibm.com>,
	Andi Kleen <andi@...stfloor.org>, Ingo Molnar <mingo@...e.hu>,
	linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Stephane Eranian <eranian@...glemail.com>,
	Eric Dumazet <dada1@...mosbay.com>,
	Robert Richter <robert.richter@....com>,
	Arjan van de Veen <arjan@...radead.org>,
	Peter Anvin <hpa@...or.com>,
	"David S. Miller" <davem@...emloft.net>,
	Maynard Johnson <mpjohn@...ibm.com>, carll@...ibm.com
Subject: Re: Performance counter API review was [patch] Performance
 Counters for Linux, v3

Peter Zijlstra writes:

> Doing a single fd for all cpus is going to suck chunks because its going
> to be a global serialization point.

If we need statistics for the system as a whole (and we do), then the
serialization is going to happen somewhere - the only question is
whether it's in the kernel or in userspace.  I don't see that it needs
to be a _global_ serialization point in either case.  Given that the
kernel has facilities like smp_call_function() available that
userspace doesn't, I think it will end up cleaner to do it in the
kernel.

That's actually a bit independent of whether it should be accessed via
one fd or multiple fds.  One alternative might be to use something
analogous to the counter group concept we have (i.e. multiple fd's,
but have a way to logically join them together).

By the way, how does userspace get to know about cpus being added or
removed?  Is there a better way than continually reading
/sys/devices/system/cpu/online?

> Also, why would you be profiling while doing a hotplug? Both cpu
> profiling, and hotplug, are administrator operations, just don't do
> that.

Performance counters are also used for counting, which by definition
is something that takes place over a period of time, possibly quite a
long time.  It would be annoying to have to stop counting and start a
new count every time we need to plug or unplug a cpu.

> The inheritance thing will also suffer this issue, if you're going to do
> reads of your fds at any other point than at the end -- it will have to
> walk the whole inheritance tree and sum all the values (or propagate
> interrupts up the tree). Which sounds rather expensive.

I'm planning to make that operation (summing over all children) be
something that userspace can request via an ioctl, so userspace gets
to decide when and how often it's worth the expense of doing it.

Paul.
--
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/