From: Chuck Ebbert <76306.1226@compuserve.com>
To: Linus Torvalds <torvalds@osdl.org>
Cc: Zachary Amsden <zach@vmware.com>, Andi Kleen <ak@suse.de>,
linux-kernel <linux-kernel@vger.kernel.org>,
Benjamin LaHaise <bcrl@kvack.org>
Subject: Re: [rfc patch] i386: don't save eflags on task switch
Date: Sat, 4 Nov 2006 01:56:51 -0500 [thread overview]
Message-ID: <200611040200_MC3-1-D04D-6EA3@compuserve.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0611031645141.25218@g5.osdl.org>
On Fri, 3 Nov 2006 16:46:25 -0800, Linus Torvalds wrote:
> On Fri, 3 Nov 2006, Chuck Ebbert wrote:
> >
> > There is no real need to save eflags in switch_to(). Instead,
> > we can keep a constant value in the thread_struct and always
> > restore that.
>
> I don't really see the point. The "pushfl" isn't the expensive part, and
> it gives sane and expected semantics.
>
> The "popfl" is the expensive part, and that's the thing that can't really
> even be removed.
Well that wasn't the impression I got:
Date: Mon, 18 Sep 2006 12:12:51 -0400
From: Benjamin LaHaise <bcrl@kvack.org>
Subject: Re: Sysenter crash with Nested Task Bit set
...
It's the pushfl that will be slow on any OoO CPU, as it has dependancies on
any previous instructions that modified the flags, which ends up bringing
all of the memory ordering dependancies into play. Doing a popfl to set the
flags to some known value is much less expensive.
And benchmarks seem to support that, even on K8:
lmbench context switch, 50 runs
before after
avg 1.09 1.05
stddev .25 .18
But P4 is the real problem case and I can't test that.
--
Chuck
"Even supernovas have their duller moments."
next reply other threads:[~2006-11-04 7:03 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-04 6:56 Chuck Ebbert [this message]
2006-11-04 19:09 ` Zachary Amsden
2006-11-04 19:35 ` Linus Torvalds
2006-11-05 3:55 ` Benjamin LaHaise
2006-11-05 4:13 ` Linus Torvalds
2006-11-05 5:41 ` Andi Kleen
2006-11-05 8:01 ` Zachary Amsden
2006-11-05 17:01 ` Andi Kleen
2006-11-05 17:26 ` Linus Torvalds
2006-11-05 17:34 ` Arjan van de Ven
2006-11-05 17:51 ` Linus Torvalds
2006-11-05 22:48 ` Zachary Amsden
2006-11-05 18:52 ` Andi Kleen
2006-11-05 16:12 ` Linus Torvalds
2006-11-05 16:54 ` Andi Kleen
2006-11-05 17:20 ` Linus Torvalds
2006-11-05 4:17 ` Zachary Amsden
2006-11-05 20:10 ` H. Peter Anvin
-- strict thread matches above, loose matches on Subject: below --
2006-11-04 0:00 Chuck Ebbert
2006-11-04 0:46 ` Linus Torvalds
2006-11-04 1:36 ` 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=200611040200_MC3-1-D04D-6EA3@compuserve.com \
--to=76306.1226@compuserve.com \
--cc=ak@suse.de \
--cc=bcrl@kvack.org \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@osdl.org \
--cc=zach@vmware.com \
/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
all inboxes | Powered by JetHome®