* Re: Semaphore assembly-code bug [not found] ` <Pine.LNX.4.61.0410291631250.8616@twinlark.arctic.org.suse.lists.linux.kernel> @ 2004-10-30 2:04 ` Andi Kleen 0 siblings, 0 replies; 52+ messages in thread From: Andi Kleen @ 2004-10-30 2:04 UTC (permalink / raw) To: dean gaudet Cc: linux-os, Andreas Steinmetz, Richard Henderson, Andi Kleen, Andrew Morton, Jan Hubicka, linux-kernel, torvalds dean gaudet <dean-list-linux-kernel@arctic.org> writes: > > it's worse than that in general -- lea typically goes through the AGU > which has either less throughput or longer latency than the ALUs... > depending on which x86en. it's 4 cycles for a lea on p4, vs. 1 for a pop. > it's 2 cycles for a lea on k8 vs. 1 for a pop. On D stepping and later K8 the lea is 1 cycle latency because the decoder optimizes the lea into an add. -Andi ^ permalink raw reply [flat|nested] 52+ messages in thread
[parent not found: <Pine.LNX.4.61.0410291316470.3945@chaos.analogic.com.suse.lists.linux.kernel>]
[parent not found: <20041029175527.GB25764@redhat.com.suse.lists.linux.kernel>]
[parent not found: <Pine.LNX.4.61.0410291416040.4844@chaos.analogic.com.suse.lists.linux.kernel>]
[parent not found: <Pine.LNX.4.58.0410291133220.28839@ppc970.osdl.org.suse.lists.linux.kernel>]
* Re: Semaphore assembly-code bug [not found] ` <Pine.LNX.4.58.0410291133220.28839@ppc970.osdl.org.suse.lists.linux.kernel> @ 2004-10-30 2:13 ` Andi Kleen 2004-10-30 9:28 ` Denis Vlasenko 0 siblings, 1 reply; 52+ messages in thread From: Andi Kleen @ 2004-10-30 2:13 UTC (permalink / raw) To: Linus Torvalds; +Cc: linux-kernel Linus Torvalds <torvalds@osdl.org> writes: > Anyway, it's quite likely that for several CPU's the fastest sequence ends > up actually being > > movl 4(%esp),%ecx > movl 8(%esp),%edx > movl 12(%esp),%eax > addl $16,%esp > > which is also one of the biggest alternatives. For K8 it should be the fastest way. K7 probably too. -Andi ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Semaphore assembly-code bug 2004-10-30 2:13 ` Andi Kleen @ 2004-10-30 9:28 ` Denis Vlasenko 2004-10-30 17:53 ` Linus Torvalds 0 siblings, 1 reply; 52+ messages in thread From: Denis Vlasenko @ 2004-10-30 9:28 UTC (permalink / raw) To: Andi Kleen, Linus Torvalds; +Cc: linux-kernel On Saturday 30 October 2004 05:13, Andi Kleen wrote: > Linus Torvalds <torvalds@osdl.org> writes: > > > Anyway, it's quite likely that for several CPU's the fastest sequence ends > > up actually being > > > > movl 4(%esp),%ecx > > movl 8(%esp),%edx > > movl 12(%esp),%eax > > addl $16,%esp > > > > which is also one of the biggest alternatives. > > For K8 it should be the fastest way. K7 probably too. Pity. I always loved 1 byte insns :) /me hopes that K8 rev E or K9 will have optimized pop. -- vda ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Semaphore assembly-code bug 2004-10-30 9:28 ` Denis Vlasenko @ 2004-10-30 17:53 ` Linus Torvalds 2004-10-30 21:00 ` Denis Vlasenko 2004-10-31 0:39 ` Semaphore assembly-code bug Andi Kleen 0 siblings, 2 replies; 52+ messages in thread From: Linus Torvalds @ 2004-10-30 17:53 UTC (permalink / raw) To: Denis Vlasenko; +Cc: Andi Kleen, linux-kernel On Sat, 30 Oct 2004, Denis Vlasenko wrote: > > On Saturday 30 October 2004 05:13, Andi Kleen wrote: > > Linus Torvalds <torvalds@osdl.org> writes: > > > > > Anyway, it's quite likely that for several CPU's the fastest sequence ends > > > up actually being > > > > > > movl 4(%esp),%ecx > > > movl 8(%esp),%edx > > > movl 12(%esp),%eax > > > addl $16,%esp > > > > > > which is also one of the biggest alternatives. > > > > For K8 it should be the fastest way. K7 probably too. > > Pity. I always loved 1 byte insns :) I personally am a _huge_ believer in small code. The sequence popl %eax popl %ecx popl %edx popl %eax is four bytes. In contrast, the three moves and an add is 15 bytes. That's almost 4 times as big. And size _does_ matter. The extra 11 bytes means that if you have six of these sequences in your program, you are pretty much _guaranteed_ one more icache miss from memory. That's a few hundred cycles these days. Considering that you _maybe_ won a cycle or two each time it was executed, it's not at all clear that it's a win, except in benchmarks that have huge repeat-rates. Real life doesn't usually have that. In many real-life schenarios, repeat rates are in the tens of hundreds for most code... And that's ignoring things like disk load times etc. Sadly, the situation is often one where when you actually do all the performance testing, you artificially increase the repeat-rates hugely: you run the same program a thousand times in order to get a good profile, and you keep in the the cache all the time. So performance analysis often doesn't actually _see_ the downsides. Linus ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Semaphore assembly-code bug 2004-10-30 17:53 ` Linus Torvalds @ 2004-10-30 21:00 ` Denis Vlasenko 2004-10-30 21:14 ` code bloat [was Re: Semaphore assembly-code bug] Lee Revell 2004-10-31 0:39 ` Semaphore assembly-code bug Andi Kleen 1 sibling, 1 reply; 52+ messages in thread From: Denis Vlasenko @ 2004-10-30 21:00 UTC (permalink / raw) To: Linus Torvalds; +Cc: Andi Kleen, linux-kernel On Saturday 30 October 2004 20:53, Linus Torvalds wrote: > > > > movl 4(%esp),%ecx > > > > movl 8(%esp),%edx > > > > movl 12(%esp),%eax > > > > addl $16,%esp > > > > > > > > which is also one of the biggest alternatives. > > > > > > For K8 it should be the fastest way. K7 probably too. > > > > Pity. I always loved 1 byte insns :) > > I personally am a _huge_ believer in small code. Thankfully you are not alone - a horde of uclibc/dietlibc/busybox users shares these views. Also see http://smarden.org/pape/ > The sequence > > popl %eax > popl %ecx > popl %edx > popl %eax > > is four bytes. In contrast, the three moves and an add is 15 bytes. That's > almost 4 times as big. > > And size _does_ matter. The extra 11 bytes means that if you have six of > these sequences in your program, you are pretty much _guaranteed_ one more > icache miss from memory. That's a few hundred cycles these days. > Considering that you _maybe_ won a cycle or two each time it was executed, > it's not at all clear that it's a win, except in benchmarks that have huge > repeat-rates. Real life doesn't usually have that. In many real-life > schenarios, repeat rates are in the tens of hundreds for most code... If only glibc / X / KDE / OpenOffice (ugggh) people could hear you more... PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME CPU COMMAND 15364 root 15 0 38008 26M 28496 S 0,0 10,8 0:57 0 kmail 20022 root 16 0 40760 24M 23920 S 0,1 10,0 0:04 0 mozilla-bin 1627 root 14 -1 71064 19M 53192 S < 0,1 7,9 3:16 0 X 1700 root 15 0 25348 16M 23508 S 0,1 6,5 0:46 0 kdeinit 3578 root 15 0 24032 14M 21524 S 0,5 5,8 0:23 0 konsole -- vda ^ permalink raw reply [flat|nested] 52+ messages in thread
* code bloat [was Re: Semaphore assembly-code bug] 2004-10-30 21:00 ` Denis Vlasenko @ 2004-10-30 21:14 ` Lee Revell 2004-10-30 22:11 ` Denis Vlasenko 2004-10-31 6:37 ` Jan Engelhardt 0 siblings, 2 replies; 52+ messages in thread From: Lee Revell @ 2004-10-30 21:14 UTC (permalink / raw) To: Denis Vlasenko; +Cc: Linus Torvalds, Andi Kleen, linux-kernel On Sun, 2004-10-31 at 00:00 +0300, Denis Vlasenko wrote: > If only glibc / X / KDE / OpenOffice (ugggh) people could hear you more... > > PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME CPU COMMAND > 15364 root 15 0 38008 26M 28496 S 0,0 10,8 0:57 0 kmail > 20022 root 16 0 40760 24M 23920 S 0,1 10,0 0:04 0 mozilla-bin > 1627 root 14 -1 71064 19M 53192 S < 0,1 7,9 3:16 0 X > 1700 root 15 0 25348 16M 23508 S 0,1 6,5 0:46 0 kdeinit > 3578 root 15 0 24032 14M 21524 S 0,5 5,8 0:23 0 konsole Wow. evolution is now more bloated than kmail. 1424 rlrevell 15 0 125m 47m 29m S 7.8 10.1 1:41.78 evolution 1508 rlrevell 15 0 92432 30m 29m S 0.0 6.4 0:14.15 mozilla-bin 1090 root 16 0 55676 18m 40m S 24.8 3.9 0:46.98 XFree86 1379 rlrevell 15 0 33776 16m 18m S 0.3 3.5 0:06.65 nautilus 1377 rlrevell 15 0 19392 11m 15m S 0.0 2.5 0:03.29 gnome-panel 1458 rlrevell 16 0 28188 11m 15m S 3.9 2.5 0:10.44 gnome-terminal 1307 rlrevell 15 0 20828 11m 17m S 0.0 2.4 0:03.08 gnome-settings- Lee ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: code bloat [was Re: Semaphore assembly-code bug] 2004-10-30 21:14 ` code bloat [was Re: Semaphore assembly-code bug] Lee Revell @ 2004-10-30 22:11 ` Denis Vlasenko 2004-10-30 22:25 ` Lee Revell 2004-10-30 22:27 ` Tim Hockin 2004-10-31 6:37 ` Jan Engelhardt 1 sibling, 2 replies; 52+ messages in thread From: Denis Vlasenko @ 2004-10-30 22:11 UTC (permalink / raw) To: Lee Revell; +Cc: Linus Torvalds, Andi Kleen, linux-kernel On Sunday 31 October 2004 00:14, Lee Revell wrote: > On Sun, 2004-10-31 at 00:00 +0300, Denis Vlasenko wrote: > > If only glibc / X / KDE / OpenOffice (ugggh) people could hear you more... > > > > PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME CPU COMMAND > > 15364 root 15 0 38008 26M 28496 S 0,0 10,8 0:57 0 kmail > > 20022 root 16 0 40760 24M 23920 S 0,1 10,0 0:04 0 mozilla-bin > > 1627 root 14 -1 71064 19M 53192 S < 0,1 7,9 3:16 0 X > > 1700 root 15 0 25348 16M 23508 S 0,1 6,5 0:46 0 kdeinit > > 3578 root 15 0 24032 14M 21524 S 0,5 5,8 0:23 0 konsole > > Wow. evolution is now more bloated than kmail. > > 1424 rlrevell 15 0 125m 47m 29m S 7.8 10.1 1:41.78 evolution > 1508 rlrevell 15 0 92432 30m 29m S 0.0 6.4 0:14.15 mozilla-bin > 1090 root 16 0 55676 18m 40m S 24.8 3.9 0:46.98 XFree86 > 1379 rlrevell 15 0 33776 16m 18m S 0.3 3.5 0:06.65 nautilus > 1377 rlrevell 15 0 19392 11m 15m S 0.0 2.5 0:03.29 gnome-panel > 1458 rlrevell 16 0 28188 11m 15m S 3.9 2.5 0:10.44 gnome-terminal > 1307 rlrevell 15 0 20828 11m 17m S 0.0 2.4 0:03.08 gnome-settings- Well, I can try to compile packages with different options for size, I can link against small libc, but I feel this does not solve the problem: the code itself is bloated... I am not a code genius, but want to help. Hmm probably some bloat-detection tools would be helpful, like "show me source_lines/object_size ratios of fonctions in this ELF object file". Those with low ratio are suspects of excessive inlining etc. More ideas, anyone? -- vda ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: code bloat [was Re: Semaphore assembly-code bug] 2004-10-30 22:11 ` Denis Vlasenko @ 2004-10-30 22:25 ` Lee Revell 2004-10-31 14:06 ` Diego Calleja 2004-10-30 22:27 ` Tim Hockin 1 sibling, 1 reply; 52+ messages in thread From: Lee Revell @ 2004-10-30 22:25 UTC (permalink / raw) To: Denis Vlasenko; +Cc: Linus Torvalds, Andi Kleen, linux-kernel On Sun, 2004-10-31 at 01:11 +0300, Denis Vlasenko wrote: > Well, I can try to compile packages with different options > for size, I can link against small libc, but I feel this > does not solve the problem: the code itself is bloated... > > I am not a code genius, but want to help. > > Hmm probably some bloat-detection tools would be helpful, > like "show me source_lines/object_size ratios of fonctions in > this ELF object file". Those with low ratio are suspects of > excessive inlining etc. > > More ideas, anyone? I ageww it's a hard problem. Right now there is massive pressure on Linux application developers to add features to catch up with MS and Apple. This inevitably leads to bloat, we all know that efficiency is the first thing to go out the window in that situation, the problem is exacerbated by the wide availability of fast machines. It's an old, depressing story... That being said it would indeed be nice if we had more tools to quantify bloat. Lee ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: code bloat [was Re: Semaphore assembly-code bug] 2004-10-30 22:25 ` Lee Revell @ 2004-10-31 14:06 ` Diego Calleja 2004-10-31 20:53 ` Z Smith 0 siblings, 1 reply; 52+ messages in thread From: Diego Calleja @ 2004-10-31 14:06 UTC (permalink / raw) To: Lee Revell; +Cc: vda, torvalds, ak, linux-kernel El Sat, 30 Oct 2004 18:25:38 -0400 Lee Revell <rlrevell@joe-job.com> escribió: > I ageww it's a hard problem. Right now there is massive pressure on > Linux application developers to add features to catch up with MS and > Apple. This inevitably leads to bloat, we all know that efficiency is I don't think it's so bad (ie: it could be _worse_) There's some work going on to fix some "bloat problems" too, for example the x.org people are working in a sort of xlib complement/replacement (i don't know its real purpose) xcb which should help latency and code size. Composite itself is a nice way of avoiding that apps redraw their windows all the time. KDE "speed" is better is much better than a year ago, gnome 2.8 is also somewhat "faster" (compare nautilus in gnome 2.6 vs the one in 2.8). Openoffice 2.0 also will have some "performance improvements" (see http://development.openoffice.org/releases/q-concept.html#4.1.3.Performance|outline and http://development.openoffice.org/releases/q-concept.html#3.1.3.Performance|outline) ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: code bloat [was Re: Semaphore assembly-code bug] 2004-10-31 14:06 ` Diego Calleja @ 2004-10-31 20:53 ` Z Smith 2004-10-31 23:35 ` Rogério Brito 2004-11-01 14:48 ` Diego Calleja 0 siblings, 2 replies; 52+ messages in thread From: Z Smith @ 2004-10-31 20:53 UTC (permalink / raw) To: Diego Calleja; +Cc: linux-kernel Diego Calleja wrote: > I don't think it's so bad (ie: it could be _worse_) But not everyone can tolerate today's level of bloat. Imagine a small charity in a rural town in Bolivia or Colorado. They have no budget for computers and no one is offering donations. A local person put Linux on their 200 MHz system after Windows crashed and the Windows CD couldn't be found, but he can't put KDE or Gnome on it as well because that would bring it to a crawl. The only way to make the computer usable is to install an old distribution of Linux from 1998 which has Netscape 4 but no office app. Eventually they will give up on the computer and just throw it out, because they can't wait forever for programmers to write non-bloated software to make good use of their system. The machine ends up at a landfill where it leeches chemicals into the local water supply. Zack ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: code bloat [was Re: Semaphore assembly-code bug] 2004-10-31 20:53 ` Z Smith @ 2004-10-31 23:35 ` Rogério Brito 2004-11-01 1:20 ` Z Smith 2004-11-01 14:48 ` Diego Calleja 1 sibling, 1 reply; 52+ messages in thread From: Rogério Brito @ 2004-10-31 23:35 UTC (permalink / raw) To: Z Smith; +Cc: Diego Calleja, linux-kernel Z Smith wrote: > But not everyone can tolerate today's level of bloat. > > Imagine a small charity in a rural town in Bolivia or > Colorado. They have no budget for computers and no one > is offering donations. Well, let me jump into this thread. I don't live in Bolivia or Colorado, but I do live in Brazil. The fastest computer that I have at my disposal is this one with a Duron 600MHz processor. My father uses a Pentium MMX 200MHz with 64MB of RAM. Unfortunately, for financial reasons, I don't see we upgrading our computers too soo. It is nice to read Alan Cox saying that the Gnome team can make Gnome use less memory in the future. I'm anxiously looking forward to that. In the mean time, I will be using fluxbox and hoping that other parts of the system (libraries etc) don't grow too fast for my computers. I know plenty of people in the same situation that I am. Given the choice of purchasing a book for my education or upgrading my computer, I guess that I should spend money on the former. And the same is true for many of my relatives and friends. Rogério Brito. -- Learn to quote e-mails decently at: http://pub.tsn.dk/how-to-quote.php http://learn.to/quote http://www.xs4all.nl/~sbpoley/toppost.htm ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: code bloat [was Re: Semaphore assembly-code bug] 2004-10-31 23:35 ` Rogério Brito @ 2004-11-01 1:20 ` Z Smith 0 siblings, 0 replies; 52+ messages in thread From: Z Smith @ 2004-11-01 1:20 UTC (permalink / raw) To: Rogério Brito; +Cc: Diego Calleja, linux-kernel Rogério Brito wrote: > Z Smith wrote: > The fastest computer that I have at my disposal is this one with a Duron > 600MHz processor. My father uses a Pentium MMX 200MHz with 64MB of RAM. > Unfortunately, for financial reasons, I don't see we upgrading our > computers too soo. It seems that as time goes by, more and more people are coming to be financially limited. In some cases the cause is clearly the IMF / World Bank / WTO triad. Some casual reading: http://www.gregpalast.com/printerfriendly.cfm?artid=96 Zack ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: code bloat [was Re: Semaphore assembly-code bug] 2004-10-31 20:53 ` Z Smith 2004-10-31 23:35 ` Rogério Brito @ 2004-11-01 14:48 ` Diego Calleja 2004-11-01 15:09 ` [OT] " Russell Miller 1 sibling, 1 reply; 52+ messages in thread From: Diego Calleja @ 2004-11-01 14:48 UTC (permalink / raw) To: Z Smith; +Cc: linux-kernel El Sun, 31 Oct 2004 12:53:21 -0800 Z Smith <plinius@comcast.net> escribió: > But not everyone can tolerate today's level of bloat. Sadly it's true, but in the other hand I haven't seen something like gnome/kde which don't eats lots of resources (mac os x and XP are not better, beos was better they say), which makes me think that building a desktop environment without eating lots of resources is not easy. Well, and your projct is also bloat in some ways...it's small and all that but putting a graphics system inside the kernel is one of the best definitions of "bloat" you can find... ^ permalink raw reply [flat|nested] 52+ messages in thread
* [OT] Re: code bloat [was Re: Semaphore assembly-code bug] 2004-11-01 14:48 ` Diego Calleja @ 2004-11-01 15:09 ` Russell Miller 0 siblings, 0 replies; 52+ messages in thread From: Russell Miller @ 2004-11-01 15:09 UTC (permalink / raw) To: linux-kernel On Monday 01 November 2004 08:48, Diego Calleja wrote: > Sadly it's true, but in the other hand I haven't seen something like > gnome/kde which don't eats lots of resources (mac os x and XP are not > better, beos was better they say) Part of the problem with KDE is the QT library underneath it all. QT 4 is supposed to be leaner and faster. The KDE folks seem to be trying pretty hard to reduce bloat whenever possible. But when you have software that's expected to have the kitchen sink, it's especially challenging to reduce the footprint while keeping all of the functionality. I use openbox on my laptop. It's nothing near KDE in terms of functionality, but it also runs reasonably snappy on a Pentium 266, so I can't complain too much. So far I'm pretty glad that the linux kernel developers have resisted putting graphics calls and routines into the kernel. It slows things down a bit, but I'd like to think you guys have learned from MS's mistakes. IMO one of the biggest mistakes they ever made was to pollute the NT kernel with the graphics subsystem. That said, FBUI looks like an interesting add-on project. Enough of my off topic ranting... --Russell -- Russell Miller - rmiller@duskglow.com - Le Mars, IA Duskglow Consulting - Helping companies just like you to succeed for ~ 10 yrs. http://www.duskglow.com - 712-546-5886 ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: code bloat [was Re: Semaphore assembly-code bug] 2004-10-30 22:11 ` Denis Vlasenko 2004-10-30 22:25 ` Lee Revell @ 2004-10-30 22:27 ` Tim Hockin 2004-10-30 22:44 ` Jeff Garzik ` (2 more replies) 1 sibling, 3 replies; 52+ messages in thread From: Tim Hockin @ 2004-10-30 22:27 UTC (permalink / raw) To: Denis Vlasenko; +Cc: Lee Revell, Linus Torvalds, Andi Kleen, linux-kernel On Sun, Oct 31, 2004 at 01:11:07AM +0300, Denis Vlasenko wrote: > I am not a code genius, but want to help. > > Hmm probably some bloat-detection tools would be helpful, > like "show me source_lines/object_size ratios of fonctions in > this ELF object file". Those with low ratio are suspects of > excessive inlining etc. The problem with apps of this sort is the multiple layers of abstraction. Xlib, GLib, GTK, GNOME, Pango, XML, etc. No one wants to duplicate effort (rightly so). Each of these libs tries to do EVERY POSSIBLE thing. They all end up bloated. Then you have to link them all in. You end up bloated. Then it is very easy to rely on those libs for EVERYTHING, rather thank actually thinking. So you end up with the mindset of, for example, "if it's text it's XML". You have to parse everything as XML, when simple parsers would be tons faster and simpler and smaller. Bloat is cause by feature creep at every layer, not just the app. Youck. ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: code bloat [was Re: Semaphore assembly-code bug] 2004-10-30 22:27 ` Tim Hockin @ 2004-10-30 22:44 ` Jeff Garzik 2004-10-30 22:50 ` Tim Hockin 2004-10-31 20:15 ` Theodore Ts'o 2004-10-30 23:13 ` Denis Vlasenko 2004-10-31 6:49 ` Jan Engelhardt 2 siblings, 2 replies; 52+ messages in thread From: Jeff Garzik @ 2004-10-30 22:44 UTC (permalink / raw) To: Tim Hockin Cc: Denis Vlasenko, Lee Revell, Linus Torvalds, Andi Kleen, linux-kernel Tim Hockin wrote: > So you end up with the mindset of, for example, "if it's text it's XML". > You have to parse everything as XML, when simple parsers would be tons > faster and simpler and smaller. hehehe. One of the reasons why I like XML is that you don't have to keep cloning new parsers. Jeff ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: code bloat [was Re: Semaphore assembly-code bug] 2004-10-30 22:44 ` Jeff Garzik @ 2004-10-30 22:50 ` Tim Hockin 2004-10-31 20:15 ` Theodore Ts'o 1 sibling, 0 replies; 52+ messages in thread From: Tim Hockin @ 2004-10-30 22:50 UTC (permalink / raw) To: Jeff Garzik Cc: Denis Vlasenko, Lee Revell, Linus Torvalds, Andi Kleen, linux-kernel On Sat, Oct 30, 2004 at 06:44:10PM -0400, Jeff Garzik wrote: > Tim Hockin wrote: > >So you end up with the mindset of, for example, "if it's text it's XML". > >You have to parse everything as XML, when simple parsers would be tons > >faster and simpler and smaller. > > > hehehe. One of the reasons why I like XML is that you don't have to > keep cloning new parsers. I'm fine with XML, when it makes sense. In fact, I wrote an XML parser. It's blazingly fast. But it doesn't try to do everything for everyone. It does just as much as I needed. And Whn I need XML, I don;t have any problem linking it in. It's only a couple hundred lines of C. What irks me is best demonstrated by this: At OLS last year or the year before, at a talk about DBUS, someone asked about the DBUS protocol. When told that it was binary, they asked if there was any advantage to that over text. The reply "We didn't want to link an XML parser in". Now, I am fine with not wanting to ad bloat. But umm, the question was about TEXT, not XML. They are not the same thing. Not all text should be XML. ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: code bloat [was Re: Semaphore assembly-code bug] 2004-10-30 22:44 ` Jeff Garzik 2004-10-30 22:50 ` Tim Hockin @ 2004-10-31 20:15 ` Theodore Ts'o 2004-10-31 20:21 ` Jeff Garzik ` (2 more replies) 1 sibling, 3 replies; 52+ messages in thread From: Theodore Ts'o @ 2004-10-31 20:15 UTC (permalink / raw) To: Jeff Garzik; +Cc: linux-kernel On Sat, Oct 30, 2004 at 06:44:10PM -0400, Jeff Garzik wrote: > Tim Hockin wrote: > >So you end up with the mindset of, for example, "if it's text it's XML". > >You have to parse everything as XML, when simple parsers would be tons > >faster and simpler and smaller. > > hehehe. One of the reasons why I like XML is that you don't have to > keep cloning new parsers. .... if you don't mind bloating your application: % ls -l /usr/lib/libxml2.a 4224 -rw-r--r-- 1 root root 4312536 Oct 19 21:55 /usr/lib/libxml2.a - Ted ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: code bloat [was Re: Semaphore assembly-code bug] 2004-10-31 20:15 ` Theodore Ts'o @ 2004-10-31 20:21 ` Jeff Garzik 2004-10-31 21:06 ` Jan Engelhardt 2004-11-01 11:27 ` Alan Cox 2 siblings, 0 replies; 52+ messages in thread From: Jeff Garzik @ 2004-10-31 20:21 UTC (permalink / raw) To: Theodore Ts'o; +Cc: linux-kernel Theodore Ts'o wrote: > On Sat, Oct 30, 2004 at 06:44:10PM -0400, Jeff Garzik wrote: > >>Tim Hockin wrote: >> >>>So you end up with the mindset of, for example, "if it's text it's XML". >>>You have to parse everything as XML, when simple parsers would be tons >>>faster and simpler and smaller. >> >>hehehe. One of the reasons why I like XML is that you don't have to >>keep cloning new parsers. > > > .... if you don't mind bloating your application: > > % ls -l /usr/lib/libxml2.a > 4224 -rw-r--r-- 1 root root 4312536 Oct 19 21:55 /usr/lib/libxml2.a GLib's is a lot smaller :) Jeff ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: code bloat [was Re: Semaphore assembly-code bug] 2004-10-31 20:15 ` Theodore Ts'o 2004-10-31 20:21 ` Jeff Garzik @ 2004-10-31 21:06 ` Jan Engelhardt 2004-11-01 11:27 ` Alan Cox 2 siblings, 0 replies; 52+ messages in thread From: Jan Engelhardt @ 2004-10-31 21:06 UTC (permalink / raw) To: Theodore Ts'o; +Cc: Jeff Garzik, linux-kernel >.... if you don't mind bloating your application: > >% ls -l /usr/lib/libxml2.a >4224 -rw-r--r-- 1 root root 4312536 Oct 19 21:55 /usr/lib/libxml2.a Whoa. Bet its creator compiled with -g -O2 rather than -g0 -O2. ANd with -static instead of with <dynamic>. Yay look at this: 22:06 io:~ # l /usr/lib/libxml2.so -L #SUSE# -rwxr-xr-x 1 root root 1145089 Apr 6 2004 /usr/lib/libxml2.so 4x smaller! Jan Engelhardt -- Gesellschaft für Wissenschaftliche Datenverarbeitung Am Fassberg, 37077 Göttingen, www.gwdg.de ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: code bloat [was Re: Semaphore assembly-code bug] 2004-10-31 20:15 ` Theodore Ts'o 2004-10-31 20:21 ` Jeff Garzik 2004-10-31 21:06 ` Jan Engelhardt @ 2004-11-01 11:27 ` Alan Cox 2004-11-01 13:40 ` Denis Vlasenko 2 siblings, 1 reply; 52+ messages in thread From: Alan Cox @ 2004-11-01 11:27 UTC (permalink / raw) To: Theodore Ts'o; +Cc: Jeff Garzik, Linux Kernel Mailing List On Sul, 2004-10-31 at 20:15, Theodore Ts'o wrote: > .... if you don't mind bloating your application: > > % ls -l /usr/lib/libxml2.a > 4224 -rw-r--r-- 1 root root 4312536 Oct 19 21:55 /usr/lib/libxml2.a Except that 1. The file size has nothing to do with the binary size as it is full of symbols and maybe debug 2. Most of the pages of libxml2.so don't get paged in by a typical application 3. If you have existing apps using it then its cost to you is nearly zero because its already loaded. libxml2 is a very complete validating all singing all dancing XML parser. There are small non-validating parsers without every conceivable glue interface that come down to about 10K. ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: code bloat [was Re: Semaphore assembly-code bug] 2004-11-01 11:27 ` Alan Cox @ 2004-11-01 13:40 ` Denis Vlasenko 2004-11-01 23:04 ` Alan Cox 0 siblings, 1 reply; 52+ messages in thread From: Denis Vlasenko @ 2004-11-01 13:40 UTC (permalink / raw) To: Alan Cox, Theodore Ts'o; +Cc: Jeff Garzik, Linux Kernel Mailing List On Monday 01 November 2004 13:27, Alan Cox wrote: > 2. Most of the pages of libxml2.so don't get paged in by a typical > application This assumes that 'needed' functions are close together. This can be easily not the case, so you end up using only a fraction of fetched page's content. Also this argument tend to defend library growth. "It's mostly unused, don't worry". What if that is not true? How to compare RAM footprint of new versus old lib in this case? Just believe that it didn't get worse? This can't be checked easily: even -static compile can fail to help. glibc produce nearly 400kb executable for int main() { return 0; } because init code uses printf on error paths and that pulls i18n in. How many kilobytes is really runs - who knows... -- vda ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: code bloat [was Re: Semaphore assembly-code bug] 2004-11-01 13:40 ` Denis Vlasenko @ 2004-11-01 23:04 ` Alan Cox 0 siblings, 0 replies; 52+ messages in thread From: Alan Cox @ 2004-11-01 23:04 UTC (permalink / raw) To: Denis Vlasenko; +Cc: Theodore Ts'o, Jeff Garzik, Linux Kernel Mailing List On Llu, 2004-11-01 at 13:40, Denis Vlasenko wrote: > This assumes that 'needed' functions are close together. > This can be easily not the case, so you end up using only > a fraction of fetched page's content. And gprof will help you sort that out, along with -ffunction-sections you can do pretty fine grained tidying ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: code bloat [was Re: Semaphore assembly-code bug] 2004-10-30 22:27 ` Tim Hockin 2004-10-30 22:44 ` Jeff Garzik @ 2004-10-30 23:13 ` Denis Vlasenko 2004-10-30 22:45 ` Alan Cox ` (2 more replies) 2004-10-31 6:49 ` Jan Engelhardt 2 siblings, 3 replies; 52+ messages in thread From: Denis Vlasenko @ 2004-10-30 23:13 UTC (permalink / raw) To: Tim Hockin; +Cc: Lee Revell, Linus Torvalds, Andi Kleen, linux-kernel On Sunday 31 October 2004 01:27, Tim Hockin wrote: > On Sun, Oct 31, 2004 at 01:11:07AM +0300, Denis Vlasenko wrote: > > I am not a code genius, but want to help. > > > > Hmm probably some bloat-detection tools would be helpful, > > like "show me source_lines/object_size ratios of fonctions in > > this ELF object file". Those with low ratio are suspects of > > excessive inlining etc. > > The problem with apps of this sort is the multiple layers of abstraction. > > Xlib, GLib, GTK, GNOME, Pango, XML, etc. I think it makes sense to start from lower layers first: Kernel team is reasonably aware of the bloat danger. glibc is worse, but thanks to heroic actions of Eric Andersen we have mostly feature complete uclibc, 4 times (!) smaller than glibc. Xlib, GLib.... - didn't look into them apart from cases when they do not build or in bug hunting sessions. Quick data point: glib-1.2.10 is 1/2 of uclibc in size. glib-2.2.2 is 2 times uclibc. x4 growth :( > No one wants to duplicate effort (rightly so). Each of these libs tries > to do EVERY POSSIBLE thing. They all end up bloated. Then you have to > link them all in. You end up bloated. Then it is very easy to rely on > those libs for EVERYTHING, rather thank actually thinking. > > So you end up with the mindset of, for example, "if it's text it's XML". > You have to parse everything as XML, when simple parsers would be tons > faster and simpler and smaller. > > Bloat is cause by feature creep at every layer, not just the app. I actually tried to convince maintainers of one package that their code is needlessly complex. I did send patches to remedy that a bit while fixing real bugs. Rejected. Bugs were planned to be fixed by adding more code. I've lost all hope on that case. I guess this is a reason why bloat problem tend to be solved by rewrite from scratch. I could name quite a few cases: glibc -> dietlibc,uclibc coreutils -> busybox named -> djbdns inetd -> daemontools+ucspi-tcp sendmail -> qmail syslogd -> socklog (http://smarden.org/socklog/) It's sort of frightening that someone will need to rewrite Xlib or, say, OpenOffice :( -- vda ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: code bloat [was Re: Semaphore assembly-code bug] 2004-10-30 23:13 ` Denis Vlasenko @ 2004-10-30 22:45 ` Alan Cox 2004-10-31 1:21 ` Z Smith 2004-10-30 23:20 ` [OT] " Lee Revell 2004-10-30 23:28 ` Tim Hockin 2 siblings, 1 reply; 52+ messages in thread From: Alan Cox @ 2004-10-30 22:45 UTC (permalink / raw) To: Denis Vlasenko Cc: Tim Hockin, Lee Revell, Linus Torvalds, Andi Kleen, Linux Kernel Mailing List The gnome/gtk folks know they have a lot of code bloat, and know how to shave about 10Mb off the desktop size already. What they don't have is enough hands and brains to do this and the other stuff that is pressing. So if the desktop stuff is annoying you join gnome-love or whatever the kde equivalent is 8) Alan ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: code bloat [was Re: Semaphore assembly-code bug] 2004-10-30 22:45 ` Alan Cox @ 2004-10-31 1:21 ` Z Smith 2004-10-31 2:47 ` Jim Nelson 2004-10-31 15:19 ` Alan Cox 0 siblings, 2 replies; 52+ messages in thread From: Z Smith @ 2004-10-31 1:21 UTC (permalink / raw) Cc: Linux Kernel Mailing List Alan Cox wrote: > So if the desktop stuff is annoying you join gnome-love or whatever the > kde equivalent is 8) Or join me in my effort to limit bloat. Why use an X server that uses 15-30 megs of RAM when you can use FBUI which is 25 kilobytes of code with very minimal kmallocing? home.comcast.net/~plinius/fbui.html Zack Smith Bloat Liberation Front ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: code bloat [was Re: Semaphore assembly-code bug] 2004-10-31 1:21 ` Z Smith @ 2004-10-31 2:47 ` Jim Nelson 2004-10-31 15:19 ` Alan Cox 1 sibling, 0 replies; 52+ messages in thread From: Jim Nelson @ 2004-10-31 2:47 UTC (permalink / raw) To: Z Smith; +Cc: Linux Kernel Mailing List Z Smith wrote: > Alan Cox wrote: > >> So if the desktop stuff is annoying you join gnome-love or whatever the >> kde equivalent is 8) > > > Or join me in my effort to limit bloat. Why use an X server > that uses 15-30 megs of RAM when you can use FBUI which is 25 kilobytes > of code with very minimal kmallocing? > > home.comcast.net/~plinius/fbui.html > > Zack Smith > Bloat Liberation Front > Because some of us use remote X clients on big iron with an X server on your desktop. IIRC (been a long time since my CAD classes), a whole bunch of FEA and CAE/CAD applications worked this way. There is a lot more flexibility inherent in user-space compared to kernel-space. You can use PAM, Kerberos, and a whole host of other security devices that would be difficult to implement efficiently in kernel-space. Dude, that's a cool hack, but just about everything you did could be done with svgalib and the input core interface. The advantage to svgalib is that if that interface dies, you can recover the machine pretty easily, whereas kernel panics are a bit more disruptive. Still - it would be a nifty add-on for POS terminals, etc., just not the kind of thing I'd expect to see in the kernel anytime soon. Once 2.7 is started, see if people are more receptive. Take the time to flesh it out, get some more people on board, see if Sourceforge will host the project, and lose the advertising campaign - that's not likely to win any friends or supporters around here. I don't mean to be harsh, but c'mon - "Bloat Liberation Front" - err... okaaay... Good luck, Jim ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: code bloat [was Re: Semaphore assembly-code bug] 2004-10-31 1:21 ` Z Smith 2004-10-31 2:47 ` Jim Nelson @ 2004-10-31 15:19 ` Alan Cox 2004-10-31 20:18 ` Z Smith 1 sibling, 1 reply; 52+ messages in thread From: Alan Cox @ 2004-10-31 15:19 UTC (permalink / raw) To: Z Smith; +Cc: Linux Kernel Mailing List On Sul, 2004-10-31 at 01:21, Z Smith wrote: > Alan Cox wrote: > > > So if the desktop stuff is annoying you join gnome-love or whatever the > > kde equivalent is 8) > > Or join me in my effort to limit bloat. Why use an X server > that uses 15-30 megs of RAM when you can use FBUI which is 25 kilobytes > of code with very minimal kmallocing? My X server seems to be running at about 4Mbytes, plus the frame buffer mappings which make it appear a lot larger. I wouldn't be suprised if half the 4Mb was pixmap cache too, maybe more. I've helped write tiny UI kits (take a look at nanogui for example) but they don't have the flexibility of X. Alan ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: code bloat [was Re: Semaphore assembly-code bug] 2004-10-31 15:19 ` Alan Cox @ 2004-10-31 20:18 ` Z Smith 2004-11-01 11:05 ` Alan Cox 0 siblings, 1 reply; 52+ messages in thread From: Z Smith @ 2004-10-31 20:18 UTC (permalink / raw) To: Alan Cox; +Cc: Linux Kernel Mailing List Alan Cox wrote: > My X server seems to be running at about 4Mbytes, plus the frame buffer > mappings which make it appear a lot larger. I wouldn't be suprised if > half the 4Mb was pixmap cache too, maybe more. At first sight that sounds like a plausible explanation, however the facts in my case suggest something else is going on: My laptop's framebuffer is only 800x600x24bpp VESA, or 1406kB. But look at what X is doing: root 632 6.1 17.5 22024 16440 ? S 12:05 0:17 X :0 The more apps in use, the more memory is used, but at the moment I've only got xterm, rxvt, thunderbird, xclock and xload. My wm is blackbox which is using 5 megs. Also, just curious but why would memory-mapped I/O be counted in the memory usage anyway? Shouldn't there be a separate number for framebuffer memory and the like? > I've helped write tiny UI kits (take a look at nanogui for example) but > they don't have the flexibility of X. In my experience, most of the flexibility is not necessary for 97% of what I do, yet it evidently costs a lot in memory usage and speed. Zack ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: code bloat [was Re: Semaphore assembly-code bug] 2004-10-31 20:18 ` Z Smith @ 2004-11-01 11:05 ` Alan Cox 0 siblings, 0 replies; 52+ messages in thread From: Alan Cox @ 2004-11-01 11:05 UTC (permalink / raw) To: Z Smith; +Cc: Linux Kernel Mailing List On Sul, 2004-10-31 at 20:18, Z Smith wrote: > My laptop's framebuffer is only 800x600x24bpp VESA, or 1406kB. > But look at what X is doing: X has the frame buffer mapped as reported by VESA sizing not the minimal for the mode. (Think about RandR and you'll see why) > root 632 6.1 17.5 22024 16440 ? S 12:05 0:17 X :0 > > The more apps in use, the more memory is used, but at the moment > I've only got xterm, rxvt, thunderbird, xclock and xload. My wm is > blackbox which is using 5 megs. Mostly shared with the other apps, you did remember to divide each page by the number of users ? > Also, just curious but why would memory-mapped I/O be counted > in the memory usage anyway? Shouldn't there be a separate number > for framebuffer memory and the like? Actually there is probably not enough information in /proc to do the maths on it. The kernel itself has a clear idea which vma's are not backed by ram in the usual sense as they are marked VM_IO. > > I've helped write tiny UI kits (take a look at nanogui for example) but > > they don't have the flexibility of X. > > In my experience, most of the flexibility is not necessary for > 97% of what I do, yet it evidently costs a lot in memory usage > and speed. So my X server is 1Mb larger because I can run networked apps and play bzflag. Suits me as a tradeoff - I'm not saying it always is the right decision - nanogui works well in restricted environments like video recorders for example. ^ permalink raw reply [flat|nested] 52+ messages in thread
* [OT] Re: code bloat [was Re: Semaphore assembly-code bug] 2004-10-30 23:13 ` Denis Vlasenko 2004-10-30 22:45 ` Alan Cox @ 2004-10-30 23:20 ` Lee Revell 2004-10-30 22:52 ` Alan Cox 2004-10-31 0:48 ` Andi Kleen 2004-10-30 23:28 ` Tim Hockin 2 siblings, 2 replies; 52+ messages in thread From: Lee Revell @ 2004-10-30 23:20 UTC (permalink / raw) To: Denis Vlasenko; +Cc: Tim Hockin, Linus Torvalds, Andi Kleen, linux-kernel On Sun, 2004-10-31 at 02:13 +0300, Denis Vlasenko wrote: > It's sort of frightening that someone will need to > rewrite Xlib or, say, OpenOffice :( I think very few application developers understand the point Linus made - that bigger code IS slower code due to cache misses. If this were widely understood we would be in pretty good shape. Lee ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [OT] Re: code bloat [was Re: Semaphore assembly-code bug] 2004-10-30 23:20 ` [OT] " Lee Revell @ 2004-10-30 22:52 ` Alan Cox 2004-10-31 1:09 ` Ken Moffat 2004-10-31 0:48 ` Andi Kleen 1 sibling, 1 reply; 52+ messages in thread From: Alan Cox @ 2004-10-30 22:52 UTC (permalink / raw) To: Lee Revell Cc: Denis Vlasenko, Tim Hockin, Linus Torvalds, Andi Kleen, Linux Kernel Mailing List On Sul, 2004-10-31 at 00:20, Lee Revell wrote: > I think very few application developers understand the point Linus made > - that bigger code IS slower code due to cache misses. If this were > widely understood we would be in pretty good shape. On my laptop both Openoffice and gnome are measurably faster if you build the lot with -Os (except a couple of image libs) ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [OT] Re: code bloat [was Re: Semaphore assembly-code bug] 2004-10-30 22:52 ` Alan Cox @ 2004-10-31 1:09 ` Ken Moffat 2004-10-31 2:42 ` Tim Connors 2004-10-31 14:44 ` Alan Cox 0 siblings, 2 replies; 52+ messages in thread From: Ken Moffat @ 2004-10-31 1:09 UTC (permalink / raw) To: Alan Cox Cc: Lee Revell, Denis Vlasenko, Tim Hockin, Linus Torvalds, Andi Kleen, Linux Kernel Mailing List On Sat, 30 Oct 2004, Alan Cox wrote: > On Sul, 2004-10-31 at 00:20, Lee Revell wrote: > > I think very few application developers understand the point Linus made > > - that bigger code IS slower code due to cache misses. If this were > > widely understood we would be in pretty good shape. > > On my laptop both Openoffice and gnome are measurably faster if you > build the lot with -Os (except a couple of image libs) > Depends how much of gnome you use. I used to swear by -Os for non-toolchain stuff, but in the end I got bitten by gnumeric on x86. http://bugs.gnome.org/show_bug.cgi?id=128834 is similar, but in my case opening *any* spreadsheet would cause gnumeric to segfault (gcc-3.3 series). Add in the time spent rebuilding gnome before I found this bug report, and adding extra parts of gnome just in case I missed something, and the time to load it is irrelevant. Since then I've had an anecdotal report that -Os is known to cause problems with gnome. I s'pose people will say it serves me right for doing my initial testing on ppc which didn't have this problem ;) The point is that -Os is *much* less tested than -O2 at the moment. Ken -- das eine Mal als Tragödie, das andere Mal als Farce ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [OT] Re: code bloat [was Re: Semaphore assembly-code bug] 2004-10-31 1:09 ` Ken Moffat @ 2004-10-31 2:42 ` Tim Connors 2004-10-31 4:45 ` Paul 2004-10-31 14:44 ` Alan Cox 1 sibling, 1 reply; 52+ messages in thread From: Tim Connors @ 2004-10-31 2:42 UTC (permalink / raw) To: Ken Moffat; +Cc: Linux Kernel Mailing List Ken Moffat <ken@kenmoffat.uklinux.net> said on Sun, 31 Oct 2004 01:09:54 +0000 (GMT): > and the time to load it is irrelevant. Since then I've had an anecdotal > report that -Os is known to cause problems with gnome. I s'pose people > will say it serves me right for doing my initial testing on ppc which > didn't have this problem ;) The point is that -Os is *much* less tested > than -O2 at the moment. Because people suck, and don't use it and hence test it. Ie, test it! I can't, because I prefer to stay away from gnome instead. -- TimC -- http://astronomy.swin.edu.au/staff/tconnors/ "Warning: Do not look into laser with remaining eye" -- a physics experiment "Press emergency laser shutdown button with remaining hand" -- J.D.Baldwin @ ASR ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [OT] Re: code bloat [was Re: Semaphore assembly-code bug] 2004-10-31 2:42 ` Tim Connors @ 2004-10-31 4:45 ` Paul 0 siblings, 0 replies; 52+ messages in thread From: Paul @ 2004-10-31 4:45 UTC (permalink / raw) To: Linux Kernel Mailing List Tim Connors <tconnors+linuxkernel1099190446@astro.swin.edu.au>, on Sun Oct 31, 2004 [01:42:34 PM] said: > Ken Moffat <ken@kenmoffat.uklinux.net> said on Sun, 31 Oct 2004 01:09:54 +0000 (GMT): > > and the time to load it is irrelevant. Since then I've had an anecdotal > > report that -Os is known to cause problems with gnome. I s'pose people > > will say it serves me right for doing my initial testing on ppc which > > didn't have this problem ;) The point is that -Os is *much* less tested > > than -O2 at the moment. > > Because people suck, and don't use it and hence test it. > > Ie, test it! > > I can't, because I prefer to stay away from gnome instead. > Hi; Ive been using -Os as my default compile flag under Gentoo for probably over 2 years now. Havent noted any real problems, and thats nearly 3gig of compressed source code compiled on what is just my current system image. (Well, I might suck a little because I havent done any benchmarks or comparisons as to the actual benifits of doing so. Also, I use fvwm;) Paul set@pobox.com > -- > TimC -- http://astronomy.swin.edu.au/staff/tconnors/ ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [OT] Re: code bloat [was Re: Semaphore assembly-code bug] 2004-10-31 1:09 ` Ken Moffat 2004-10-31 2:42 ` Tim Connors @ 2004-10-31 14:44 ` Alan Cox 1 sibling, 0 replies; 52+ messages in thread From: Alan Cox @ 2004-10-31 14:44 UTC (permalink / raw) To: Ken Moffat Cc: Lee Revell, Denis Vlasenko, Tim Hockin, Linus Torvalds, Andi Kleen, Linux Kernel Mailing List On Sul, 2004-10-31 at 01:09, Ken Moffat wrote: > and the time to load it is irrelevant. Since then I've had an anecdotal > report that -Os is known to cause problems with gnome. I s'pose people > will say it serves me right for doing my initial testing on ppc which > didn't have this problem ;) The point is that -Os is *much* less tested > than -O2 at the moment. I've seen no real problems - x86-32 or x86-64, and my gnumeric appears happy. Could be that the Red Hat gcc 3.3 has the relevant fixes already in it from upstream I guess. ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: [OT] Re: code bloat [was Re: Semaphore assembly-code bug] 2004-10-30 23:20 ` [OT] " Lee Revell 2004-10-30 22:52 ` Alan Cox @ 2004-10-31 0:48 ` Andi Kleen 1 sibling, 0 replies; 52+ messages in thread From: Andi Kleen @ 2004-10-31 0:48 UTC (permalink / raw) To: Lee Revell Cc: Denis Vlasenko, Tim Hockin, Linus Torvalds, Andi Kleen, linux-kernel On Sat, Oct 30, 2004 at 07:20:04PM -0400, Lee Revell wrote: > On Sun, 2004-10-31 at 02:13 +0300, Denis Vlasenko wrote: > > It's sort of frightening that someone will need to > > rewrite Xlib or, say, OpenOffice :( > > I think very few application developers understand the point Linus made > - that bigger code IS slower code due to cache misses. If this were > widely understood we would be in pretty good shape. It's true in some cases, but not true in others. Don't make it your gospel. -Andi ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: code bloat [was Re: Semaphore assembly-code bug] 2004-10-30 23:13 ` Denis Vlasenko 2004-10-30 22:45 ` Alan Cox 2004-10-30 23:20 ` [OT] " Lee Revell @ 2004-10-30 23:28 ` Tim Hockin 2004-10-31 2:04 ` Michael Clark 2 siblings, 1 reply; 52+ messages in thread From: Tim Hockin @ 2004-10-30 23:28 UTC (permalink / raw) To: Denis Vlasenko; +Cc: Lee Revell, Linus Torvalds, Andi Kleen, linux-kernel On Sun, Oct 31, 2004 at 02:13:37AM +0300, Denis Vlasenko wrote: > > Bloat is cause by feature creep at every layer, not just the app. > > I actually tried to convince maintainers of one package > that their code is needlessly complex. I did send patches > to remedy that a bit while fixing real bugs. Rejected. > Bugs were planned to be fixed by adding more code. > I've lost all hope on that case. See, there is an ego problem, too. If you rewrite my code, it means you're better than I am. Rejected. Features win over efficiency. Seriously, look at glibc. Hav eyou ever tried to fix a bug in it? Holy CRAP is that horrible code. Each chunk of code itself is OK (though it abuses macrso so thoroughly I hesitate to call it C code). But it tried to support every architecture x every OS. You know what? I don't CARE if the glibc code compiles on HPUX or not. HPUX has it's own libc. > I guess this is a reason why bloat problem tend to be solved > by rewrite from scratch. I could name quite a few cases: From-scratch is a huge risk. But yeah, sometimes it has to be. > It's sort of frightening that someone will need to > rewrite Xlib or, say, OpenOffice :( Never gonna happen. ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: code bloat [was Re: Semaphore assembly-code bug] 2004-10-30 23:28 ` Tim Hockin @ 2004-10-31 2:04 ` Michael Clark 0 siblings, 0 replies; 52+ messages in thread From: Michael Clark @ 2004-10-31 2:04 UTC (permalink / raw) To: Tim Hockin Cc: Denis Vlasenko, Lee Revell, Linus Torvalds, Andi Kleen, linux-kernel On 10/31/04 07:28, Tim Hockin wrote: > On Sun, Oct 31, 2004 at 02:13:37AM +0300, Denis Vlasenko wrote: > >>>Bloat is cause by feature creep at every layer, not just the app. >> >>I actually tried to convince maintainers of one package >>that their code is needlessly complex. I did send patches >>to remedy that a bit while fixing real bugs. Rejected. >>Bugs were planned to be fixed by adding more code. >>I've lost all hope on that case. > > > See, there is an ego problem, too. If you rewrite my code, it means > you're better than I am. Rejected. > > Features win over efficiency. Seriously, look at glibc. Hav eyou ever > tried to fix a bug in it? Holy CRAP is that horrible code. Each chunk of > code itself is OK (though it abuses macrso so thoroughly I hesitate to > call it C code). But it tried to support every architecture x every OS. > You know what? I don't CARE if the glibc code compiles on HPUX or not. > HPUX has it's own libc. > > >>I guess this is a reason why bloat problem tend to be solved >>by rewrite from scratch. I could name quite a few cases: > > > From-scratch is a huge risk. But yeah, sometimes it has to be. > > >>It's sort of frightening that someone will need to >>rewrite Xlib or, say, OpenOffice :( Well, the xlib rewrite is happening (XCB/XCL). One of the reasons cited is the size of xlib. http://www.freedesktop.org/Software/xcb ~mc ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: code bloat [was Re: Semaphore assembly-code bug] 2004-10-30 22:27 ` Tim Hockin 2004-10-30 22:44 ` Jeff Garzik 2004-10-30 23:13 ` Denis Vlasenko @ 2004-10-31 6:49 ` Jan Engelhardt 2004-10-31 21:09 ` Z Smith 2004-11-01 15:17 ` Lee Revell 2 siblings, 2 replies; 52+ messages in thread From: Jan Engelhardt @ 2004-10-31 6:49 UTC (permalink / raw) Cc: linux-kernel >> Hmm probably some bloat-detection tools would be helpful, >> like "show me source_lines/object_size ratios of fonctions in >> this ELF object file". Those with low ratio are suspects of >> excessive inlining etc. Hm, I've got a (very simple) line determining utility, http://linux01.org:2222/f/UHXT/bin/sourcefuncsize maybe someone can pipe it together with ls -l or whatever. >The problem with apps of this sort is the multiple layers of abstraction. > >Xlib, GLib, GTK, GNOME, Pango, XML, etc. At least they know one thing: that thou should not stuff everything into one .so but multiple ones (if it's a lot). That /may/ reduce the size-in-memory, because not all .so's need to be loaded. OTOH, most apps load /all/ anyway. Heh, there we go. >Bloat is cause by feature creep at every layer, not just the app. I sense Java and C# being the best example. Z Smith wrote: >Or join me in my effort to limit bloat. Why use an X server >that uses 15-30 megs of RAM when you can use FBUI which is 25 kilobytes >of code with very minimal kmallocing? FBUI does not have 3d acceleration? Ken Moffat wrote: >>The point is that -Os is *much* less tested >>than -O2 at the moment. >Because people suck, and don't use it and hence test it. I doubt even the -O2-only-people use gprof/gcov frequently. :( Jan Engelhardt -- Gesellschaft für Wissenschaftliche Datenverarbeitung Am Fassberg, 37077 Göttingen, www.gwdg.de ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: code bloat [was Re: Semaphore assembly-code bug] 2004-10-31 6:49 ` Jan Engelhardt @ 2004-10-31 21:09 ` Z Smith 2004-10-31 21:13 ` Jan Engelhardt 2004-11-01 15:17 ` Lee Revell 1 sibling, 1 reply; 52+ messages in thread From: Z Smith @ 2004-10-31 21:09 UTC (permalink / raw) To: Jan Engelhardt; +Cc: linux-kernel Jan Engelhardt wrote: > FBUI does not have 3d acceleration? The problem is 3d non-acceleration i.e. VESA and VGA would still have to be supported. I'm no 3d expert but I think there must be some software-based 3d function would require using floating point, which isn't allowed in the kernel. Also, might not software 3d open the kernel up to patent issues? Zachary Smith ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: code bloat [was Re: Semaphore assembly-code bug] 2004-10-31 21:09 ` Z Smith @ 2004-10-31 21:13 ` Jan Engelhardt 2004-10-31 21:48 ` Z Smith 2004-11-01 11:29 ` Alan Cox 0 siblings, 2 replies; 52+ messages in thread From: Jan Engelhardt @ 2004-10-31 21:13 UTC (permalink / raw) To: Z Smith; +Cc: linux-kernel >> FBUI does not have 3d acceleration? > >The problem is 3d non-acceleration i.e. VESA and VGA >would still have to be supported. I'm no 3d expert but >I think there must be some software-based 3d function >would require using floating point, which isn't allowed >in the kernel. > >Also, might not software 3d open the kernel up to >patent issues? Whatever you do, 3D at the software level is slow, even with a fast comp. See MESA. Jan Engelhardt -- Gesellschaft für Wissenschaftliche Datenverarbeitung Am Fassberg, 37077 Göttingen, www.gwdg.de ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: code bloat [was Re: Semaphore assembly-code bug] 2004-10-31 21:13 ` Jan Engelhardt @ 2004-10-31 21:48 ` Z Smith 2004-11-01 11:29 ` Alan Cox 1 sibling, 0 replies; 52+ messages in thread From: Z Smith @ 2004-10-31 21:48 UTC (permalink / raw) To: Jan Engelhardt; +Cc: linux-kernel Jan Engelhardt wrote: >>Also, might not software 3d open the kernel up to >>patent issues? > > Whatever you do, 3D at the software level is slow, even with a fast comp. > See MESA. Well it might be nice to add support for hardware 3-D, once 2-D is mature. In fact I imagine it could be very convenient for some people. ZS ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: code bloat [was Re: Semaphore assembly-code bug] 2004-10-31 21:13 ` Jan Engelhardt 2004-10-31 21:48 ` Z Smith @ 2004-11-01 11:29 ` Alan Cox 2004-11-01 12:36 ` Jan Engelhardt 1 sibling, 1 reply; 52+ messages in thread From: Alan Cox @ 2004-11-01 11:29 UTC (permalink / raw) To: Jan Engelhardt; +Cc: Z Smith, Linux Kernel Mailing List On Sul, 2004-10-31 at 21:13, Jan Engelhardt wrote: > Whatever you do, 3D at the software level is slow, even with a fast comp. > See MESA. If you are willing to lose a few bits of OpenGL you can do 3D pretty fast in software for gaming. Take a look at stuff like TinyGL ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: code bloat [was Re: Semaphore assembly-code bug] 2004-11-01 11:29 ` Alan Cox @ 2004-11-01 12:36 ` Jan Engelhardt 0 siblings, 0 replies; 52+ messages in thread From: Jan Engelhardt @ 2004-11-01 12:36 UTC (permalink / raw) To: Alan Cox; +Cc: Z Smith, Linux Kernel Mailing List >> Whatever you do, 3D at the software level is slow, even with a fast comp. >> See MESA. > >If you are willing to lose a few bits of OpenGL you can do 3D pretty >fast in software for gaming. Take a look at stuff like TinyGL Ok, you're right. But to be honest, it does not need to be GL. Just look at UnrealTournament (runs fine on a PII W98 w/233MHz, in software mode!) Jan Engelhardt -- Gesellschaft für Wissenschaftliche Datenverarbeitung Am Fassberg, 37077 Göttingen, www.gwdg.de ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: code bloat [was Re: Semaphore assembly-code bug] 2004-10-31 6:49 ` Jan Engelhardt 2004-10-31 21:09 ` Z Smith @ 2004-11-01 15:17 ` Lee Revell 2004-11-01 16:56 ` Kristian Høgsberg 1 sibling, 1 reply; 52+ messages in thread From: Lee Revell @ 2004-11-01 15:17 UTC (permalink / raw) To: Jan Engelhardt; +Cc: linux-kernel, xorg On Sun, 2004-10-31 at 07:49 +0100, Jan Engelhardt wrote: > Z Smith wrote: > >Or join me in my effort to limit bloat. Why use an X server > >that uses 15-30 megs of RAM when you can use FBUI which is 25 kilobytes > >of code with very minimal kmallocing? > > FBUI does not have 3d acceleration? Um I don't think chucking X is the answer. The problem is that it's embarassingly slow compared to any modern GUI. If the display were as snappy as WinXP I don't care if it's 200MB. On my desktop I constantly see windows redrawing every freaking widget in situations where XP would just blit from an offscreen buffer or something. Anyway please keep replies off LKML and on the Xorg list... Lee ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: code bloat [was Re: Semaphore assembly-code bug] 2004-11-01 15:17 ` Lee Revell @ 2004-11-01 16:56 ` Kristian Høgsberg 0 siblings, 0 replies; 52+ messages in thread From: Kristian Høgsberg @ 2004-11-01 16:56 UTC (permalink / raw) To: Discuss issues related to the xorg tree; +Cc: Jan Engelhardt, linux-kernel Lee Revell wrote: > On Sun, 2004-10-31 at 07:49 +0100, Jan Engelhardt wrote: > >>Z Smith wrote: >> >>>Or join me in my effort to limit bloat. Why use an X server >>>that uses 15-30 megs of RAM when you can use FBUI which is 25 kilobytes >>>of code with very minimal kmallocing? >> >>FBUI does not have 3d acceleration? > > > Um I don't think chucking X is the answer. The problem is that it's > embarassingly slow compared to any modern GUI. If the display were as > snappy as WinXP I don't care if it's 200MB. On my desktop I constantly > see windows redrawing every freaking widget in situations where XP would > just blit from an offscreen buffer or something. > > Anyway please keep replies off LKML and on the Xorg list... Actually, please keep replies off the Xorg list as well. Thanks, Kristian ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: code bloat [was Re: Semaphore assembly-code bug] 2004-10-30 21:14 ` code bloat [was Re: Semaphore assembly-code bug] Lee Revell 2004-10-30 22:11 ` Denis Vlasenko @ 2004-10-31 6:37 ` Jan Engelhardt 1 sibling, 0 replies; 52+ messages in thread From: Jan Engelhardt @ 2004-10-31 6:37 UTC (permalink / raw) To: linux-kernel; +Cc: Denis Vlasenko, Linus Torvalds >> If only glibc / X / KDE / OpenOffice (ugggh) people could hear you more... >> >> PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME CPU COMMAND >> 15364 root 15 0 38008 26M 28496 S 0,0 10,8 0:57 0 kmail >> 20022 root 16 0 40760 24M 23920 S 0,1 10,0 0:04 0 mozilla-bin >> 1627 root 14 -1 71064 19M 53192 S < 0,1 7,9 3:16 0 X >> 1700 root 15 0 25348 16M 23508 S 0,1 6,5 0:46 0 kdeinit >> 3578 root 15 0 24032 14M 21524 S 0,5 5,8 0:23 0 konsole Heh, and guess what: the people in #kde (irc.freenode.net for example) deny that it's their fault with the statement "bah, that's shared libraries"! If that's a lie or not, or a semi-lie, I'm definitely sure THAT libdcop libmcop and every shitcrap that's running makes it almost impossible to run even on Duron-800 w/256. >Wow. evolution is now more bloated than kmail. > > 1424 rlrevell 15 0 125m 47m 29m S 7.8 10.1 1:41.78 evolution > 1508 rlrevell 15 0 92432 30m 29m S 0.0 6.4 0:14.15 mozilla-bin > 1090 root 16 0 55676 18m 40m S 24.8 3.9 0:46.98 XFree86 > 1379 rlrevell 15 0 33776 16m 18m S 0.3 3.5 0:06.65 nautilus > 1377 rlrevell 15 0 19392 11m 15m S 0.0 2.5 0:03.29 gnome-panel > 1458 rlrevell 16 0 28188 11m 15m S 3.9 2.5 0:10.44 gnome-terminal > 1307 rlrevell 15 0 20828 11m 17m S 0.0 2.4 0:03.08 gnome-settings- Gnome is no better. (Flamewar: I like ICEWM) The only thing more bloated is the X server itself when it runs with the proprietary NV GL core: USER PID MEM% VSZ RSZ STAT START TIME COMMAND root 5220 7.8 417872 20220 SL 08:37 0:03 X -noliste[...] Jan Engelhardt -- Gesellschaft für Wissenschaftliche Datenverarbeitung Am Fassberg, 37077 Göttingen, www.gwdg.de ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Semaphore assembly-code bug 2004-10-30 17:53 ` Linus Torvalds 2004-10-30 21:00 ` Denis Vlasenko @ 2004-10-31 0:39 ` Andi Kleen 2004-10-31 1:43 ` Linus Torvalds 1 sibling, 1 reply; 52+ messages in thread From: Andi Kleen @ 2004-10-31 0:39 UTC (permalink / raw) To: Linus Torvalds; +Cc: Denis Vlasenko, Andi Kleen, linux-kernel > I personally am a _huge_ believer in small code. > > The sequence > > popl %eax > popl %ecx > popl %edx > popl %eax > > is four bytes. In contrast, the three moves and an add is 15 bytes. That's > almost 4 times as big. Using the long stack setup code was found to be a significant win when enough registers were saved (several percent in real benchmarks) on K8 gcc. It speed up all function calls considerably because it eliminates several stalls for each function entry/exit. The popls will all depend on each other because of their implicied reference to esp. Yes, it bloats the code, but function calls happen so often that having them faster is really noticeable. The K8 has quite big caches and is not decoding limited, so it wasn't a too bad tradeoff there. Ideally you would want to only do it on hot functions and optimize rarely called functions for code size, but that would require profile feedback which is often not feasible (JITs have an advantage here) Unfortunately I don't think it is practically feasible for the kernel because we rely on to be able to recreate the same vmlinuxs for debugging. [It's a pity actually because modern compilers do a lot better with profile feedback] On P4 on the other hand it doesn't help at all and only makes the code bigger. I did it from hand in the x86-64 syscall code too (that was before there was EM64T, but I still think it was a good idea). Perhaps AMD adds special hardware in some future CPU that also makes it unnecessary, but currently it's like this and it helps. -Andi ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Semaphore assembly-code bug 2004-10-31 0:39 ` Semaphore assembly-code bug Andi Kleen @ 2004-10-31 1:43 ` Linus Torvalds 2004-10-31 2:04 ` Andi Kleen 0 siblings, 1 reply; 52+ messages in thread From: Linus Torvalds @ 2004-10-31 1:43 UTC (permalink / raw) To: Andi Kleen; +Cc: Denis Vlasenko, linux-kernel On Sun, 31 Oct 2004, Andi Kleen wrote: > > Using the long stack setup code was found to be a significant > win when enough registers were saved (several percent in real benchmarks) > on K8 gcc. For _what_? Real applications, or SpecInt? The fact is, SpecInt is not very interesting, because it has almost _zero_ icache footprint, and it has generally big repeat-rates, and to make matters worse, you are allowed (and everybody does) warm up the caches by running before you actually do the benchmark run. _None_ of these are realistic for real life workloads. > It speed up all function calls considerably because it > eliminates several stalls for each function entry/exit. .. it shaves off a few cycles in the cached case, yes. > The popls will all depend on each other because of their implicied > reference to esp. Which is only true on moderately stupid CPU's. Two pop's don't _really_ depend on each other in any real sense, and there are CPU's that will happily dual-issue them, or at least not stall in between (ie the pop's will happily keep the memory unit 100% busy). Linus ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: Semaphore assembly-code bug 2004-10-31 1:43 ` Linus Torvalds @ 2004-10-31 2:04 ` Andi Kleen 0 siblings, 0 replies; 52+ messages in thread From: Andi Kleen @ 2004-10-31 2:04 UTC (permalink / raw) To: Linus Torvalds; +Cc: Andi Kleen, Denis Vlasenko, linux-kernel On Sat, Oct 30, 2004 at 06:43:21PM -0700, Linus Torvalds wrote: > > > On Sun, 31 Oct 2004, Andi Kleen wrote: > > > > Using the long stack setup code was found to be a significant > > win when enough registers were saved (several percent in real benchmarks) > > on K8 gcc. > > For _what_? > > Real applications, or SpecInt? iirc gcc itself was faster (the modern one, not the old version in SpecInt) KDE startup ended up being faster too, but that may have been due to other improvements too. This was all tested on CPUs with very large caches (1MB L2), you can pack a lot of code into that. Also when people benchmark -m64 code compared to -m32 they often see large improvements on AMD64 (as long as the code isn't long or pointer memory bound), and I suspect at least part of that can be explained by the -m64 gcc defaulting to the long function prologues. Another example of larger code usually being better is x87 vs SSE2 floating point math. > The fact is, SpecInt is not very interesting, because it has almost _zero_ > icache footprint, and it has generally big repeat-rates, and to make I don't think it's generally true. one counter example is the gcc subtest in SpecInt. > > It speed up all function calls considerably because it > > eliminates several stalls for each function entry/exit. > > .. it shaves off a few cycles in the cached case, yes. I would expect it to help in the uncached case too because the CPU does very aggressive prefetching of code. Once it gets started on a function it will fetch it very quickly. > > > The popls will all depend on each other because of their implicied > > reference to esp. > > Which is only true on moderately stupid CPU's. Two pop's don't _really_ I don't see the K8 as a stupid CPU. > depend on each other in any real sense, and there are CPU's that will > happily dual-issue them, or at least not stall in between (ie the pop's > will happily keep the memory unit 100% busy). Yes, there are. And there are others that don't. -Andi ^ permalink raw reply [flat|nested] 52+ messages in thread
* Re: code bloat [was Re: Semaphore assembly-code bug] @ 2004-11-01 14:26 Ian Kumlien 0 siblings, 0 replies; 52+ messages in thread From: Ian Kumlien @ 2004-11-01 14:26 UTC (permalink / raw) To: linux-kernel [-- Attachment #1: Type: text/plain, Size: 1536 bytes --] Hi, First, why use a .a file to specify code bloat? I don't see why you want the object files... ie: ar tv /usr/lib/libxml2.a rw-rw-r-- 0/0 76336 Oct 29 04:34 2004 SAX.o rw-rw-r-- 0/0 83156 Oct 29 04:34 2004 entities.o rw-rw-r-- 0/0 90704 Oct 29 04:34 2004 encoding.o rw-rw-r-- 0/0 84272 Oct 29 04:34 2004 error.o rw-rw-r-- 0/0 90620 Oct 29 04:34 2004 parserInternals.o ... It can gladly sit there for all i care esp since it's installed by the -dev package. -rw-r--r-- 1 root root 4312792 Oct 29 04:34 /usr/lib/libxml2.a But when a app wants to load it you'll load a much smaller portion which is: 987632 bytes. As for X, check this out: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 2886 root 15 0 416m 152m 283m S 1.7 15.1 309:31.75 XFree86 And yes, that might look bad, but consider agp memory, memory on the card etc etc, then thats the figures we'd get. (and perhaps i should actually shut down some apps as well =)) Btw, the most annoyingly large .a file i have ever found was libc.a in a version of mdk, it included the whole libc build directory, post build, weighing something along the lines of 24 mb. Oh, and, you can never get rid of X, who will want something less flexible when they have had something like this. You'll get back to the same complexity sooner or later. I have to say that i much prefer freedesktop's approach. I'm not subbed so, you know what to do. -- Ian Kumlien <pomac () vapor ! com> -- http://pomac.netswarm.net [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 52+ messages in thread
end of thread, other threads:[~2004-11-02 0:41 UTC | newest]
Thread overview: 52+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <Pine.LNX.4.58.0410181540080.2287@ppc970.osdl.org.suse.lists.linux.kernel>
[not found] ` <417550FB.8020404@drdos.com.suse.lists.linux.kernel>
[not found] ` <1098218286.8675.82.camel@mentorng.gurulabs.com.suse.lists.linux.kernel>
[not found] ` <41757478.4090402@drdos.com.suse.lists.linux.kernel>
[not found] ` <20041020034524.GD10638@michonline.com.suse.lists.linux.kernel>
[not found] ` <1098245904.23628.84.camel@krustophenia.net.suse.lists.linux.kernel>
[not found] ` <1098247307.23628.91.camel@krustophenia.net.suse.lists.linux.kernel>
[not found] ` <Pine.LNX.4.61.0410200744310.10521@chaos.analogic.com.suse.lists.linux.kernel>
[not found] ` <Pine.LNX.4.61.0410290805570.11823@chaos.analogic.com.suse.lists.linux.kernel>
[not found] ` <Pine.LNX.4.58.0410290740120.28839@ppc970.osdl.org.suse.lists.linux.kernel>
[not found] ` <41826A7E.6020801@domdv.de.suse.lists.linux.kernel>
[not found] ` <Pine.LNX.4.61.0410291255400.17270@chaos.analogic.com.suse.lists.linux.kernel>
[not found] ` <Pine.LNX.4.58.0410291103000.28839@ppc970.osdl.org.suse.lists.linux.kernel>
[not found] ` <Pine.LNX.4.61.0410291631250.8616@twinlark.arctic.org.suse.lists.linux.kernel>
2004-10-30 2:04 ` Semaphore assembly-code bug Andi Kleen
[not found] ` <Pine.LNX.4.61.0410291316470.3945@chaos.analogic.com.suse.lists.linux.kernel>
[not found] ` <20041029175527.GB25764@redhat.com.suse.lists.linux.kernel>
[not found] ` <Pine.LNX.4.61.0410291416040.4844@chaos.analogic.com.suse.lists.linux.kernel>
[not found] ` <Pine.LNX.4.58.0410291133220.28839@ppc970.osdl.org.suse.lists.linux.kernel>
2004-10-30 2:13 ` Andi Kleen
2004-10-30 9:28 ` Denis Vlasenko
2004-10-30 17:53 ` Linus Torvalds
2004-10-30 21:00 ` Denis Vlasenko
2004-10-30 21:14 ` code bloat [was Re: Semaphore assembly-code bug] Lee Revell
2004-10-30 22:11 ` Denis Vlasenko
2004-10-30 22:25 ` Lee Revell
2004-10-31 14:06 ` Diego Calleja
2004-10-31 20:53 ` Z Smith
2004-10-31 23:35 ` Rogério Brito
2004-11-01 1:20 ` Z Smith
2004-11-01 14:48 ` Diego Calleja
2004-11-01 15:09 ` [OT] " Russell Miller
2004-10-30 22:27 ` Tim Hockin
2004-10-30 22:44 ` Jeff Garzik
2004-10-30 22:50 ` Tim Hockin
2004-10-31 20:15 ` Theodore Ts'o
2004-10-31 20:21 ` Jeff Garzik
2004-10-31 21:06 ` Jan Engelhardt
2004-11-01 11:27 ` Alan Cox
2004-11-01 13:40 ` Denis Vlasenko
2004-11-01 23:04 ` Alan Cox
2004-10-30 23:13 ` Denis Vlasenko
2004-10-30 22:45 ` Alan Cox
2004-10-31 1:21 ` Z Smith
2004-10-31 2:47 ` Jim Nelson
2004-10-31 15:19 ` Alan Cox
2004-10-31 20:18 ` Z Smith
2004-11-01 11:05 ` Alan Cox
2004-10-30 23:20 ` [OT] " Lee Revell
2004-10-30 22:52 ` Alan Cox
2004-10-31 1:09 ` Ken Moffat
2004-10-31 2:42 ` Tim Connors
2004-10-31 4:45 ` Paul
2004-10-31 14:44 ` Alan Cox
2004-10-31 0:48 ` Andi Kleen
2004-10-30 23:28 ` Tim Hockin
2004-10-31 2:04 ` Michael Clark
2004-10-31 6:49 ` Jan Engelhardt
2004-10-31 21:09 ` Z Smith
2004-10-31 21:13 ` Jan Engelhardt
2004-10-31 21:48 ` Z Smith
2004-11-01 11:29 ` Alan Cox
2004-11-01 12:36 ` Jan Engelhardt
2004-11-01 15:17 ` Lee Revell
2004-11-01 16:56 ` Kristian Høgsberg
2004-10-31 6:37 ` Jan Engelhardt
2004-10-31 0:39 ` Semaphore assembly-code bug Andi Kleen
2004-10-31 1:43 ` Linus Torvalds
2004-10-31 2:04 ` Andi Kleen
2004-11-01 14:26 code bloat [was Re: Semaphore assembly-code bug] Ian Kumlien
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.