Messages in this thread | | | Date | Thu, 16 Aug 2007 15:23:49 -0400 | From | Chris Snook <> | Subject | Re: [patch 1/2] i386: use asm() like the other atomic operations already do. |
| |
Herbert Xu wrote: > On Wed, Aug 15, 2007 at 01:02:23PM -0400, Chris Snook wrote: >> Herbert Xu wrote: >>> Andi Kleen <ak@suse.de> 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |