linux-kernel - Re: [rfc patch] i386: don't save eflags on task switch

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.64.0611050920220.25218@g5.osdl.org>
Date:	Sun, 5 Nov 2006 09:26:40 -0800 (PST)
From:	Linus Torvalds <torvalds@...l.org>
To:	Andi Kleen <ak@...e.de>
cc:	Zachary Amsden <zach@...are.com>,
	Benjamin LaHaise <bcrl@...ck.org>,
	Chuck Ebbert <76306.1226@...puserve.com>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [rfc patch] i386: don't save eflags on task switch

On Sun, 5 Nov 2006, Andi Kleen wrote:
> 
> > sti is expensive as well; iirc just as expensive on most processors as 
> > popf, 
> 
> On K8 STI is 4 cycles.

Your point being? On K8, popf was 12 cycles according to Zach. The 
conditional branch is going to be almost totally unpredictable, unless you 
inline it everywhere (it will be statically predictable in each individual 
location), but if you inline it, you'll be expanding a two-byte 
instruction sequence to something like 10 bytes with all the tests.

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?

> 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.

The problem with that is that it's now a lot more fragile, ie you must 
know what the calling context was. We do do this, because it _is_ faster 
when it's unconditional, but you're optimizing all the wrong things.

Andi, one single bug is usually worth _months_ of peoples time and effort. 
How many CPU cycles is that? 

You need to learn that "stability and maintainability" is more important 
than trying to get a single cycle or two. Really. I'll do cycle tweaking 
too, but it needs to be something that is really obvious, or really 
important. 

			Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/