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

81–90 of 98 posts

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

#81

Post by rcoder »

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.

Since this only groups processes according to TTY/PTY, it should only affect jobs kicked off by an interactive login session. Background daemons, cron jobs, and the like all run detached from a controlling terminal, so their priority should be unaffected.

As long as the fixed overhead of the patch is small (which the linked thread seems to indicate) this should be a sizable win for desktop Linux boxes without much downside for server loads.

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

#82

Post by rcoder »

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…

Pluggable schedulers have been proposed, implemented, and shot down by Linus several times in the past. IANAKH, but Linus's argument seems to basically boil down to this: for a monolithic kernel, delegating something as central as task scheduling to pluggable modules is a pretty big hit in terms of latency and complexity vs. just putting the best, most tightly-tuned scheduler you can smack dab in the heart of the beast.

: I Am Not A Kernel Hacker

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

#83

Post by juiceandjuice »

SkyMarshal wrote: post #66
riffraff wrote: post #30

Earlier quoted context omitted.

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 ;)

It probably approximates Linus's typical workload, which I imagine involves constant compiling and testing while compiling. He's probably still CPU bound.

make?

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

#85

Post by ra »

SkyMarshal wrote: post #84
sandGorgon wrote: post #42

Earlier quoted context omitted.

anybody know a ubuntu ppa for this ?

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.

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

#86

Post by reinhardt »

krakensden wrote: post #77
ludwigvan wrote: post #50

It makes me wonder whether it is a sign that desktop responsiveness has been neglected by the kernel devs which possibly prioritize server issues. I had read a Google engineer suggesting Canonical should hire decent kernel developers : " P.S. Next thing for Ubuntu to learn --- how to pay their engineers well enough, and how to give them enough time to work on upstream issues, that once they gain that experience on Ub…

Canonical has some decent kernel developers, just... not enough, especially for their install base and the amount of work they do.

At least they're aware of it; just yesterday they posted this: http://webapps.ubuntu.com/employment/canonical_KD%20PG3/

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

#88

Post by c00ki3s »

Jach wrote: post #80
riffraff wrote: post #10

Earlier quoted context omitted.

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

Gentoo recommends -jN+1 where N is the number of physical and virtual cores.

Say I have a quadcore with hyperthreading, does this mean 4 + 8 + 1? Or is it either the physical or the logical cores (whichever is higher)?

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

#89

Post by ars »

c00ki3s wrote: post #88
Jach wrote: post #80

Earlier quoted context omitted.

Gentoo recommends -jN+1 where N is the number of physical and virtual cores.

Say I have a quadcore with hyperthreading, does this mean 4 + 8 + 1? Or is it either the physical or the logical cores (whichever is higher)?

How do you get 4 + 8? But anyway, it's logical cores, not physical ones.

The kernel can multi-task processes, but each process still gets exclusive use of the CPU when it runs. So if it doesn't need an adder, that adder sits idle.

With hyperthreading you can run two processes at once and the CPU merges them at the instruction level making maximum use of the components on the CPU.

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

#90

Post by Confusion »

rcoder wrote: post #81
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.

Since this only groups processes according to TTY/PTY, it should only affect jobs kicked off by an interactive login session. Background daemons, cron jobs, and the like all run detached from a controlling terminal, so their priority should be unaffected. As long as the fixed overhead of the patch is small (which the linked thread seems to indicate) this should be a sizable win for desktop Linux boxes without much do…

I think gxti is asking for a quantification of 'without much'.
Post reply on HN