linux-kernel - Re: [perfmon] Re: [perfmon2] perfmon2 merge news

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: <20071114141342.GH6557@frankl.hpl.hp.com>
Date:	Wed, 14 Nov 2007 06:13:42 -0800
From:	Stephane Eranian <eranian@....hp.com>
To:	Andi Kleen <andi@...stfloor.org>
Cc:	Christoph Hellwig <hch@...radead.org>,
	Paul Mackerras <paulus@...ba.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Greg KH <gregkh@...e.de>, Philip Mucci <mucci@...utk.edu>,
	William Cohen <wcohen@...hat.com>,
	Robert Richter <robert.richter@....com>,
	linux-kernel@...r.kernel.org, Perfmon <perfmon@...ali.hpl.hp.com>,
	perfmon2-devel@...ts.sourceforge.net,
	OSPAT devel <ospat-devel@...utk.edu>,
	papi list <ptools-perfapi@...utk.edu>
Subject: Re: [perfmon] Re: [perfmon2] perfmon2 merge news

Andi,

On Wed, Nov 14, 2007 at 01:38:38PM +0100, Andi Kleen wrote:
> Christoph Hellwig <hch@...radead.org> writes:
> >
> > I've done this a gazillion times before, so maybe instead of beeing a lazy
> > bastard you could look up mailinglist archive.  It's not like this is the
> > first discussion of perfmon.  But to get start look at the systems calls,
> > many of them are beasts like:
> >
> >   int pfm_read_pmds(int fd, pfarg_pmd_t *pmds, int n)
> >
> > This is basically a read(2) (or for other syscalls a write) on something
> 
> At least for x86 and I suspect some 1other architectures we don't
> initially need a syscall at all for this. There is an instruction
> RDPMC who can read a performance counter just fine. It is also much
> faster and generally preferable for the case where a process measures
> events about itself. In fact it is essential for one of the use cases
> I would like to see perfmon used (replacement of RDTSC for cycle
> counting) 
> 

This only works when counting (not sampling) and only for self-monitoring.

> Later a syscall might be needed with event multiplexing, but that seems
> more like a far away non essential feature.
> 
On a machine with only two generic counters such as MIPS or Intel Core 2 Duo,
multiplexing offers some advantages. If NMI watchdog is enabled, then you drop
to one generic counter on on Core 2.

> > else than the file descriptor provided to the system call.   The right thing
> 
> I don't like read/write for this too much. I think it's better to
> have individual syscalls.  After all that is CPU state and having
> syscalls for that does seem reasonable.

As I said earlier, we do use read(), not for reading counters but to extract overflow
notification messages when we are sampling. It makes more sense for this usage because
this is where you want to leverage some key mechanisms such as:

	 - asynchronous notification via SIGIO. this is how you can implement self-sampling
	   for instance.

	 - select/poll to allow monitoring tools to wait for notification coming from
	   multiple sessions in one call. This is useful when monitoring across fork or
	   pthread_create.

-- 
-Stephane
-
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/