Live data from Hacker News

The ~200 Line Linux Kernel Patch That Does Wonders

phoronix.com

91–98 of 98 posts

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

#91
post #32
post #13

Earlier quoted context omitted.

What sort of tasks? FWIW, I had a similar configuration to yours (just an older MBP) and installing an SSD helped immensely . I can hit 200% CPU load and not even realize it until the fans kick in…

I know the subject is pretty much Apple's and oranges but i'm currently running: - Terminal with 2 tabs - firefox with 2 tabs - chrome with about 9 - gaim and skype - iTunes streaming soma.fm - Netbeans with an opened project - jEdit - Colloquy - Postgres instance and as soon as i booted Windows XP in VMware, well, took me a while to be able to reply to this post (after the vm settled). I also that you might be sayin…

Chrome doesn't behave with limited cpu/ram. It likes to "burst". I generally close it when doing anything like gaming or VMing much.

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

#92
post #65
post #49

Earlier quoted context omitted.

Your typical workload sounds almost exactly the same to mine - right down to VMware temporarily killing OS X performance. Not that Anonymous Guy On HN is worth much, but get an SSD - it'll be the best upgrade you've ever purchased. (Or maybe I just needed to sidegrade to Linux. :)

Do you have a suggestion on a good and large SSD? And what did you install it into?

The Intel SSDs are good; they top out at 160GB and they're not as fast as some of the newer drives - but their track record is nearly flawless. It's what I have, but I ordered one the minute it was posted on Newegg last year. Some of the newer Sandforce-based drives are supposed to be good, though you'll want to pick one from a reliable manufacturer and with a stable firmware. If you have a Mac, OWC[1] is a good choice, as I believe they have firmware that garbage-collects HFS+, which helps to keep the SSD as fast as possible. I also think OCZ is good, but check reviews to make sure people aren't having too many problems.

You can also get a brackets that replaces your optical drive, and allows you to fit a 2.5" HDD. I have one in my 17" non-unibody MBP, and it's really the best of both worlds - I keep OS X, my working files and apps on the SSD, along with my main Windows XP web testing VM. My iTunes library, media, and games stay on the HDD, along with a Boot Camped copy of Windows 7 (though it's a pain to get the installer to run without an internal optical drive). I keep a cheap Samsung bus-powered DVD burner in my bag, but in reality I rarely need it. I think OWC sells a bracket for Macs, but if you can figure out exactly which bracket you need, a site called newmodeus.com sells them for almost every laptop ever made for considerably less.

I really do believe my SSD is the best upgrade I've ever spent money on; no computer I use from now on will be without one. It's not so much that the computer is faster; it's more the feeling that the computer does not grind to a halt or slow down, no matter what's going on. (I may have compared my computer to the Terminator amongst friends once or twice… it just doesn't slow down.)

1: macsales.com

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

#93
post #85

Earlier quoted context omitted.

Do they put kernel patches in PPAs?

No, but you can make a deb of a patched kernel and compile that for PPA distribution. It wouldn't be very difficult to make, I would expect to see one in the next 24 hours or so. Be wary of getting your kernel from a PPA though - consider it experimental.

Thanks, I've only used PPAs for apps and such, didn't realize people put kernels up too. Though like you say, probably would only use that for a virtual machine instance, will wait till the next kernel patch for my base workstation.

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

#94
post #79

Earlier quoted context omitted.

Of course there will be a regression if you change the scheduler policy. ck tried something similar to this and mplayer performance suffered with it (though I don't remember the details). It also broke gnome-startup because it assumed some specific schedule ordering, though this patch is more limited so it might not.

When your application breaks because of scheduler ordering , You're Doing It Wrong.

Yeah, well, kernels need to support existing programs…

By the way, your post is the single most obvious statement I've read this year. You got upvoted just because you capitalized some words?

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

#95
post #79

Earlier quoted context omitted.

When your application breaks because of scheduler ordering , You're Doing It Wrong.

Yeah, well, kernels need to support existing programs… By the way, your post is the single most obvious statement I've read this year. You got upvoted just because you capitalized some words?

I got upvoted because I'm right. Kernels don't need to support horribly designed programs just because they exist, just like they don't need to support horribly designed programs that don't exist yet. Kernels support an interface and that's it. If you write code that abuses the interface, get ready to become a regression, and that'll be your own fault.

(TBH I have no idea why I got upvoted, it wasn't that insightful, but I stick by what I said)

(EDIT: I'm talking about gnome-startup. That's a stupid regression that never should've happened. The mplayer performance bug is totally understandable if you're mucking with the scheduler. What we really need is for someone (distros?) to pick up cgroups and provide a nice UI for it, some sane but nondestructive defaults, etc. Until then, this is a nice patch that keeps badly behaving programs from dragging down the entire system. At the very least, we mostly get user separation in multi-user environments.)

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

#96
post #22

So what's the downside? You almost never get optimizations like this for free. The post hints that this is also good for server workloads, but what suffers? Realtime would, but realtime usually involves a different scheduler anyway.

The downside is that a bunch of processes started from one TTY doesn't get as much CPU as before. It basically shifts the scheduling granularity a level higher from processes to (interactive) sessions. Because that's what the question is: on which level do we want to have a fair scheduling? For a desktop user, processes have little meaning. Sessions, instead, are much more useful because they correspond better to his different tasks, for which he expects that the CPU power is distributed in a fair way.

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

#98
post #70

Earlier quoted context omitted.

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.

Agreed. My lizard brain tells me that too. When we buy a faster processor, we are valuing our time against the cost of the processor. I just have to convince the lizard inside to do the same with disk wait times.

For most desktop workloads the disk wait times exceed the processor wait times by orders of magnitude.
Post reply on HN