From: Rusty Russell <rusty@rustcorp.com.au>
To: Jeremy Fitzhardinge <jeremy@goop.org>
Cc: Andi Kleen <ak@muc.de>,
lkml - Kernel Mailing List <linux-kernel@vger.kernel.org>,
virtualization <virtualization@lists.osdl.org>
Subject: Re: [PATCH 2/7]
Date: Sat, 23 Sep 2006 14:36:01 +1000 [thread overview]
Message-ID: <1158986162.26261.66.camel@localhost.localdomain> (raw)
In-Reply-To: <451462B0.8000709@goop.org>
On Fri, 2006-09-22 at 15:24 -0700, Jeremy Fitzhardinge wrote:
> Rusty Russell wrote:
> > This patch implements save/restore of %gs in the kernel, so it can be
> > used for per-cpu data. This is not cheap, and we do it for UP as well
> > as SMP, which is stupid. Benchmarks, anyone?
> >
> I measured the cost as adding 9 cycles to a null syscall on my Core Duo
> machine. I have not explicitly measured it on other machines, but I run
> a number of other segment save/load tests on a wide range of machines,
> and didn't find much variability.
Oh, OK! I had a belief that segment loading was expensive, perhaps I'm
off-base here.
> I think saving/restoring %gs will still be necessary. There are a number
> of places in the kernel which expect to find the usermode %gs on the
> kernel stack frame, including context switch, ptrace, vm86, signal
> context, and maybe something else. If you don't save it on the stack,
> then you need to have UP variations of %gs handling in all those other
> places, which is pretty messy. Also, unless you want to have two
> definitions of struct_pt regs (which would add even more mess into
> ptrace), you'd still need to sub/add %esp in entry.S to skip over the
> %gs hole. I don't think this UP microoptimisation would be worth enough
> to justify the mess it would cause elsewhere.
>
> How does this version of the patch differ from mine? Is it just my
> patch+Ingo's fix, or are there other changes? I couldn't see anything
> from a quick read-over.
Yep, no substative changes. s/__KERNEL_PDA/__KERNEL_PERCPU/, plus your
version had a "write_pda(pcurrent, next_p)" inserted in process.c's
__switch_to which belonged in a successor patch...
Thanks!
Rusty.
--
Help! Save Australia from the worst of the DMCA: http://linux.org.au/law
next prev parent reply other threads:[~2006-09-23 4:36 UTC|newest]
Thread overview: 35+ 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 ` [PATCH 5/7] Use %gs for per-cpu sections in kernel Andi Kleen
2006-09-22 12:32 ` Andi Kleen
2006-09-22 22:43 ` 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: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 [this message]
-- strict thread matches above, loose matches on Subject: below --
2004-03-21 19:33 [PATCH 0/7] Bunch of patches Alexander Kern
2004-03-21 19:37 ` [PATCH 2/7] Alexander Kern
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=1158986162.26261.66.camel@localhost.localdomain \
--to=rusty@rustcorp.com.au \
--cc=ak@muc.de \
--cc=jeremy@goop.org \
--cc=linux-kernel@vger.kernel.org \
--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 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.