From: Andi Kleen <andi@firstfloor.org>
To: eranian@googlemail.com
Cc: linux-kernel@vger.kernel.org, akpm@linux-foundation.org,
mingo@elte.hu, x86@kernel.org, andi@firstfloor.org,
eranian@gmail.com, sfr@canb.auug.org.au
Subject: Re: [patch 23/24] perfmon: kernel documentation
Date: Wed, 26 Nov 2008 13:21:07 +0100 [thread overview]
Message-ID: <20081126122107.GV6703@one.firstfloor.org> (raw)
In-Reply-To: <492d0c14.02225e0a.15ab.6f8e@mx.google.com>
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?
> +
> + A monitoring session is uniquely identified by a file descriptor obtained
> + when the session is created. File sharing semantics apply to access the
> + session inside a process. A session is never inherited across fork. The file
> + descriptor can be used to receive counter overflow notifications or when the
> + sampling buffer is full. It is possible to use poll/select on the descriptor
> + to wait for notifications from multiple sessions. Similarly, the descriptor
> + supports asynchronous notifications via SIGIO.
What happens when the fd is passed between processes using unix sockets fd
passing?
> +
> + We have released a simple monitoring tool to demonstrate the features of
> + the interface. The tool is called pfmon and it comes with a simple helper
> + library called libpfm. The library comes with a set of examples to show
I don't think "simple" is the right word to describe pfmon/libpfm @)
> + There maybe other tools available for perfmon.
s/maybe/are/ ?
> +
> + To destroy a session, the regular close() system call is used.
...
Some simple syscall examples would be nice. e.g. how to set up a counter
that it can be accessed using RDPMC on x86.
> + /sys/kernel/perfmon/arg_mem_max(read-write):
> +
> + Maximum size of vector arguments expressed in bytes.
> + It can be modified but must be at least a page.
> + Default: PAGE_SIZE
Is there any good reason ever to enlarge this beyond a page?
If it just depends on future hardware it would make more sense
to let a driver patch for that adjust it.
-Andi
--
ak@linux.intel.com
next prev parent reply other threads:[~2008-11-26 12:10 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 [this message]
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
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=20081126122107.GV6703@one.firstfloor.org \
--to=andi@firstfloor.org \
--cc=akpm@linux-foundation.org \
--cc=eranian@gmail.com \
--cc=eranian@googlemail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.