Page 13 of 23 FirstFirst ... 31112131415 ... LastLast
Results 121 to 130 of 225

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

  1. #121
    Join Date
    Aug 2009
    Posts
    2,264

    Default

    Quote Originally Posted by misiu_mp View Post
    Interesting to know what scheduling tricks do they use for the UI. Is it a generic solution or could it be just one UI process with higher priority?
    A lot of things, realy. It's not some genious algorithm, though. It is done in the kernel, but managed from userspace. A sort of avarge on which priority a process has and what the physical user is doing on the screen. So for example if the user maximises a window, then the maximised window app gets more priority. That sort of thing.

    Watch the Vista kernel dev interview on channel9. Windows 7 is actualy Windows Vista but the UI gets some slice of what the user is doing trick, combined with optimizations of the UI app itself.

    Don't forget that Windows tightly integrates the UI with the kernel, where on Linux it is just an afterthought with X.org, that currently happens to have its Gallium3D driver framework partialy into the Linux kernel now, but there is no kernelspace<->userspace management voodoo going on

  2. #122
    Join Date
    Nov 2010
    Posts
    6

    Default

    Quote from Lennart Poettering:

    H
    ere's my super-complex patch btw, to achieve exactly the same thing
    from userspace without involving any kernel or systemd patching and
    kernel-side logic. Simply edit your own ~/.bashrc and add this to the end:

    if [ "$PS1" ] ; then
    mkdir -m 0700 /sys/fs/cgroup/cpu/user/$$
    echo $$ > /sys/fs/cgroup/cpu/user/$$/tasks
    fi

    Then, as the superuser do this:

    mount -t cgroup cgroup /sys/fs/cgroup/cpu -o cpu
    mkdir -m 0777 /sys/fs/cgroup/cpu/user
    Original post: http://marc.info/?l=linux-kernel&m=128993140308849&w=2

    This sounds easier to folks having issue compiling the kernel.

  3. #123
    Join Date
    Nov 2010
    Posts
    6

    Default

    Read more on the original post, it seems that the responsiveness only exhibits when you have a huge process running in the terminal.

    Quote from Lennart Poettering:
    http://marc.info/?l=linux-kernel&m=128993935321081&w=2
    Heck, the patch wouldn't even have any effect on my machine (and I am
    hacker), because I tend to run my builds from within emacs. And since
    emacs has no TTY (since it is a X11/gtk build) it wouldn't be in its own
    scheduling group.

  4. #124
    Join Date
    Sep 2010
    Posts
    67

    Default

    I think OSX does a similar thing with it's apps. This isn't based on any technical knowledge of it but from rather brief usage of it over a period. One thing I noticed is that OSX seems to give the current app that the user is using more priority than other OSs do. With some apps running in the background I noticed they tended to suffer quite noticably while the app in focus ran just fine.

  5. #125

    Default

    Gentoo Linux users have backported this patch to kernels 2.6.35.8 and 2.6.36:

    http://forums.gentoo.org/viewtopic-p...7.html#6489517

  6. #126
    Join Date
    Oct 2009
    Posts
    845

    Default

    Quote Originally Posted by Michael View Post
    Jeg er ikke fra Sverige, men som Skandinavia landene.

    [And am bad with speaking Swedish but slightly less bad with Norwegian , but you all seem to know all the scandic languages due to the similarities ]
    Heh, well actually I can't pride myself with knowing finnish, unless 'perkele' counts, oh and of course 'olen tässä' which means 'you are here', which can be very important information when you are drunk on a ferry and trying to find your cabin

    Quote Originally Posted by devius View Post
    How about you finnish/swedish/norwegian-speaking guys start including subtitles in the posts so the rest of us know what you're talking about. Or do I have to start insulting everyone in portuguese?
    Trust me, you're not really missing out on anything

  7. #127
    Join Date
    Jun 2010
    Location
    Italy
    Posts
    20

    Default

    Update:
    After the fight Linus vs Lennart (kernel vs user) at the end Lennart implemented the same thing the patch does in systemd (check out latest commit).

    If the requisite is :
    The latency improves only by isolating tasks in containers (cgroups)
    In think Systemd acheives this in the right way:
    1. all is configurable (with pam-systemd you can choose whatever controller you like (cpu, memory, block by which every user isolate his tasks);
    2. systemd knows better what is a session (the kernel doesn't even know it);
    3. anytime, you can see what is going on (do a pstree on /sys/fs/cgroup);

    I would like to point out that this great work comes from the following history:
    • Con Kolivas sd scheduler;
    • Ingo Molnar cfs scheduler;
    • Ingo introduce Paul Menage cgroups in cfs scheduler;
    • Mike Galbraith in-kernel autogrouping based on cfs-cgroup scheduler;
    • Lennart Pottering autogrouping in user-space (systemd);


    This is a great story of success.
    Thanks to all people involved

    Marco

  8. #128
    Join Date
    Aug 2007
    Location
    Poland
    Posts
    215

    Default

    Thank you, Marco for detailed information.

    So with systemd it's not needed to patch kernel now?
    What's the oldest kernel that did get cgroups that systemd will benefit from it?

  9. #129
    Join Date
    Jun 2010
    Location
    Italy
    Posts
    20

    Default

    Quote Originally Posted by xeros View Post
    Thank you, Marco for detailed information.

    So with systemd it's not needed to patch kernel now?
    What's the oldest kernel that did get cgroups that systemd will benefit from it?
    With latest systemd (today commits) you don't need to patch kernel: systemd solution is alternative to Mike Galbraith patch and achieves the same goal (isolating tasks in cpu groups by user session using libpam-systemd). I think putting the things together will cause some mess.

    As far as I know all the kernel with cpu cgroup are complaiant with systemd. But systemd requires at least
    • cgroup mounted on /sys/fs/cgroup (i dont know which commit is in which kernel, perhaps not even in 2.6.36, but easily to backport);


    To work at best kernel needs
    • a little patch fixing bug concerning moving tasks accross cgroups;


    Marco

  10. #130
    Join Date
    Jun 2010
    Location
    Italy
    Posts
    20

    Default

    Sorry, I forgot the announce of new systemd features:

    http://lkml.org/lkml/2010/11/17/502

    marco

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •