public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <ak@suse.de>
To: Chuck Ebbert <76306.1226@compuserve.com>
Cc: Ingo Molnar <mingo@elte.hu>, Jakub Jelinek <jakub@redhat.com>,
	Roland McGrath <roland@redhat.com>,
	Ulrich Drepper <drepper@redhat.com>,
	Linus Torvalds <torvalds@osdl.org>,
	linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [RFC, patch] i386: vgetcpu(), take 2
Date: Wed, 21 Jun 2006 19:14:37 +0200	[thread overview]
Message-ID: <200606211914.37137.ak@suse.de> (raw)
In-Reply-To: <200606210828_MC3-1-C30B-9D83@compuserve.com>

On Wednesday 21 June 2006 14:24, Chuck Ebbert wrote:
> In-Reply-To: <20060621081539.GA14227@elte.hu>
> 
> On Wed, 21 Jun 2006 10:15:39 +0200, Ingo Molnar wrote:
> 
> > * Chuck Ebbert <76306.1226@compuserve.com> wrote:
> > 
> > > Use a GDT entry's limit field to store per-cpu data for fast access 
> > > from userspace, and provide a vsyscall to access the current CPU 
> > > number stored there.
> > 
> > very nice idea! I thought of doing sys_get_cpu() too, but my idea was to 
> > use the scheduler to keep a writable [and permanently pinned, 
> > per-thread] VDSO data page uptodate with the current CPU# [and other 
> > interesting data]. Btw., do we know how fast LSL is on modern CPUs?
> 
> Now that the GDT is a full page for each CPU there's plenty of space
> for all kinds of per-cpu data, even if we waste 75% of it.  LSL seems
> pretty fast; I got 13 clocks for the whole lsl/jnz/and sequence on K8

My measurements show different - i get 60+ cycles on K8 and 150+ cycles
on P4. That is with a full vsyscall around it. However it is still
far better than CPUID, however slower than RDTSCP on those CPUs that support it.

I changed the CPUID fallback path to use LSL on x86-64

> and 21 clocks on PII.  Myabe you can test P4?
> 
> /* test how fast lsl/jnz/and runs.
>  */
> #define _GNU_SOURCE
> #include <stdio.h>
> #include <stdlib.h>
> 
> #define rdtscll(t)	asm volatile ("rdtsc" : "=A" (t))
> 
> #ifndef ITERS
> #define ITERS	1000000
> #endif
> 
> int main(int argc, char * const argv[])
> {
> 	unsigned long long tsc1, tsc2;
> 	int count, cpu, junk;
> 
> 	rdtscll(tsc1);
> 	asm (
> 		"	pushl %%ds		\n"
> 		"	popl %2			\n"
> 		"1:				\n"
> #ifdef DO_TEST
> 		"	lsl %2,%0		\n"
> 		"	jnz 2f			\n"
> 		"	and $0xff,%0		\n"
> #endif
> 		"	dec %1			\n"
> 		"	jnz 1b			\n"
> 		"2:				\n"
> 		: "=&r" (cpu), "=&r" (count), "=&r" (junk)
> 		: "1" (ITERS), "0" (-1)
> 	);
> 	rdtscll(tsc2);

Measuring this way is a bad idea because you get far too much 
noise from the RDTSCs. Usually you need to put a a few thousands entry 
loop inside the RDTSCP and devide the result by the loop count

-Andi

> 

  reply	other threads:[~2006-06-21 17:14 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-06-21 12:24 [RFC, patch] i386: vgetcpu(), take 2 Chuck Ebbert
2006-06-21 17:14 ` Andi Kleen [this message]
2006-06-21 17:27   ` Linus Torvalds
2006-06-21 17:50     ` Andi Kleen
  -- strict thread matches above, loose matches on Subject: below --
2006-06-22 12:23 Chuck Ebbert
2006-06-22 12:44 ` Andi Kleen
2006-06-21  7:27 Chuck Ebbert
2006-06-21  8:15 ` Ingo Molnar
2006-06-21 17:38   ` Artur Skawina
2006-06-28  5:44   ` Paul Jackson
2006-06-28  8:53     ` Andi Kleen
2006-06-28  9:00       ` Ingo Molnar
2006-06-29  8:47         ` Paul Jackson
2006-06-21  9:26 ` Andi Kleen
2006-06-21  9:35   ` Ingo Molnar
2006-06-21 21:54   ` Rohit Seth
2006-06-21 22:21     ` Andi Kleen
2006-06-21 22:59       ` Rohit Seth
2006-06-21 23:05         ` Andi Kleen
2006-06-21 23:18           ` Rohit Seth
2006-06-21 23:29             ` Andi Kleen
2006-06-22  0:55               ` Rohit Seth
2006-06-22  8:08                 ` Andi Kleen
2006-06-22 21:06                   ` Rohit Seth
2006-06-22 22:14                     ` Andi Kleen
2006-06-22 23:10                       ` Rohit Seth

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=200606211914.37137.ak@suse.de \
    --to=ak@suse.de \
    --cc=76306.1226@compuserve.com \
    --cc=drepper@redhat.com \
    --cc=jakub@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=roland@redhat.com \
    --cc=torvalds@osdl.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox