From: Andi Kleen <ak@muc.de>
To: Rusty Russell <rusty@rustcorp.com.au>
Cc: virtualization <virtualization@lists.osdl.org>,
lkml - Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 5/7] Use %gs for per-cpu sections in kernel
Date: 22 Sep 2006 14:32:15 +0200
Date: Fri, 22 Sep 2006 14:32:15 +0200 [thread overview]
Message-ID: <20060922123215.GA98728@muc.de> (raw)
In-Reply-To: <1158926386.26261.17.camel@localhost.localdomain>
BTW I changed my copy sorry. I redid the early PDA support
to not be in assembler.
On Fri, Sep 22, 2006 at 09:59:45PM +1000, Rusty Russell wrote:
> This patch actually uses the gs register to implement the per-cpu
> sections. It's fairly straightforward: the gs segment starts at the
> per-cpu offset for the particular cpu (or 0, in very early boot).
>
> We also implement x86_64-inspired (via Jeremy Fitzhardinge) per-cpu
> accesses where a general lvalue isn't needed. These
> single-instruction accesses are slightly more efficient, plus (being a
> single insn) are atomic wrt. preemption so we can use them to
> implement cpu_local_inc etc.
The problem is nobody uses cpu_local_inc() etc :/ And it is difficult
to use in generic code because of the usual preemption issues
(and being slower on other archs in many cases compared to preempt disabling
around larger block of code)
Without that it is the same code as Jeremy's variant
%gs memory reference + another reference with offset as far as I can see.
So while it looks nice I don't think it will have advantages. Or did
i miss something?
-Andi
next prev parent reply other threads:[~2006-09-22 12:32 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-09-22 11:51 [PATCH 0/7] Using %gs for per-cpu areas on x86 Rusty Russell
2006-09-22 11:53 ` [PATCH 1/7] Use per-cpu GDT tables from early in boot Rusty Russell
2006-09-22 11:55 ` [PATCH 2/7] Rusty Russell
2006-09-22 11:56 ` [PATCH 3/7] Update sys_vm86 to cope with changed pt_regs and %gs usage Rusty Russell
2006-09-22 11:58 ` [PATCH 4/7] Fix places where using %gs changes the usermode ABI Rusty Russell
2006-09-22 11:59 ` [PATCH 5/7] Use %gs for per-cpu sections in kernel Rusty Russell
2006-09-22 12:00 ` [PATCH 6/7] (Optional) implement smp_processor_id() as a per-cpu var Rusty Russell
2006-09-22 12:01 ` [PATCH 7/7] (Optional) implement current " Rusty Russell
2006-09-25 5:29 ` Rusty Russell
2006-09-25 5:27 ` [PATCH 6/7] (Optional) implement smp_processor_id() " Rusty Russell
2006-09-22 12:32 ` Andi Kleen [this message]
2006-09-22 22:43 ` [PATCH 5/7] Use %gs for per-cpu sections in kernel Jeremy Fitzhardinge
2006-09-22 23:52 ` Andi Kleen
2006-09-23 4:51 ` Rusty Russell
2006-09-23 8:17 ` Andi Kleen
2006-09-23 8:55 ` Rusty Russell
2006-09-22 22:39 ` Jeremy Fitzhardinge
2006-09-23 4:31 ` Rusty Russell
2006-09-25 1:03 ` Jeremy Fitzhardinge
2006-09-25 1:16 ` Rusty Russell
2006-09-25 1:36 ` Jeremy Fitzhardinge
2006-09-25 2:51 ` Rusty Russell
2006-09-25 5:25 ` Jeremy Fitzhardinge
2006-09-25 6:03 ` Rusty Russell
2006-09-25 6:25 ` Jeremy Fitzhardinge
2006-09-25 23:33 ` Rusty Russell
2006-09-23 8:13 ` Andi Kleen
2006-09-25 1:07 ` Jeremy Fitzhardinge
2006-09-25 1:20 ` Rusty Russell
2006-09-25 5:26 ` Rusty Russell
2006-09-22 22:24 ` [PATCH 2/7] Jeremy Fitzhardinge
2006-09-23 4:36 ` Rusty Russell
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=20060922123215.GA98728@muc.de \
--to=ak@muc.de \
--cc=linux-kernel@vger.kernel.org \
--cc=rusty@rustcorp.com.au \
--cc=virtualization@lists.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).