Announcement

Collapse
No announcement yet.

More Patches To Improve Linux Desktop Responsiveness

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    What impact will these patches have on throughput for servers that don't require instantaneous response times? Will there be a way to disable these patches for servers if they are merged into mainline?

    I don't know about this patchset in particular, but frequently, responsiveness issues are a direct tradeoff with throughput and efficiency. The efficiency side: For better responsiveness, the CPU has to be awake a lot, constantly processing events to make things "respond" as quickly as possible. The throughput side: Aside from scheduler thrashing issues that may interfere with processes' ability to get a consistent stream of work done, the other problem with most responsiveness patches is that it creates a lot of overhead in terms of context switches, cache flushes, and IPIs. This can reduce the amount of operations per second that can be performed on the CPU.

    So for servers, you want to line up as many bowling pins as you can, and then bowl a strike, even if it takes you time to line them up. For desktops, you want to throw down one pin, sprint back, grab the bowling ball, hit that one pin, and repeat. Although you can probably set up and hit one pin faster than you can set up 12 or 24 pins and hit them, you've hit less pins in that time than you could have. Hence the throughput vs responsiveness issue.

    I've seen a great many VFS, virtual memory/allocator, and scheduler patches hit mainline in the past year, and sometimes I worry that it's just some guy with a hammer trying to find something that looks like a nail. Phoronix has noted that most kernel releases bring only regressions for typical systems, not improvements. How long have we been sliding down the performance slope, and how far will we keep sliding until everyone is happy?

    I'm all for configurability, though. If there's a patch that has a tradeoff, merge it to mainline and add a config option. We could always use more config options. It warms the Gentoo user's heart, and for the rest of us, it gives the distro kernel maintainers something useful to do, like set the proper options for the desktop vs. server kernels.

    So in closing, if this patch is universally either beneficial or a wash regardless of whether you're in a desktop or server environment, I say merge it without an option. But if we find that it comes with added overhead and reduced throughput for servers, it shouldn't be merged unless it can be made configurable, at least with a Y/N if a module doesn't make sense.

    Comment


    • #17
      Originally posted by allquixotic View Post
      What impact will these patches have on throughput for servers that don't require instantaneous response times? Will there be a way to disable these patches for servers if they are merged into mainline?

      I don't know about this patchset in particular, but frequently, responsiveness issues are a direct tradeoff with throughput and efficiency. The efficiency side: For better responsiveness, the CPU has to be awake a lot, constantly processing events to make things "respond" as quickly as possible. The throughput side: Aside from scheduler thrashing issues that may interfere with processes' ability to get a consistent stream of work done, the other problem with most responsiveness patches is that it creates a lot of overhead in terms of context switches, cache flushes, and IPIs. This can reduce the amount of operations per second that can be performed on the CPU.

      So for servers, you want to line up as many bowling pins as you can, and then bowl a strike, even if it takes you time to line them up. For desktops, you want to throw down one pin, sprint back, grab the bowling ball, hit that one pin, and repeat. Although you can probably set up and hit one pin faster than you can set up 12 or 24 pins and hit them, you've hit less pins in that time than you could have. Hence the throughput vs responsiveness issue.

      I've seen a great many VFS, virtual memory/allocator, and scheduler patches hit mainline in the past year, and sometimes I worry that it's just some guy with a hammer trying to find something that looks like a nail. Phoronix has noted that most kernel releases bring only regressions for typical systems, not improvements. How long have we been sliding down the performance slope, and how far will we keep sliding until everyone is happy?

      I'm all for configurability, though. If there's a patch that has a tradeoff, merge it to mainline and add a config option. We could always use more config options. It warms the Gentoo user's heart, and for the rest of us, it gives the distro kernel maintainers something useful to do, like set the proper options for the desktop vs. server kernels.

      So in closing, if this patch is universally either beneficial or a wash regardless of whether you're in a desktop or server environment, I say merge it without an option. But if we find that it comes with added overhead and reduced throughput for servers, it shouldn't be merged unless it can be made configurable, at least with a Y/N if a module doesn't make sense.
      there probably won't be any if you haven't enabled those features via the debugfs

      so far I've noticed a significant delay when trying to launch applications during heavy (CPU) load and rattling of the hdd so throughput may go down at the cost of interactivity

      someone should do some benchmarks - another job for PTS !

      Comment


      • #18
        Originally posted by allquixotic View Post
        What impact will these patches have on throughput for servers that don't require instantaneous response times? Will there be a way to disable these patches for servers if they are merged into mainline?
        It seems no one pays attention. These patches were introduced in order to improve performance on server load. Linus Torvalds complained that it damaged desktop performance. So this is round two of those patches: improving server performance while not hurting desktop performance.

        I don't get why everyone, including Michael, claims these are desktop improvement patches in the first place. Which is why I don't trust this whole thing, since I care only about desktop issues... Too much misinformation and no real explanation at what these patches do.

        Comment


        • #19
          Originally posted by unimatrix View Post
          Finally! There should be more effort put into the desktop responsiveness. It's the one problem that gives new Linux users that feel of "slowness".
          The problem are graphic drivers and/or related things. Others are probably nearly meaningless compared to causes of 'slowness' related to graphic.

          Comment


          • #20
            Originally posted by nanonyme View Post
            Smooth full-screen Flash video works here just fine with open display drivers on an ATi card. Just takes 32bit Adobe Flash on a 32bit Firefox.
            The same here, but with 32bit flash and 64bit Firefox. Top shows CPU load 110% (Athlon X2 5000+), kwin compositions enabled, 2.6.32 kernel and git version of open source radeon driver from Ubuntu ppa.

            Comment


            • #21
              This is the kid of fixes I want on my lnux desktop. Over the last five years there has been all kinds of eye candy inprovements, and that's great. But what I really want is stable fast 2D graphics.

              As old as X is it is hard to fathom why my windows update so slow as I them drag it around. I suppose a lot of these basic issues are not with X but the companies making the proprietary drivers. Come on AMD and Nvidia lets give a little TLC to X11.

              Comment


              • #22
                Very good news indeed! Any chance that some of these fixes will be backported and included in Ubuntu 10.10?

                Comment


                • #23
                  Originally posted by RealNC View Post
                  I don't get why everyone, including Michael, claims these are desktop improvement patches in the first place.
                  I'm sure it's because the patches come with this comment:

                  Originally posted by TheCoder
                  With this patchset, I got the following results with wakeup-latency.c (a 10ms periodic timer), running periodic-fork.sh, Xorg, make -j3 and firefox (playing a youtube video), with Xorg moving terminal windows around, in parallel on a UP system (links to the test program source in the dyn min_vruntime patch). The Xorg interactivity is very good with the new features enabled, but was poor originally with the vanilla mainline scheduler.
                  which seems to indicate at least some desktop improvement, under certain cirumstances.

                  Comment


                  • #24
                    Originally posted by RealNC View Post
                    It seems no one pays attention. These patches were introduced in order to improve performance on server load. Linus Torvalds complained that it damaged desktop performance. So this is round two of those patches: improving server performance while not hurting desktop performance.

                    I don't get why everyone, including Michael, claims these are desktop improvement patches in the first place. Which is why I don't trust this whole thing, since I care only about desktop issues... Too much misinformation and no real explanation at what these patches do.
                    Are you saying the new patches do NOT improve desktop performance but makes it worse?

                    Comment


                    • #25
                      Originally posted by korpenkraxar View Post
                      Are you saying the new patches do NOT improve desktop performance but makes it worse?
                      If I remember corectly old series of this patches made noticeable latency worse while the measurable latency was better. However, it seems this series should bring improvements to both.

                      Comment


                      • #26
                        there are also some patches in the set wich add configure options which seem aimed at desktop responsiveness.

                        Comment


                        • #27
                          Originally posted by unimatrix View Post
                          Finally! There should be more effort put into the desktop responsiveness. It's the one problem that gives new Linux users that feel of "slowness".
                          Yep, Windows takes for god damn ever to fully load up, but once it is loaded the responsiveness of the interface is snappy in general. Gnome isn't, though, and takes some time to first load, but that is primarily due to everything not being pre-loaded like in Windows. Even the main Gnome app menu is "just another panel app" so it is not completely pre-loaded, AFAIK. I think things like that are the real reasons behind thinking Linux is slow on the desktop. Don't get me wrong though, multitasking with disk I/O + something else is a horrible problem on Linux that these patches will help solve and that will be a huge help.

                          So glad that every now and then the real problems with Linux get some love. I'll take major under-the-hood improvements over eye candy any day, even if Linux does need both to succeed.

                          Next up, a single cross-distro program installer for Linux? Seriously, please? At least PackageKit is well-adopted now... Anything to help friends be less confused when trying to install Linux software from non-repo sources. "What's a static package? What's a binary? What is a tar.gz? How do I run it? What do I click on?" For @#%!% sake...

                          Comment


                          • #28
                            These patches are now part of the Zen-Kernel sources: http://git.zen-kernel.org/?p=kernel/....git;a=summary

                            If you do not want to use our master branch, we keep each feature available in separate branches that are based on vanilla linux.

                            The branch cfs-low-latency-features is available in our git repository and you may view it through gitweb here: http://git.zen-kernel.org/?p=kernel/...tency-features

                            Comment


                            • #29
                              Originally posted by damentz View Post
                              If you do not want to use our master branch, we keep each feature available in separate branches that are based on vanilla linux.
                              Vanilla is a flavor in its own right. :P

                              Comment


                              • #30
                                Originally posted by Yfrwlf View Post
                                Yep, Windows ... What do I click on?" For @#%!% sake...
                                Linux distro's are multiflavor things. There will always be a zillion distro's simply because "we can". You can hate it but that will only make your day worse. Better to accept it and see the positive side of it: users can have Linux the way they like it best.

                                Comment

                                Working...
                                X