Re: Semaphore assembly-code bug
From: Linus Torvalds
Date: Mon Nov 01 2004 - 18:58:07 EST
On Mon, 1 Nov 2004, linux-os wrote:
> No. You've just shown that you like to argue. I recall that you
> recently, like within the past 24 hours, supplied a patch that
> got rid of the time-consuming stack operations in your semaphore
> code. Remember, you changed it to pass parameters in registers.
... because that fixed a _bug_.
> Why would you bother if stack operations are free?
I didn't say that instructions are free. I just tried (unsuccessfully) to
tell you that "lea" is not free either, and that "lea" has some serious
problems on several setups, ranging from old cpu's (AGI stalls) to new
CPU's (stack engine stalls). And that "pop" is often faster.
And you have been arguing against it despite the fact that I ended up
writing a small test-program to show that it's true. It's a _stupid_
test-program, but the fact is, you only need a single test-case to prove
some theory wrong.
Your theory that "lea" is somehow always cheaper than "pop" is wrong.
> It's not a total focus. It's just necessary emphasis. Any work
> done by your computer, ultimately comes from and goes to memory.
A lot of work is done in cache. Any access that doesn't change the state
of the cache is a no-op as far as the memory bus is concerned. Ie a store
to a cacheline that is already dirty is just a cache access, as is a load
from a cacheline that is already loaded.
This is especially true on x86 CPU's, where the lack of registers means
that the core has been highly optimized for doing cached operations.
Remember: a CPU is not some kind of abstract entity - it's a very
practical piece of engineering that has been highly optimized for certain
And the fact is, "lea" on %esp is not a common usage pattern. Which is
why, in practice, you will find CPU's that end up not optimizing for it.
While "pop"+"pop" is a _very_ common pattern, and why existing CPU's
do them efficiently.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/