mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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."


             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®