From: Andi Kleen <ak@suse.de>
To: Linus Torvalds <torvalds@osdl.org>
Cc: Zachary Amsden <zach@vmware.com>,
Benjamin LaHaise <bcrl@kvack.org>,
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 19:52:55 +0100 [thread overview]
Message-ID: <200611051952.55655.ak@suse.de> (raw)
In-Reply-To: <Pine.LNX.4.64.0611050920220.25218@g5.osdl.org>
>
> So you get a test, a unpredictable conditional jump, and the sti - and
> you'll end up with the cost being pretty much the same as the popf: only
> bigger and more complex.
>
> That's a win, right?
Previously we had a popf which for the CPU unpredictable
restoring of most of its state. I would assume the unpredicted jump
is cheaper than that.
I might be wrong. Benchmarks will tell when I try it.
But I think it might be worth a try at least.
>
> > 99.9999% of all restore_flags just need STI.
>
> Hell no. If you know it statically, you can already just do the
> "spin_lock_irq()"->"spin_unlock_irq()", and then you have the
> _unconditional_ sti.
I meant they don't care about any other flags. Of course you need
a test + conditional jump first to handle the nested lock case.
> Andi, one single bug is usually worth _months_ of peoples time and effort.
> How many CPU cycles is that?
I bet near all cases where restore_flags() are used to restore something
else than IF are actually bugs or performance issues of some sort
This doesn't include the context switch of course, but that one
doesn't use restore_flags().
(I think I have a few legitimate cases of save_flags though. They probably
should be using a different macro for clarity.)
-Andi
next prev parent reply other threads:[~2006-11-05 18:53 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 [this message]
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=200611051952.55655.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox