LKML Archive on
help / color / mirror / Atom feed
From: Mikael Pettersson <>
Subject: Re: [PATCH][3/7] perfctr-2.7.2 for 2.6.6-mm2: x86_64
Date: Sat, 15 May 2004 16:44:13 +0200 (MEST)	[thread overview]
Message-ID: <> (raw)

On Sat, 15 May 2004 11:09:11 +0200, Andi Kleen wrote:
>> entail; just look at the horrendous mess that is the P4 performance
>> counter event selector.
>There is no way around that - there are kernel users (like the
>nmi watchdog or oprofile) and kernel users cannot be made dependent 
>on user space modules.

The NMI watchdog uses a simple static mapping. No problem there.

I don't care where oprofile computes its mapping, but clearly
it could be done in user-space at the same time as user-space
chooses which events to monitor.

User-space needs to know about it anyway. For instance, unless
you understand the HW constraints, you may try to enable mutually
exclusive events. Some events may be unconstrained, but you need
to know about the constrained ones before you assign the
unconstrained ones. And user-space must know the mapping anyway
for the RDPMC instruction.

The kernel, in the case of both perfctr and oprofile, needs to be
informed of the mapping, but it has no real reason to compute it
itself -- especially not on a complex machine like the P4.

> Also I think managing of hardware resources is the 
>primary task of a kernel, nothing that should be delegated to user 

In my view, the kernel has three primary responsibilities:
- Control resources that user-space code is prevented from accessing.
- Implement useful well-understood abstractions.
- Task-related synchronization.

The only reason performance-counters must have kernel support
is because the control registers are reserved, and because the
kernel state previously didn't include the counters, so they
weren't context-switched.

We don't put an abstract floating-point module in the kernel,
charging it with choosing x87, 3dnow!, or sse code, and
performing register allocation, do we?
No, we expect user-space to deal with that.

In constrast to well-understood abstractions like file systems
or ethernet drivers, there is no common abstraction of the
performance counters that doesn't hide too much details.
And users need to know those details anyway when they interpret
the counter values. User-space libraries do implement abstractions,
for ease of use, but both they and expert users need low-level
interfaces with direct access to the hardware. And that's what
perfctr provides.


             reply	other threads:[~2004-05-15 14:45 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-05-15 14:44 Mikael Pettersson [this message]
2004-05-15 19:26 ` Andi Kleen
  -- strict thread matches above, loose matches on Subject: below --
2004-05-16  9:58 Mikael Pettersson
2004-05-15 14:42 Mikael Pettersson
2004-05-15 19:16 ` Andi Kleen
2004-05-15 20:40   ` John Reiser
2004-05-15 20:49     ` Andi Kleen
     [not found] <>
2004-05-14 15:14 ` Andi Kleen
2004-05-15  5:37   ` Bryan O'Sullivan
2004-05-15  9:09     ` Andi Kleen
2004-05-16  4:15       ` Bryan O'Sullivan
2004-05-14 14:11 Mikael Pettersson

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \
    --subject='Re: [PATCH][3/7] perfctr-2.7.2 for 2.6.6-mm2: x86_64' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).