Slashdot Mirror


Alternative To the 200-Line Linux Kernel Patch

climenole writes "Phoronix recently published an article regarding a ~200 line Linux Kernel patch that improves responsiveness under system strain. Well, Lennart Poettering, a Red Hat developer, replied to Linus Torvalds on a mailing list with an alternative to this patch that does the same thing yet all you have to do is run 2 commands and paste 4 lines in your ~/.bashrc file."

5 of 402 comments (clear)

  1. Re:which one is 'right'? by h4rr4r · · Score: 5, Interesting

    I've done some tests and the result is that Lennart's approach seems to work best. It also _feels_ better interactively compared to the vanilla kernel and in-kernel cgrougs on my machine. Also it's really nice to have an interface to actually see what is going on. With the kernel patch you're totally in the dark about what is going on right now.

    -Markus Trippelsdorf

    right from the article

  2. While the bashrc approach may seem attractive by joeflies · · Score: 4, Interesting

    this is definitely one of those things that I add now, then forget about later, and it becomes a condition that may or may not work when I apply upgrades & patches in the future. Whether or not the .bashrc approach is faster, I think that going down the kernel route makes it more consistently usable.

  3. Lennart is right - the kernel patch is the hack. by neiras · · Score: 4, Interesting

    The kernel patch is the hackish way to do it. They're hard-coding policy settings into a kernel patch. Dumb. The kernel is there to provide the knobs, not to twiddle them for you.

    Lennart's argument is that policy should not be hard-coded into the kernel. He's not saying "everyone should do this in a bash script". He's saying "leave policy settings to userspace mechanisms that can handle them better." Say, systemd for instance.

    Users would be better served by Lennart's approach, I think.

    Funny thing is, most desktop users will not see the benefits of the patch, since most of them never use the terminal to run cpu-hogging kernel builds. All desktop apps share the same cgroup.

    That won't stop hordes of n00bs from claiming ZOMG MAI SYSTEM IS SO MUCH FA$TER NOW OMG!

  4. Re:Also from the article by arth1 · · Score: 5, Interesting

    What I don't get is why he uses

    if [ "$PS1" ]; then

    instead of

    if [ -t 0 ]; then

    Why the latter? Because it works, that's why:

    # sh -c '[ "$PS1" ] && echo tty detected'
    #

    # sh -c '[ -t 0 ] && echo tty detected'
    tty detected

    The other way around, if a user has set PS1 in .profile, you'll get false positives, and cron jobs that will consume more than their fair share of resources.

  5. Re:Also from the article by msclrhd · · Score: 4, Interesting

    There is no one single magic bullet to say do XYZ and the desktop usage will be super awesome responsive. That is because there are different situations and conditions that can affect performance.

    This specific patch is to handle the case where running background tasks (updating, backup, searching the filesystem to index files and other things the computer can do) that eat up CPU causes the system to become unresponsive (especially on lower spec machines that don't have enough CPUs to handle moderately complex workloads). The reason the "make -j64" was used was not to say that this is great for developers or people building stuff in the background while watching video (which it will be), but to simulate the system under stress.