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

21–30 of 98 posts

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

#21

Post by jws »

I don't think I've managed to piece all this together, perhaps someone can fill in the blanks.

• The patch automatically creates a task group for each TTY.

• The patch automatically assigns each new process to the task group for its controlling TTY.

• In the case where there are large (>cores) numbers of cpu bound jobs, the latency of interactive jobs is vastly improved.

I think the piece I'm missing is the behavior of the scheduler. Does it now make its decisions based on task group cpu consumption instead of process? I saw options to that effect back around 2.6.25.

Why is this an improvement over just nicing the "make -j64" into the basement and letting the interactive jobs have their way as needed? (Likely possibilities are that it is automatic, or maybe there is something about disk IO scheduling happening from the task groups as well.)

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

#23

Post by someone_here »

krschultz wrote: post #9
hippich wrote: post #7

I am newbie when it comes to compiling kernel. Is it a pain to do with stock ubuntu 10.10? Sometimes I run something heavy on my laptop and desktop freezes annoy me. If this patch will allow me to get around it - I would be glad to try it out. Anyone having url of some niuce tutorial to compile new kernel for ubuntu 10.10?

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.

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

#25

Post by azim »

jedbrown wrote: post #16
adobriyan wrote: post #12

Earlier quoted context omitted.

make -j$(2N + 1) is roughly where minimal compile times are.

Where N is the number of physical cores? I do not use hyper-threading (it tends to be bad for the floating point and bandwidth limited operations that I do), but usually find minimal compile times at N+1 jobs (but with little penalty for several more).

Out of curiosity, What types of applications are you running where HT hurts performance?

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

#26

Post by adobriyan »

jedbrown wrote: post #16
adobriyan wrote: post #12

Earlier quoted context omitted.

make -j$(2N + 1) is roughly where minimal compile times are.

Where N is the number of physical cores? I do not use hyper-threading (it tends to be bad for the floating point and bandwidth limited operations that I do), but usually find minimal compile times at N+1 jobs (but with little penalty for several more).

> Where N is the number of physical cores?

Yes. Dunno about HT, never used a box with it.

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

#27

Post by leif »

gxti wrote: 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.

There isn't one. It's an existing option in the kernel, you can configure cgroups that way already, but most people don't do this so the feature is wasted. All this patch does is roughly approximate a decent-looking cgroup configuration by splitting processes by tty automatically.

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

#28

Post by [deleted] »

pietrofmaggi wrote: post #3

It's not down for me... but here's the text: In recent weeks and months there has been quite a bit of work towards improving the responsiveness of the Linux desktop with some very significant milestones building up recently and new patches continuing to come. This work is greatly improving the experience of the Linux desktop when the computer is withstanding a great deal of CPU load and memory strain. Fortunately, th…

[deleted]

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

#29

Post by burgerbrain »

rufo wrote: post #13
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.

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…

What kind of application blocks on disk IO but nothing else for extended amounts of time? I'm having a hard time seeing how installing an SSD and maxing out your cores are terribly related otherwise.

SSDs do a lot to reduce loadtimes, and thus make your computer seem much faster, but they do little for making your programs run full-speed-ahead constantly. Most every application out there blocks on network connections, user input, or just plain old throttles itself.

For that matter, I can max out my cores just using a couple dozen instances of mplayer, playing several movies at once off of a usb removable harddrive...

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

#30

Post by riffraff »

fragmede wrote: post #17
riffraff wrote: post #10

Earlier quoted context omitted.

OT: is "make -j64" overkill unless you have dozens of cores or am I missing something?

You're right - but that was the point. The patch was trying to fix problems with the process scheduler, and "-j64" is going to make lots of processes that want to do work and need scheduling.

thanks, but then the "that is my tipical workload" thingy does not hold, as you rarely have >60 cpu bound processes running at the same time. Well, flash player in chrome notwithstanding ;)
Post reply on HN