| Weekly edition | Kernel | Security | Distributions | Search |
| Archives | Calendar | Subscribe | Write for LWN | LWN.net FAQ |
Linux: It's Not Just for Servers Anymore (Wired)
Linux: It's Not Just for Servers Anymore (Wired)
Posted Jul 27, 2007 17:10 UTC (Fri) by mbottrell (guest, #43008)Parent article: Linux: It's Not Just for Servers Anymore (Wired)
And the same week Con Kolivas (CK) announced he was hanging up his boots from kernel patching to make the desktop usable. *sigh*
Something the current kernel-devels should look seriously at... there has been enough work go into the server end, why not look at introducing
CONFIG_PLATFORM = "Desktop/Server" into the mix?
They really are two very different beasts, and need appropriate decisions for both. You can then apply the appropriate optimizations depending on the platform. Yeah, some has been done, but not nearly enough.
Time to start getting some of those Desktop optimizations into the mainline kernel and just show the competition just how good Linux can be on the desktop.
Linux Desktop users are sick of seeing performance like that of a VW Beatle when their servers run like Ferraris.
The momentum that desktop adoption is seeing it's likely that there WILL be more desktops running Linux over the next 3-5 years than servers.
(Log in to post comments)
Linux: It's Not Just for Servers Anymore (Wired)
Posted Jul 27, 2007 21:38 UTC (Fri) by tzafrir (subscriber, #11501) [Link]
$ wc /boot/config-2.6.18-4-6863535 5342 70781 /boot/config-2.6.18-4-686
There are enough configuration choices already. Kindly ask your distribution to provide you a kernel that is optimized for the desktop and one that is optimized for the server (or build an optimized one yourself). Then you could apply specific optimizations to each type.
Any specific example of an optimization that is good for the desktop and not for the server or vice-versa?
Linux: It's Not Just for Servers Anymore (Wired)
Posted Jul 27, 2007 21:49 UTC (Fri) by einstein (subscriber, #2052) [Link]
> Any specific example of an optimization that is good for the desktop and not for the server or vice-versa?
Sure, for starters, things like HZ=1000
In general, anything that touches on latency-vs-throughput considerations, and such ideas as priority boost for the GUI, to make the OS "feel" more responsive.
Linux: It's Not Just for Servers Anymore (Wired)
Linux: It's Not Just for Servers Anymore (Wired)
Posted Jul 27, 2007 23:35 UTC (Fri) by malefic (subscriber, #37306) [Link]
CONFIG_HZ, CONFIG_PREEMPT, CONFIG_PREEMPT_BKL, CONFIG_IOSHED_CFQ, CONFIG_HIGH_RES_TIMERS etc... Plus you have RSDL/CFS patches available. Additionally, if you want absolute priority fairness, renice and ionice intensive background tasks, renice X, and you'll be running a pretty low-latency desktop.
I regularly have gcc doing some heavy compilation, amarok playing music, firefox with a few dozens of tabs with flash movies in them and a lot of other stuff doing something. And you know what? No latency problems whatsoever. That's on an average box with dual-core processor and 2 gigs of RAM.
I'd say that properly configured Linux beats pretty much every other common OS when it comes to latency and responsiveness on a common desktop workflow on a comparable hardware.
The main point is that optimizations targeted at server workflows do not necessarily make desktop functioning worse.
Linux: It's Not Just for Servers Anymore (Wired)
Posted Jul 28, 2007 10:45 UTC (Sat) by tzafrir (subscriber, #11501) [Link]
> CONFIG_HZ, CONFIG_PREEMPT, CONFIG_PREEMPT_BKL, CONFIG_IOSHED_CFQ,> CONFIG_HIGH_RES_TIMERS
Well, those are existing configuration options already. So if one builds a separate "desktop" and a separate "server" kernel, one can give them different values, right?
> Plus you have RSDL/CFS patches available.
CFS is being merged into 2.6.23 .
> Additionally, if you want absolute priority fairness,
> renice and ionice intensive background tasks, renice X,
> and you'll be running a pretty low-latency desktop.
I'm a bit confused here. Do you suggest anything specific that should be changed in the kernel? I also thought that one of the goals of CFS was not to need renice daemon.
> The main point is that optimizations targeted at server
> workflows do not necessarily make desktop functioning worse.
If the main task of the server is answering as many clients as possible, responding a split-second later is not going to hurt it. However wit hyour configuration it is going to have more context switches and hence worse performance.
Linux: It's Not Just for Servers Anymore (Wired)
Posted Jul 28, 2007 16:33 UTC (Sat) by malefic (subscriber, #37306) [Link]
>> CONFIG_HZ, CONFIG_PREEMPT, CONFIG_PREEMPT_BKL, CONFIG_IOSHED_CFQ,>> CONFIG_HIGH_RES_TIMERS
> Well, those are existing configuration options already. So if one builds a
> separate "desktop" and a separate "server" kernel, one can give them
> different values, right?
Of course. The point was to highlight the options that make difference.
>> Plus you have RSDL/CFS patches available.
> CFS is being merged into 2.6.23 .
I know that
>> Additionally, if you want absolute priority fairness,
>> renice and ionice intensive background tasks, renice X,
>> and you'll be running a pretty low-latency desktop.
> I'm a bit confused here. Do you suggest anything specific that should be
> changed in the kernel? I also thought that one of the goals of CFS was
> not to need renice daemon.
Not exactly. CFS unlike the <=2.6.22 mainline scheduler does not try to be
overly smart and adjust priorities automagically. Instead it tries to
distribute the CPU time between tasks in a fair unbiased fashion.
So the process niceness is pretty much important for the scheduler.
I don't say it's absolutely necessary to renice stuff with CFS. I say that
CFS is much more deterministic when it comes to nice levels. I.e it
makes more sense to renice processes because you're sure that
every nice level proportionally adds 10% (or something like that,
I don't remember) to the process CPU time.
>> The main point is that optimizations targeted at server
>> workflows do not necessarily make desktop functioning worse.
> If the main task of the server is answering as many clients as possible,
> responding a split-second later is not going to hurt it. However wit
> hyour configuration it is going to have more context switches and hence
> worse performance.
Right. The last sentence wasn't directly related to the configuration
options. It's a general idea that increased efficiency and throughput
are beneficial all around.