Ingenuity has always been a hallmark of the Linux world, but sometimes the community really outdoes itself.
Take the 233-line patch to the Linux kernel’s scheduler that was recently created by developer Mike Galbraith, for example. With the ability to reduce the average latency of the desktop by as much as 60 times under heavy loads, the patch even drew kudos from Linus himself, who said it enables group scheduling to go “from ‘useful for some specific server loads’ to ‘that’s a killer feature.'”
One could hardly ask for praise much higher than that, and the Slashdot crowds were soon echoing Linus’ enthusiasm with gusto.
Smooth 1080p Video – ‘Astounding’
“For those that haven’t tried it without the patch, a multithreaded kernel compile will typically peg a modern multicore CPU at 100% and will even give you drunken mouse syndrome,” wrote Slashdot blogger morgan_greywolf, for example. “Just being able to scroll around a browser window while doing a lengthy make -j64 is impressive.
“Being able to watch 1080p video smoothly is … astounding,” morgan_greywolf added. “Especially when you consider the minimum CPU requirement for 1080p H.264 playback is a 3 GHz single core or a 2 GHz dual core.”
But wait — there’s more!
Just days after Phoronix originally brought the patch to light, an even simpler alternative from Red Hat developer Lennart Poettering surfaced that requires just two commands and four lines of code.
Knowing the Linux community’s propensity for debate, it wasn’t too surprising to see the Slashdot masses jump on the topic and turn it into a debate on the question of how they differ and which approach is best.
‘Do It Once and Leave It Built-In’
“The kernel patch groups processes by owning TTY. The bash shell change groups them by session,” wrote Slashdot blogger Anonymous Coward, citing an explanation (for subscribers) on LWN.
Alternatively: “The differences between the change to the kernel and the shell script are basically two: one, they apparently have slightly different algorithms for choosing how to group the processes,” brion wrote.
“That’s not due to it being in-kernel vs out-of-kernel, though — that’s just because they are slightly different,” brion added. “Both can be implemented in both ways, and both work with the same actual implementation mechanism — simply one works from userspace through the interfaces and one’s built-in to the kernel.”
Auto-tuning behavior “that’s built in will probably be the most reliable, easiest, and best-performing way to do this, rather than requiring every Linux distribution to ensure that they’re running the same extra scripts and keeping the userspace stuff in sync,” brion concluded. “Do it once and leave it built-in to the kernel.”
And again: “One requires a kernel patch. One uses functionality *already present in the kernel* to do the same thing,” chimed in spun. “Testing reveals the one that doesn’t require a kernel patch is more responsive. You tell me which is best.”
A Script for Ubuntu
The saga continued last week when an Ubuntu Life user created a script that automatically applies the alternative fix in Ubuntu.
Does life get any better than this??!
Of course, it’s true that the main people to notice the above changes will be those running heavy loads. Nevertheless, it would be hard to find a better example of the pure genius that is FOSS.
Throughout the streets and watering holes of the Linux blogosphere, much of the conversation in recent days focused on these new developments. Linux Girl set out to learn more.
‘I’m Not Done Benchmarking’
“I’m trying the two line patch now and it seems to help somewhat, but I’m not done benchmarking,” Montreal consultant and Slashdot blogger Gerhard Mack told Linux Girl.
“It seems like either ought to work, but as I don’t run make -j64 while I play games, I’m not amazingly worried about either,” Hyperlogos blogger Martin Espinoza offered. “The things that are slow for me are slow no matter what is running, like Flash.”
Indeed, “this patch mostly will benefit users who create heavy loads on the CPU,” blogger Robert Pogson added. “I do not have that unless an application loops, but I do keep my terminal server busy.”
It will be interesting, however, “to see if this patch helps distribute the load users care about: their screens,” Pogson opined. “The alternative approach should do the same thing under explicit control of the system administrator. I like that.”
DIY vs. ‘Make It Easy’
The debate over the two original approaches, meanwhile, “shows the division in the Linux camp,” Slashdot blogger hairyfeet opined.
“On one side you have the DIYers with the patch; on the other, the ‘make it easy’ option with an update that will end up rolled in the kernel,” he explained.
“Who is right? Well, I still say that Linux needs to be looking at Apple and MSFT on the usability standpoint, so I’d go with the easier option that is rolling it in a kernel update and passing it down through the distro updates,” concluded hairyfeet.
‘I’m Not in a Rush’
Indeed, “like most people, I’ll wait until my distro — OpenSUSE — rolls it out as part of an upgrade,” said Barbara Hudson, a blogger on Slashdot who goes by “Tom” on the site. “I’m not in a rush.”
As for the debate about “which is better — the kernel patch or the command-line ‘hack’ — I’ll stick with the kernel patch,” Hudson said.
“Not that it will make much of a difference in the grand scheme of things,” she opined. “Nowadays computers are already ‘good enough’ to do what I want most of the time; the only exception is Firefox occasionally pigging out, and that’s easily fixed with a quick ‘kill -9.'”
In fact, “I’d be more excited over Firefox getting a separate process for each tab, so that one slow web site doesn’t kill everything,” Hudson added. “Experience shows that just running plugins in a separate process is not enough.”
Loading ...
In the end, one is not easier than the other since both can be rolled out by the distro. I’m guessing that no matter what options wins out we will see it become a standard addition by Linux distros since only the DIY crowd uses anything but precompiled kernel or installation provided scripts.