Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The ~200 Line Linux Kernel Patch That Does Wonders

phoronix.com

Post reply on HN
Print view View original

51–60 of 98 posts

Re: The ~200 Line Linux Kernel Patch That Does Wonders

#51

Post by eru »

someone_here wrote: post #23
krschultz wrote: post #9

Earlier quoted context omitted.

It isn't hard to do, but a painless way to learn is to install a ubuntu 10.10 instance in a virtualbox and try it all in the box. If you screw up, who cares. After you have been through the process once it won't be intimidating to do it for your real OS.

Should I be pulling in the source from apt and applying the patch that way? I am forced to use nvidia's drivers, and I fear the vanilla kernel may not work.

Don't be too afraid. Nvidia's driver come as a module. There's lots of documention out there, how to make them work.

Re: The ~200 Line Linux Kernel Patch That Does Wonders

#52

Post by zemanel »

AngryParsley wrote: post #40
zemanel wrote: post #36

Earlier quoted context omitted.

yes, i'd like that very much but the current prices are too high for me.

You can afford a MacBook Pro but you can't afford an SSD that costs 25% of that? (A really fast expensive SSD is around $400.)

erhm yeah basically :) recently said "no more", quit my job, bought a MBP and struggling to get bootstrapping work. One wave short of a ship wreck? Yes. Free to be creative, free from LAMPish crappy apps, free to hack away Dojo/Django/Postgres apps, free from bosses who don't code? Fuck yeah

Re: The ~200 Line Linux Kernel Patch That Does Wonders

#53

Post by sp332 »

bobf wrote: post #24

I don't follow kernel development extremely closely, but it fascinates me that people are still actively working on the kernel's scheduler and achieving a "huge improvement" like this.

Pretty much all of the performance enhancement in the kernel has been toward server-type high-throughput applications. This was mainly because subjective things like jutter and interactivity lag are really hard to measure objectively (using existing performance benchmarks), and it's really hard to optimize for something when you have no benchmarks and no regression tests. Desktop-style interactivity improvements have been advancing only recently. The cgroups feature has actually been available in the kernel for some time, but distros weren't using it. This new patch sort of auto-configures cgroups per-TTY.

Re: The ~200 Line Linux Kernel Patch That Does Wonders

#54

Post by burgerbrain »

AngryParsley wrote: post #40
zemanel wrote: post #36

Earlier quoted context omitted.

yes, i'd like that very much but the current prices are too high for me.

You can afford a MacBook Pro but you can't afford an SSD that costs 25% of that? (A really fast expensive SSD is around $400.)

Spending a thousand or two on a computer is a hell of a lot easier to justify than spending several hundred on a harddrive. Particularly when you can find less fancy harddrives for a fraction of that. SSDs are far more of a luxury item than laptops.

Re: The ~200 Line Linux Kernel Patch That Does Wonders

#55

Post by cookiecaper »

Anything from Phoronix should be taken with a grain of salt. This looks legit since it has a message from Linus praising the patch, but there have been several similar stories out of Phoronix that turn out to be hoaxes or misunderstandings.

That said, such a patch would be pretty rad.

Re: The ~200 Line Linux Kernel Patch That Does Wonders

#56

Post by acdha »

AngryParsley wrote: post #35
zemanel wrote: post #11

i whish something similar could be ported to BSD/Darwin, OSX. I have a MBP 6,2 (i5) with 4GB mem/5400 rpm disk and it's quite easy to hog it down, to almost unbearable sometimes.

5400 rpm disk Even with a perfect scheduler you're going to have to wait on I/O. Disk speeds are the limiting factor on most machines, and this goes double for laptops. I highly recommend getting an SSD.

But not anywhere near what we see: BeOS on my 1999-era system handily trumped Linux, Windows or Mac OS on 2010 hardware (non-SSD) when it came to interactive performance, solely because it had a better I/O scheduler. Back then, I could surf the web without being constantly reminded that I had Mozilla compiling & DV streaming off of a camera; today I'm regularly reminded that work is happening in the background.

This isn't to say that there aren't real limits or that BeOS was perfect (far from it) but simply that there's considerable room for improvement before we start hitting theoretical limits.

Re: The ~200 Line Linux Kernel Patch That Does Wonders

#57

Post by yason »

Makes me wonder that don't they have kernel APIs for process schedulers and I/O schedulers by now? The scheduler tweaks have been going on for ages.

Instead of compiling a single new kernel module (or downloading it prebuilt from an apt repo or a PPA) and kicking it in with modprobe, we now need to obtain the sources for the whole kernel, apply the patches, configure, build, and deploy. Sure Debian/Ubuntu has that partially automatized but it's still a pain.

At least I'll wait for stock 2.6.38 on Ubuntu and cross my fingers they put this patch in.

Re: The ~200 Line Linux Kernel Patch That Does Wonders

#58

Post by wtallis »

yason wrote: post #57

Makes me wonder that don't they have kernel APIs for process schedulers and I/O schedulers by now? The scheduler tweaks have been going on for ages. Instead of compiling a single new kernel module (or downloading it prebuilt from an apt repo or a PPA) and kicking it in with modprobe, we now need to obtain the sources for the whole kernel, apply the patches, configure, build, and deploy. Sure Debian/Ubuntu has that pa…

All this patch does is add a smarter default for just such an API: cgroups.

Obviously, any change to the default behavior is going to require building a new kernel.

There may be good reasons for completely plugable schedulers, but this is not one of them.

Re: The ~200 Line Linux Kernel Patch That Does Wonders

#60

Post by wmf »

yason wrote: post #57

Makes me wonder that don't they have kernel APIs for process schedulers and I/O schedulers by now? The scheduler tweaks have been going on for ages. Instead of compiling a single new kernel module (or downloading it prebuilt from an apt repo or a PPA) and kicking it in with modprobe, we now need to obtain the sources for the whole kernel, apply the patches, configure, build, and deploy. Sure Debian/Ubuntu has that pa…

Linus intentionally will not allow the scheduler to be modularized to force people to develop the One True Scheduler rather than a bunch of workload-specific ones.
Post reply on HN