mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Andi Kleen <ak@suse.de>
To: Nicholas Miell <nmiell@comcast.net>
Cc: Andi Kleen <ak@suse.de>, Stephane Eranian <eranian@hpl.hp.com>,
	Ray Bryant <raybry@mpdtxmail.amd.com>,
	discuss@x86-64.org, linux-kernel@vger.kernel.org,
	perfctr-devel@lists.sourceforge.net
Subject: Re: [Perfctr-devel] Re: Enabling RDPMC in user space by default
Date: Tue, 29 Nov 2005 23:43:47 +0100	[thread overview]
Message-ID: <20051129224346.GS19515@wotan.suse.de> (raw)
In-Reply-To: <1133303615.3271.12.camel@entropy>

> I think you really need to come up with a better justification than "I
> think this will be useful" for a permanent user-space ABI change.

There's no user space ABI change involved, at least not from
the kernel side. Hardware is breaking some assumptions people
made though (they actually never worked fully, but these days they
break more clearly) and this is a best effort to adapt.

To give an bad analogy RDTSC usage in the last years is
like explicit spinning wait loops for delays in the earlier
times. They tended to work on some subset of computers,
but were always bad and caused problems and people eventually learned
it was better to use operating system services for this.

The kernel will probably not disable RDTSC outright,
but will make it clear in documentation that it's a bad
idea to use directly and laugh at everybody who runs
into problems with it.

oprofile usage might change slightly though, although only
for a small subset of its users. There can't be very many
of them using multiple performance counters anyways because
at least in the last 0.9 release I tried it didn't even work.

> What problem are you trying to solve, why is that a problem, how does
> making PMC0 always be a cycle counter solve that, what makes you think

Read the original messages in the thread. They explain it all.

> that future CPUs will have the same type of cycle counter that behaves
> the same way as the current cycle counters, etc.
> 
> AFAICT, the problem you're trying to solve is two-fold:
> 
> a) RDTSC is serializing and RDPMC isn't.
> 
> Which is nicely solved by RDTSCP.

No, you got that totally wrong. Please read the RDTSCP specification again.

> and
> b) RDTSC isn't well defined.

It's well defined - but in a way that makes it useless for cycle
measurements these days.

> 
> Well, RDPMC isn't defined at all. You're assuming that future processor
> revisions will have the same or substantially similar PerfCtrs as
> current processors, and nothing guarantees that at all.

Point, but i guess it is reasonable to assume that future x85 CPUs
will have cycle counter perfctrs.  I cannot imagine anybody dropping
such a basic facility.

-Andi


  reply	other threads:[~2005-11-29 22:43 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-11-29 15:15 Andi Kleen
2005-11-29 16:04 ` Mikael Pettersson
2005-11-29 16:17   ` Andi Kleen
2005-11-29 16:56 ` Ray Bryant
2005-11-29 16:15   ` Andi Kleen
2005-11-29 18:09   ` [Perfctr-devel] " Stephane Eranian
2005-11-29 18:13     ` Andi Kleen
2005-11-29 18:29       ` John Reiser
2005-11-29 18:38         ` Andi Kleen
2005-11-29 19:05         ` Lee Revell
2005-11-29 21:43       ` Nicholas Miell
2005-11-29 21:52         ` Andi Kleen
2005-11-29 22:19           ` Stephane Eranian
2005-11-29 22:51             ` [discuss] " Andi Kleen
2005-11-30 16:01               ` Stephane Eranian
2005-11-30 16:23                 ` Andi Kleen
2005-12-01 23:41                   ` Stephane Eranian
2005-12-02  0:07                     ` Andi Kleen
2005-12-02  7:09                       ` Stephane Eranian
2005-12-02 11:36                         ` Andi Kleen
2005-11-29 22:33           ` Nicholas Miell
2005-11-29 22:43             ` Andi Kleen [this message]
2005-11-29 23:02               ` Nicholas Miell
2005-11-29 23:17                 ` Andi Kleen
2005-11-29 23:29                   ` Nicholas Miell
2005-11-29 23:39                     ` Andi Kleen
2005-11-29 23:56                       ` David Gibson
2005-11-30  0:34                         ` Andi Kleen
2005-11-30  0:52                           ` David Gibson
2005-11-30  1:04                             ` [discuss] " Andi Kleen
2005-11-30  0:50                       ` Ray Bryant
2005-11-30  0:38                         ` Andi Kleen
2005-11-30  7:38                     ` Stephane Eranian
2005-11-30  8:22                       ` Nicholas Miell
2005-11-30 15:48                         ` Stephane Eranian
2005-11-29 23:07               ` David Gibson
2005-11-29 23:18                 ` [discuss] " Andi Kleen
2005-11-29 23:28               ` Bernd Schmidt
2005-11-29 23:46                 ` [discuss] " Andi Kleen
2005-11-30  2:39 ` Zwane Mwaikambo
2005-11-30  3:38   ` Andi Kleen
2005-12-01  4:08     ` Zwane Mwaikambo
2005-12-01 13:05       ` Andi Kleen
2005-12-01 17:01         ` Zwane Mwaikambo

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=20051129224346.GS19515@wotan.suse.de \
    --to=ak@suse.de \
    --cc=discuss@x86-64.org \
    --cc=eranian@hpl.hp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nmiell@comcast.net \
    --cc=perfctr-devel@lists.sourceforge.net \
    --cc=raybry@mpdtxmail.amd.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

all inboxes | Powered by JetHome®