| |||||||||||||
LinuxCon: Kernel roundtable covers more than just bloatLinuxCon: Kernel roundtable covers more than just bloatPosted Oct 1, 2009 1:02 UTC (Thu) by flewellyn (subscriber, #5047)Parent article: LinuxCon: Kernel roundtable covers more than just bloat
No plan yet on how to deal with the bloat problem? Well, I hope that doesn't remain the case for long.
(Log in to post comments)
LinuxCon: Kernel roundtable covers more than just bloat Posted Oct 1, 2009 4:31 UTC (Thu) by dowdle (subscriber, #659) [Link]
Over the last 10 releases (3 months x 10 = 30 months) the kernel has gotten 12% slower... but it has a ton more features and supports a lot more hardware. Doesn't sound like much of a loss to me. I mean how much better have processors gotten in the same 30 months? I'm guessing they have gotten more than 12% faster so it is obviously a net gain.
That isn't to say I want the kernel to keep getting slower.
If you want the video in a different format, I'd recommend visiting the page, pausing the video and waiting until it is completely buffered. Then you can copy /tmp/Flash{random-characters} to ~ and convert it to whatever format you want. Of course it would be nice to have a higher quality source to convert from but it isn't too bad.
LinuxCon: Kernel roundtable covers more than just bloat Posted Oct 1, 2009 9:32 UTC (Thu) by gevaerts (subscriber, #21521) [Link]
If you want to download the video, just visit the page and look at the source. The flv file is easily downloadable.
LinuxCon: Kernel roundtable covers more than just bloat Posted Oct 1, 2009 15:28 UTC (Thu) by Velmont (guest, #46433) [Link]
It's surprising that it doesn't work in Gnash. Many video players do, I should think Linux Magazine thought about that!
LinuxCon: Kernel roundtable covers more than just bloat Posted Oct 2, 2009 2:16 UTC (Fri) by DOT (subscriber, #58786) [Link]
You'd think Linux-related sites would already be providing Theora videos (self-hosted, or through dailymotion or blip.tv). It's not like their target demographic is likely to be running Internet Explorer. ;)
The causes of bloat? Posted Oct 1, 2009 9:46 UTC (Thu) by alex (subscriber, #1355) [Link]
Listening to this weeks FLOSS weekly which interviewed Linus I noted a lot of the "bloat" comes from features like auditing and security checking. I don't know if it's possible to build a stripped down kernel without these things in them and see if the performance comes back. Not that I'd want to run such a kernel on a production site though...
The causes of bloat? Posted Oct 4, 2009 17:26 UTC (Sun) by nevets (subscriber, #11875) [Link]
I've seen this with ftrace traces. Running the function graph tracer, a good amount of time is spent in the selinux code. The price you pay for security.
One might argue that we've become 12% slower, but > 12% more secure.
How much checking do you need to do? Posted Oct 5, 2009 10:43 UTC (Mon) by alex (subscriber, #1355) [Link]
I'm all for increasing the security of the kernel. However I feel the ideal* case the kernel should be striving for is a compare/branch for the check. Does SELinux do any caching of it's authentication results?
For example once you have validated a process can read a given file descriptor do you need to re-run the whole capability checking logic for every sys_read()?
Of course any such caching probably introduces another attack vector so care would have to be taken with the implementation?
*ideal being a target even if you may never actually reach that goal.
The causes of bloat? Posted Oct 8, 2009 7:01 UTC (Thu) by kragil (subscriber, #34373) [Link]
Yeah, it was clear that Linus wasn't happy about how the "huge and bloated" thing was the only focus nearly all media concentrated on. (leaving out the "unacceptable but unavoidable" part.)
In the interview he said that "at least Linux isn't this fat ugly pig that should have been shot 15 years ago"
I'd like to think that Linus is so bright that the bloat statement was intentional to get the kernel community working on a solution (don't tell me there isn't one that is way too easy), but he probably does not have these mad Sun Tzu communication skillz.
Maybe next time add the the pig comment to put things into perspective for the media?
LinuxCon: Kernel roundtable covers more than just bloat Posted Oct 1, 2009 10:26 UTC (Thu) by job (guest, #670) [Link] Considering what 5% extra performance costs in hardware in the mainstream segment, running a year old kernel would give you the same benefit (if you don't care about the newest features). That's not a good situation! Regarding the video, you can wget this link and feed it in mplayer/xine if you have a recent ffmpeg with VP6 installed.
LinuxCon: Kernel roundtable covers more than just bloat Posted Oct 2, 2009 18:09 UTC (Fri) by simonl (subscriber, #13603) [Link]
The Moore's law reference stinks. It is a typical commercial vendor apologist view. Sorry, our software sucks, we know, but just buy faster hw and make up for our crap.
When you argue that way, you take no pride in your code. And pride is what built this kernel.
Maybe the kernel devs have become too employed. Too focused on solving customers' immediate needs, and having too little time to go hunt down whatever catches their attention, big or small, with no prospects to please a project manager.
But look what Apple just did in their latest release: Nothing spectacular, except cleaning up. Someone has had the guts to nack new features and focus on removal.
LinuxCon: Kernel roundtable covers more than just bloat Posted Oct 4, 2009 9:41 UTC (Sun) by Los__D (guest, #15263) [Link]
Features costs performance. Drops for no reason is, of course, a problem but tradeoffs will need to be made sometimes.
You could have a LIGHTNING FAST DOS box today. What good would it do you?
Features no excuse Posted Oct 5, 2009 10:34 UTC (Mon) by eru (subscriber, #2753) [Link] Features costs performance.But if you don't use the features, you should not need to pay the price! If I understand correctly, the slowdown has been seen in repeatable benchmarks that can be run on both old and new kernel versions. Therefore the benchmarked code certainly isn't using any new features, but it still gets slowed down. Not justifiable. You could have a LIGHTNING FAST DOS box today. What good would it do you? Bad comparison. MS-DOS always had severe problems that really did not have much to do with its small footprint. It was brain-damaged already on day one. An OS that does more or less what MS-DOS did, but in a sensible and stable way might still be useful.
Features no excuse Posted Oct 8, 2009 8:20 UTC (Thu) by renox (subscriber, #23785) [Link]
[[But if you don't use the features, you should not need to pay the price!
If I understand correctly, the slowdown has been seen in repeatable benchmarks that can be run on both old and new kernel versions. Therefore the benchmarked code certainly isn't using any new features, but it still gets slowed down. Not justifiable.]]
Linus referred to the icache footprint(size) of the kernel, if you add features, even when not used they increased the size of the generated code so they reduce the performance.
Without specific figures, it's difficult to know where the issue is, I wouldn't be surprised that SELinux or virtualisation are the culprit: these features seems quite invasive..
Features no excuse Posted Oct 8, 2009 9:03 UTC (Thu) by dlang (✭ supporter ✭, #313) [Link]
adding SELinux defiantly slows things down, and if you run a benchmark on a system running a kernel compiled with SELinux you will get lower results than if you run the same benchmark on the same kernel without SELinux
so to not use the feature of SELinux you would compile a kernel without it.
the same thing goes for many fetures, turning them on at compile time increases the cache footprint and therefor slows the system, even if you don't use the feature. but you (usually) do have the option to not compile the code into the kernel to really avoid the runtime cost of them.
Features no excuse Posted Oct 8, 2009 9:10 UTC (Thu) by bersl2 (subscriber, #34928) [Link] But if you don't use the features, you should not need to pay the price! If I understand correctly, the slowdown has been seen in repeatable benchmarks that can be run on both old and new kernel versions. Therefore the benchmarked code certainly isn't using any new features, but it still gets slowed down. Not justifiable. Then configure out what you don't want already. Really, you think going with your distro's generic kernel is efficient? It doesn't take very long to find /proc/config* and take out some of the above-mentioned features that can't be modular. That, or yell at your distro, for the little good that will do.
LinuxCon: Kernel roundtable covers more than just bloat Posted Oct 4, 2009 12:04 UTC (Sun) by fuhchee (subscriber, #40059) [Link]
"... Too focused on solving customers' immediate needs, and having too little time to go hunt down whatever catches their attention ..."
I suspect it's the other way around. Many customers care deeply about performance, and it is their vendors who must perform code-karate against this kind of "bloat" (slowdown). To justify each new thing, LKML rarely carries data beyond microbenchmarks.
LinuxCon: Kernel roundtable covers more than just bloat Posted Oct 5, 2009 8:11 UTC (Mon) by cmccabe (guest, #60281) [Link]
> The Moore's law reference stinks. It is a typical commercial vendor
> apologist view. Sorry, our software sucks, we know, but just buy faster hw > and make up for our crap. > > When you argue that way, you take no pride in your code. And pride is what > built this kernel.
Well, maybe, you can have clean code that runs 12% slower, or you can have code that's #ifdef'ed to hell that runs at the old speed. In that case, which would you rather have?
Keep in mind, if you choose route #2, people in 2015 might use your name as a curse...
Obviously this is an oversimplification. But still, the point remains: don't criticize the code until you've seen it and understand the tradeoffs.
pride comes before a fall Posted Oct 14, 2009 9:52 UTC (Wed) by gvy (guest, #11981) [Link]
> And pride is what built this kernel.
I hope *not*.
LinuxCon: Kernel roundtable covers more than just bloat Posted Oct 1, 2009 16:20 UTC (Thu) by smoogen (subscriber, #97) [Link]
I think the issue is defining 'bloat'. Most of the features that the unnamed priestess of Delphi has are also features that the various people running it have wanted if for no other reason than all the business case rules that require them to be audited. Now for ye-old hacker in the basement.. those are things that aren't needed ro wanted. Its going to be in the end up to the ye-old hackers to dive in and fix/remove the bloat to see if it can be regained. My guess though is that for mainstream Linux it will mostly be there for some time.
LinuxCon: Kernel roundtable covers more than just bloat Posted Oct 1, 2009 16:43 UTC (Thu) by flewellyn (subscriber, #5047) [Link]
That's a good point: there's no rule that says you have to run a distro-built kernel, even in a production environment. A customized kernel with unneeded features trimmed may help matters. (For instance, I have no need for most of the drivers or filesystems.)
LinuxCon: Kernel roundtable covers more than just bloat Posted Oct 2, 2009 0:25 UTC (Fri) by giraffedata (subscriber, #1954) [Link] Linus was talking about some kind of bloat that makes the kernel slower. I don't think removing device driver or filesystem driver modules from the disk or configuring out most of the configurable features speeds things up.
LinuxCon: Kernel roundtable covers more than just bloat Posted Oct 2, 2009 4:48 UTC (Fri) by karthik_s1 (subscriber, #60525) [Link]
make linux a micro kernel :-)
macro overhead Posted Oct 14, 2009 10:03 UTC (Wed) by gvy (guest, #11981) [Link]
> make linux a micro kernel :-)
Oh yeah, that would make those pesky 12% a non-issue. :]
|
|||||||||||||