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 15:59:11 -0700 [thread overview]
Message-ID: <1150930751.6885.61.camel@galaxy.corp.google.com> (raw)
In-Reply-To: <200606220021.21657.ak@suse.de>
On Thu, 2006-06-22 at 00:21 +0200, Andi Kleen wrote:
> > Can we use similar mechanism to access pda in vsyscall in x86_64 (by
> > storing the address of pda there).
>
>
> You mean in the kernel? %gs prefix is a lot faster than this.
>
Yes it is. And will work if we are okay to swap to kernel gs in
vsyscall code.
> Also the limit is only 20bit, not enough for a full address.
>
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).
> For user space it's useful though, but I don't see any immediate uses
> other than cpu number and node number. For most purposes glibc TLS
> (which uses %fs) is probably sufficient.
cpu and node number are really important (for the reasons that you
mentioned in your initial mail on vgetcpu). In addition to that I was
thinking in terms of having some counters like nmi_count that is already
there and per cpu specific.
Besides, not having to use the tcache part in the proposed system call
seems to just make the interface cleaner.
-rohit
next prev parent reply other threads:[~2006-06-21 22:59 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 [this message]
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
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
-- strict thread matches above, loose matches on Subject: below --
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=1150930751.6885.61.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.