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

71–80 of 98 posts

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

#71

Post by nitrogen »

pmr_ wrote: post #45
riffraff wrote: post #10

Earlier quoted context omitted.

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

The number of jobs to run for an optimal compile time can be quite confusing. If none of the files you are going to compile are cached it is alright to run a lot more jobs then usual as a lot of them are going to wait for the disk I/O. After that twice the jobs then you have cores is mostly appropriate.

According to Con Kolivas's benchmarks, with the BFS scheduler you just do make -j [numprocs] for best results. I can't recall if he was accounting for disk cache, though.

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

#72

Post by nitrogen »

tbrownaw wrote: post #34
jws wrote: post #21

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…

> 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. Yes, and yes. Previously you could set things like this up explicitly, this makes it (optionally) automatic. > Why is this an improvement over just nicing the "make -j64" into the basement That gives you... I think 10%…

So does "tty" or "terminal" in this context also refer to pseudoterminals, so that each xterm/konsole/gnome-terminal instance gets its own scheduling group as well?

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

#73

Post by nitrogen »

someone_here wrote: post #62
eru wrote: post #51

Earlier quoted context omitted.

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

How do you stay up to date with Ubuntu's changes?

Ubuntu's changes to the kernel usually just backport new kernel features/fixes to an older kernel version. Compiling a fresh mainline kernel will get you most or all of those fixes. The source code shim that loads Nvidia's blob can be automatically recompiled by dkms when you boot into the new kernel. Installing the nvidia-kernel-dkms (or similarly-named) package should make that happen.

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

#74

Post by nitrogen »

sp332 wrote: post #19
eru wrote: post #15

Earlier quoted context omitted.

Yes, it's indeed quite easy to compile your own kernel, and virtualbox is a good idea. (For compiling you won't actually need the virtualbox, but for booting from it without worries that you broke something, virtualbox sure comes in handy.) I use "sudo make menuconfig", which gives you a text-based menu, there may also be a graphical version. I would not recommend "sudo make config", as that only gives you a long lis…

# sudo make xconfig should give you a point-and-click interface to the same menu. I haven't used it in years, but it was pretty clunky back then. It's just nicer to poke around in than the text-mode menu.

You should probably start with the .config from your distribution's kernel, rather than the stock vanilla kernel .config. It's usually in /boot, so in make menuconfig/make xconfig you choose to load an existing saved config, then select /boot/config-[kernel version] (assuming your distribution installs the kernel config there). Some kernels may also provide the .config contents in /proc/kconfig (or something similar -- can't remember the exact filename).

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

#75

Post by nitrogen »

slowpoison wrote: post #59

So, is this really going to help, if I don't have tons of busy processes (a'la "make -j64") running?

It can help prevent background processes (like disk indexing or manpage index updating) from interfering with interactive processes.

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

#76

Post by rbanffy »

derobert wrote: post #61
rbanffy wrote: post #46

Earlier quoted context omitted.

How many simultaneous threads will your next computer be able to run? Chances are it already runs at least two, most probably four. It's not unreasonable to see 4 and 8-threads as the norm. Also keep in mind we are only considering x86s. SPARCs, IIRC, can do up to 64 on a single socket. ARM-based servers should follow a similar path. BTW, a fully-comfigured MacPro does 12. A single-socket i7 machine can do 12. I neve…

Dual-socket i7 is called Xeon. There are dual-socket and even quad-socket 8-core hyperthreaded xeons (the Xeon L75xx series). A 1U Intel with 64 threads will set you back about $20k. AMD has 12-core chips, so you can get 48 cores in 4 sockets there. (But I think they only have one thread per core)

So, -j64 seems quite reasonable, if you have $20K around... ;-)

Personally, I would spend a part of the money on 2048x2048 square LCD screens. They look really cool.

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

#77

Post by krakensden »

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.

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

#78

Post by tbrownaw »

nitrogen wrote: post #72
tbrownaw wrote: post #34

Earlier quoted context omitted.

> 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. Yes, and yes. Previously you could set things like this up explicitly, this makes it (optionally) automatic. > Why is this an improvement over just nicing the "make -j64" into the basement That gives you... I think 10%…

So does "tty" or "terminal" in this context also refer to pseudoterminals, so that each xterm/konsole/gnome-terminal instance gets its own scheduling group as well?

I would be very surprised if it didn't, this should be the same as what shows under the "TTY" column from "ps -f".

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

#79

Post by leif »

astrange wrote: post #69
leif wrote: post #27

Earlier quoted context omitted.

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.

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.

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

#80

Post by Jach »

riffraff wrote: post #10
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…

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.
Post reply on HN