| 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 23:35 UTC (Fri) by malefic (subscriber, #37306)In reply to: Linux: It's Not Just for Servers Anymore (Wired) by mbottrell
Parent article: Linux: It's Not Just for Servers Anymore (Wired)
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.
(Log in to post comments)
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.