public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Zachary Amsden <zach@vmware.com>
To: Chuck Ebbert <76306.1226@compuserve.com>
Cc: Linus Torvalds <torvalds@osdl.org>, 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, 04 Nov 2006 11:09:42 -0800	[thread overview]
Message-ID: <454CE576.3000709@vmware.com> (raw)
In-Reply-To: <200611040200_MC3-1-D04D-6EA3@compuserve.com>

Chuck Ebbert wrote:
> 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.
>   

That doesn't sound correct to me.  The popf is far more expensive.  
There is no popfl $IMM instruction, so setting flags never can avoid the 
memory read and must make some more expensive assumptions about effects 
on further instruction stream (TF, DF, all sign flags for conditional 
jumps...).

Every processor I've ever measured it on, popf is slower.  On P4, for 
example, pushf is 6 cycles, and popf is 54.  On Opteron, it is 2 / 12.  
On Xeon, it is 7 / 91.

Zach

  reply	other threads:[~2006-11-04 19:09 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-11-04  6:56 [rfc patch] i386: don't save eflags on task switch Chuck Ebbert
2006-11-04 19:09 ` Zachary Amsden [this message]
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=454CE576.3000709@vmware.com \
    --to=zach@vmware.com \
    --cc=76306.1226@compuserve.com \
    --cc=ak@suse.de \
    --cc=bcrl@kvack.org \
    --cc=linux-kernel@vger.kernel.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox