From: Andi Kleen <ak@suse.de>
To: Linus Torvalds <torvalds@osdl.org>
Cc: Benjamin LaHaise <bcrl@kvack.org>,
Zachary Amsden <zach@vmware.com>,
Chuck Ebbert <76306.1226@compuserve.com>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [rfc patch] i386: don't save eflags on task switch
Date: Sun, 5 Nov 2006 17:54:11 +0100 [thread overview]
Message-ID: <200611051754.11982.ak@suse.de> (raw)
In-Reply-To: <Pine.LNX.4.64.0611050808090.25218@g5.osdl.org>
On Sunday 05 November 2006 17:12, Linus Torvalds wrote:
> And changing restore-flags to a "conditional branch around sti"
Yes of course.
> is likely
> not much better
We'll see.
It used to be a bad idea because everything was inline, but these
days with out of line code one can be much more flexible.
> - mispredicted branches on a P4 are potentially worse than
> the popf cost.
They are far less than 48 cycles. The P4 is not _that_ bad in this
area.
> Side note: for the netburst microarchitecture - aka P4 - in general,
> something like 48 cycles is a _good_ thing. I measured a internal
> micro-fault for marking a page table entry dirty at over 1500 cycles!
> There's a reason Intel dropped Netburst in favour of Core 2 - which is
> largely just an improved Pentium Pro uarch. Admittedly, the "just" is a
> bit unfair, because there's a _lot_ of improvement, but still..
>
> So you should never actually make any real code design decisions based on
> a P4 result. The P4 is goign away, and it was odd.
There are millions and millions of P4s out there running
Linux and I don't think that will change any time soon (in fact Intel will
be still shipping many new ones for a long time) If there are cheap
valuable optimizations for P4 that don't impact others much I'm all for them.
-Andi
next prev parent reply other threads:[~2006-11-05 16:55 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
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 [this message]
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=200611051754.11982.ak@suse.de \
--to=ak@suse.de \
--cc=76306.1226@compuserve.com \
--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 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.