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]

Message-ID: <18825.29238.559809.341658@cargo.ozlabs.ibm.com>
Date:	Wed, 4 Feb 2009 21:47:18 +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:

> How is smp_call_function() going to help here? You still need to pull
> all that data through that one FD. That's a cacheline bounce fest.

Well, let's put this into perspective.  We would be collecting 8 bytes
of data from each CPU.  Hardly a "cacheline bounce fest". :)

> Why not collect all this data with per-cpu threads and post-process in
> user-space. The processing might even be capable of doing per-cpu
> filtering, reducing the amount of data that needs to be merged.
> 
> No way that's better done in the kernel.

Not quite sure why you think there's an enormous volume of data to be
managed...

> > > 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.
> 
> Well, you need to at least stop/start the cpu to be hot-(un)plugged, no
> way around that.

It might be worth having the kernel do that automatically, given that
the perfcounters code already has a hotplug notifier routine.
However, I don't think this point is worth debating until we have a
more concrete proposal.

> > 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.
> 
> Userspace already has that control, you don't have to read the counter
> before you get SIGCHLD.
> 
> I'm not seeing how an ioctl will help here, or did you mean a toggle
> between:
>   - collect the full hierarchy
>   - read the currently collected data and don't bother with the
>     active kids

No, I meant an operation that syncs up all the child counters to the
parent so that a subsequent read of the counter immediately afterwards
will get a full total (just by reading the parent counter).  But it
could be implemented as a toggle instead.

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/