From: Philip Mucci <mucci@cs.utk.edu>
To: Nigel Stephens <nigel@mips.com>
Cc: Linux-mips@linux-mips.org, perfmon@napali.hpl.hp.com,
Stephane Eranian <eranian@hpl.hp.com>
Subject: Re: 2.6.13-rc2 perfmon2 new code base with MIPS5K/20K support + libpfm available
Date: Thu, 19 Jan 2006 16:41:54 +0100 [thread overview]
Message-ID: <1137685314.6648.188.camel@localhost.localdomain> (raw)
In-Reply-To: <43CFB130.7000105@mips.com>
Hi Nigel,
There is a much more detailed discussion to be found on the perfctr
mailing list...we all worked through that when deciding on perfmon. I
have been a big advocate in the past for perfctr especially since it
played such an important part of the PAPI work. But in a nutshell:
- kernel level event multiplexing
- buffered IP sampling and profiling
- remote (third party) monitoring
- support for event address features through sampling like IA64, PIV and
PPC64 support
- support for randomization
To name the most important ones...
Stefane has worked with us, and Mikael P, to make sure that perfmon
provides everything that Perfctr did...one notable addition was support
for mmaped counters where you can read the full 64 bit quantity in user
mode...Not possible on MIPS64 though...darn privileged mfc
instructions...that's avail on the 10/12/14K and probably others of the
MIPS line...
Check this link:
http://sourceforge.net/mailarchive/message.php?msg_id=12829209
Regards,
Phil
On Thu, 2006-01-19 at 15:33 +0000, Nigel Stephens wrote:
>
> Philip Mucci wrote:
>
> >perfmon is intended up be used for performance tuning in production
> >multiprogrammed environments, although it also has system-wide and
> >per-cpu counting modes. So you can have multiple people using the
> >counters inside their processes and threads and all the counts are
> >preserved as the state and the full 64 bit values are part of the
> >process context, for the per-thread monitoring modes.
> >
> >
>
> How does perfmon differ from the perfctr project, which seems to be
> doing something very similar? See http://user.it.uu.se/~mikpe/linux/perfctr/
>
> >
> >
> >Anyways, glad to hear other folks are as interested in performance
> >analysis!
> >
> >
> >
>
> We most definitely are, in particular we are looking for good tools with
> which to analyse threaded applications running on multi-threading
> hardware. Does this version of perfmon support threaded code?
>
> Nigel
next prev parent reply other threads:[~2006-01-19 15:38 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-01-19 10:30 2.6.13-rc2 perfmon2 new code base with MIPS5K/20K support + libpfm available Philip Mucci
2006-01-19 13:36 ` Ralf Baechle
2006-01-19 14:04 ` Philip Mucci
2006-01-19 15:33 ` Nigel Stephens
2006-01-19 15:41 ` Philip Mucci [this message]
2006-01-19 18:16 ` Stephane Eranian
2006-01-19 18:38 ` [perfmon] " Philip Mucci
2006-01-19 19:14 ` Stephane Eranian
2006-01-19 19:30 ` Philip Mucci
2006-01-19 19:59 ` Stephane 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=1137685314.6648.188.camel@localhost.localdomain \
--to=mucci@cs.utk.edu \
--cc=Linux-mips@linux-mips.org \
--cc=eranian@hpl.hp.com \
--cc=nigel@mips.com \
--cc=perfmon@napali.hpl.hp.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox