From: Rohit Seth <rohitseth@google.com>
To: Andi Kleen <ak@suse.de>
Cc: Chuck Ebbert <76306.1226@compuserve.com>,
Linus Torvalds <torvalds@osdl.org>, Ingo Molnar <mingo@elte.hu>,
linux-kernel@vger.kernel.org
Subject: Re: [RFC, patch] i386: vgetcpu(), take 2
Date: Wed, 21 Jun 2006 16:18:42 -0700 [thread overview]
Message-ID: <1150931922.6885.72.camel@galaxy.corp.google.com> (raw)
In-Reply-To: <200606220105.18512.ak@suse.de>
On Thu, 2006-06-22 at 01:05 +0200, Andi Kleen wrote:
> On Thursday 22 June 2006 00:59, Rohit Seth wrote:
> > I was thinking of storing it is base address part of the descriptor and
> > then using the memory load to read it in vsyscall. (Keeping the p bit
> > to zero in the descriptor).
>
> I'm still not sure where and for what you want to use this. In user space
> or in kernel space? And what information should be stored in there?
>
Store the kernel virtual pointer in gdt to access pda in (proposed)
vgetcpu in vsyscall. Using this pointer we can easily reach the cpu and
node numbers and any other information that is there in pda. For the
cpu and node numbers this will get rid of the need to do a serializing
operation cpuid.
Does it make any sense?
> > Besides, not having to use the tcache part in the proposed system call
> > seems to just make the interface cleaner.
>
> tcache is still far faster than LSL (which is slower than RDTSCP)
Since we are not using the limits part of the descriptor so lsl will not
be needed. Though an indirect load from gdt page will be made.
-rohit
next prev parent reply other threads:[~2006-06-21 23:19 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-06-21 7:27 [RFC, patch] i386: vgetcpu(), take 2 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 [this message]
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
2006-06-23 12:42 ` [discuss] " Andi Kleen
2006-06-24 2:06 ` Rohit Seth
2006-06-24 8:42 ` Andi Kleen
2006-06-27 1:13 ` Rohit Seth
2006-06-21 12:24 Chuck Ebbert
2006-06-21 17:14 ` Andi Kleen
2006-06-21 17:27 ` Linus Torvalds
2006-06-21 17:50 ` Andi Kleen
2006-06-22 12:23 Chuck Ebbert
2006-06-22 12:44 ` Andi Kleen
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=1150931922.6885.72.camel@galaxy.corp.google.com \
--to=rohitseth@google.com \
--cc=76306.1226@compuserve.com \
--cc=ak@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--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;
as well as URLs for NNTP newsgroup(s).