Herbert Xu wrote:
On Wed, Aug 15, 2007 at 01:02:23PM -0400, Chris Snook wrote:
Herbert Xu wrote:
Andi Kleen <[email protected]> wrote:
My config with march=pentium-m and gcc (GCC) 4.1.2 (Gentoo 4.1.2):
text data bss dec hex filename
3434150 249176 176128 3859454 3ae3fe atomic_normal/vmlinux
3435308 249176 176128 3860612 3ae884 atomic_inlineasm/vmlinux
What is the difference between atomic_normal and atomic_inlineasm?
The inline asm stops certain optimisations from occuring.
I'm still unconvinced why we need this because nobody has
brought up any examples of kernel code that legitimately
need this.
There's plenty of kernel code that *wants* this though. If we can
You keep saying this yet everytime I ask for an example I
get nothing.
Just look for all the code (and there's an immense amount) that has a
barrier() between two atomic_* operations, or in a loop with such
operations. With these patches merged, we can proceed to *remove* those
barriers.
reduce the need for register-clobbering barriers, shrink our binaries,
shrink our code, improve performance, and avoid heisenbugs, I think it's
a win, whether or not we *need* it.
Hmm, you're increasing our binary size and probably killing
performance.
The cost of these patches themselves is negligible, since people pretty
much always use barriers in places where it would matter. The long-term
benefit is that with guaranteed volatile behavior, we can go through and
remove a whole bunch of these barriers.
-- Chris
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
