Announcement

Collapse
No announcement yet.

ULatencyD Enters The Linux World

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

  • #11
    Originally posted by schmidtbag View Post
    lmao that metaphor linus said was genious. but really if nice is THAT useless why is it there? personally, i've used nice before and it works GREAT for me. for example, there was a year where i used screensavers for my background. screensavers can be somewhat cpu intensive, so i set the nice level to 19 (or maybe it was -19? i forget at this point). then, whenever another program demanded cpu power, the screensaver would get really choppy and unresponsive while the program had little to no slowdown at all.

    based on my experience, nice isn't broken at all, it works great. thats why this new thing is confusing to me because if i were to use it in my example, i don't see how anything would change at all.
    All I know is certain i/o tasks in particular get at least equal treatment, if not top priority it seems like sometimes, and bring the UI to a screeching halt in certain scenarios. At first I thought the same, that if I simply adjusted the niceness level of, say, all X.org operations over that of other operations like compiling or copying or whatever, that it would resolve that problem.

    However, Linus' comment that niceness levels are absolute, and you may want things to be more dynamic than that and fine-grained. For instance, if Xorg started being mean, you wouldn't want all your other processes to be destroyed. That's my understanding of that anyway.

    Also, I think this issue is more complex than just scheduling of jobs, and there seems to have been a lot of improvements in actually making things more able to run in parallel, or in other words I think the multitasking ability of Linux just got a whole lot better with the recent coding that has gone into it. Being also able to make it so GUI responsiveness and user interaction in general gets higher priority is just one of the improvements.

    Seriously, before all this, Linux had much worse multitasking capabilities than Windows 2000 did. Very happy to see this getting fixed.

    Comment


    • #12
      Originally posted by Larven View Post
      Wow... sounds great! Can you tell us how long until we could try this?
      You can run it. Feedback is very much welcome :-)
      Especially usecases that slow down your computer to a point of not nice to use ;-)

      Comment


      • #13
        Originally posted by Yfrwlf View Post
        All I know is certain i/o tasks in particular get at least equal treatment, if not top priority it seems like sometimes, and bring the UI to a screeching halt in certain scenarios. At first I thought the same, that if I simply adjusted the niceness level of, say, all X.org operations over that of other operations like compiling or copying or whatever, that it would resolve that problem.
        IO scheduling is a different matter. One problem i noticed is to less file cache in memory. You can even get the feeling of swap of death without any swap :-)

        For real good io scheduling linux 2.6.36 got a cgroup blkio subsystem.
        Unfortunately it does not support deep hierarchy, so i need to run an own, flat mapping there.


        Originally posted by Yfrwlf View Post
        However, Linus' comment that niceness levels are absolute, and you may want things to be more dynamic than that and fine-grained. For instance, if Xorg started being mean, you wouldn't want all your other processes to be destroyed. That's my understanding of that anyway.
        If x dies, it dies and you are screwed, thing can stop that. What can be done is to make sure x will not get killed. I haven't added adjustment of the oom_adj value, but the api is already there. I plan to adjust the oom flags of important tasks so it will not likely be killed, when everything is lost :-)
        But i hope that oom killer will never fire at all.


        Originally posted by Yfrwlf View Post

        Also, I think this issue is more complex than just scheduling of jobs, and there seems to have been a lot of improvements in actually making things more able to run in parallel, or in other words I think the multitasking ability of Linux just got a whole lot better with the recent coding that has gone into it. Being also able to make it so GUI responsiveness and user interaction in general gets higher priority is just one of the improvements.

        Seriously, before all this, Linux had much worse multitasking capabilities than Windows 2000 did. Very happy to see this getting fixed.
        Windows does not have better scheduling at all. The problem with the linux scheduler that he is just to fair when not adjusted. The windows scheduler is just unfair in general, at least up to vista. Fair in general is better, if it can be adjusted to what the user expects :-)

        Comment


        • #14
          Originally posted by poelzi View Post
          Windows does not have better scheduling at all. The problem with the linux scheduler that he is just to fair when not adjusted. The windows scheduler is just unfair in general, at least up to vista. Fair in general is better, if it can be adjusted to what the user expects :-)
          I have to agree with Yfrwlf on this one. Even windows 2000 felt more "snapier" (that seems to be a popular word these days) than recent linux (until at least version .34). Just the fact that, when something heavy is going on in the background (high disk i/o, high cpu load) it takes a few seconds from the moment you click on something to it actually responding to the click speaks a lot about the responsiveness problem. This is something that apple got right: it must feel fast (even if it isn't).

          Comment


          • #15
            Originally posted by devius View Post
            I have to agree with Yfrwlf on this one. Even windows 2000 felt more "snapier" (that seems to be a popular word these days) than recent linux (until at least version .34). Just the fact that, when something heavy is going on in the background (high disk i/o, high cpu load) it takes a few seconds from the moment you click on something to it actually responding to the click speaks a lot about the responsiveness problem. This is something that apple got right: it must feel fast (even if it isn't).
            Completely agree with you. Windows has no big problem when copying some data from a disc, it works most of the time. And Mac OS X is relay good on this, that's why many graphics and sound producers use it without thinking twice. Using iOS is a pleasure, the GUI is more responsive than a PC.

            The GUI tasks should have a high priority, mainly the front window; audio should have a high priority too.

            Comment


            • #16
              I'd like to make two points.
              Point one:
              Guys, what are you talking about? Do you even realise a bunch of students can't write an OS scheduler! It's Operating System Science, a lot of research has been put into it, it's a highly theoretical and a very complex matter. It's not done overnight or in any way fast.
              Point two:
              Desktop latency is a very complex issue, spawning across numerous subsystems, and the disorganised approach we have now in Linux, with new scheduler variants appearing every day, a few control daemons, and now this ULatencyD daemon being developed without necessary synchronisation and unified planning. Take a look at the Windows approach, for example:there the scheduler talks to the window manager and to some other subsystems, such as I/O and don't remember what else, dynamically adjusting itself and the process timeslice to the current situation. However, it is desktop-oriented, and this is where the window manager ties and the general quantum calculation and distribution algorithms originate. So we need to tackle this issue in a more broad and integrated way (not to be messed up with generic, that's another thing), and less UNIX/Linux (distributed/independent development) way, if you want.

              This is what I mean:imagine some guy comes and says, "I want to introduce a mechanism for providing window manager feedback into the kernel a la Windows scheduler." Imagine the flame that comes right next to this? "It's not generic enough! We can't rely on a window manager in the kernel! We chanbge window managers every day! You're making too many assumptions, and this s not how Linux and UNIX in general is developed! Go go go develop your non-generic code somewhere else but not here! Never will it be included in the kernel!" And so on and so forth. We're too generic, and that's our problem. Sometimes you need to make compromises and develop something less generic and more exact, but solving some certain problem well instead of trying to be a jack of all trades and not succeeding in any of the problems you're trying to solve.

              Comment


              • #17
                Originally posted by Yfrwlf View Post
                Seriously, before all this, Linux had much worse multitasking capabilities than Windows 2000 did. Very happy to see this getting fixed.
                I like Windows 2K, a-lot. It was the last Windows OS on my workstation.
                .... However,
                You seem to mix "multi-tasking" and "interactive performance".

                Linux is -very- good at juggling huge amount of process on large amount of processing cores, In fact, it's -far- better than Windows Server 2K8 (Let alone Windows 2K).
                However, as a desktop OS, Linux, at least out-of-the-box, is less optimized for interactive performance. (What is usually called responsiveness)

                On the other hand, I spent parts of the weekend working (including gaming...) on my Xeon workstation while 16 out of the 24 (hyper)threads were busy compressing a 1.5TB storage into an external USB drive using tar+pbzip, so I guess Linux is not that bad when it comes to interactive performance....

                - Gilboa
                oVirt-HV1: Intel S2600C0, 2xE5-2658V2, 128GB, 8x2TB, 4x480GB SSD, GTX1080 (to-VM), Dell U3219Q, U2415, U2412M.
                oVirt-HV2: Intel S2400GP2, 2xE5-2448L, 120GB, 8x2TB, 4x480GB SSD, GTX730 (to-VM).
                oVirt-HV3: Gigabyte B85M-HD3, E3-1245V3, 32GB, 4x1TB, 2x480GB SSD, GTX980 (to-VM).
                Devel-2: Asus H110M-K, i5-6500, 16GB, 3x1TB + 128GB-SSD, F33.

                Comment


                • #18
                  I just wanted to inform, that i made a real release 0.3.1

                  It got a lot of features since the project announcement. This release contains a plugin that detects the process of the active x window and gives those more cpu shares. And much more...

                  https://github.com/poelzi/ulatencyd/downloads

                  There is now a ubuntu PPA.

                  Comment


                  • #19
                    Originally posted by poelzi View Post
                    I just wanted to inform, that i made a real release 0.3.1

                    It got a lot of features since the project announcement. This release contains a plugin that detects the process of the active x window and gives those more cpu shares. And much more...

                    https://github.com/poelzi/ulatencyd/downloads

                    There is now a ubuntu PPA.
                    When you browse menus the active window doesn't lose focus, at least not in Gnome. All of GTK, the entire interface, needs to have responsiveness above what any running program gets. I assume for this to happen you would need to make sure Xorg gets top priority, and perhaps some other things like gnome-panel for Gnome and similar for KDE.

                    Xorg sure does use a lot of CPU. I wonder just how CPU-hungry Wayland will be in comparison. :P

                    Comment


                    • #20
                      Originally posted by Yfrwlf View Post
                      When you browse menus the active window doesn't lose focus, at least not in Gnome. All of GTK, the entire interface, needs to have responsiveness above what any running program gets. I assume for this to happen you would need to make sure Xorg gets top priority, and perhaps some other things like gnome-panel for Gnome and similar for KDE.

                      Xorg sure does use a lot of CPU. I wonder just how CPU-hungry Wayland will be in comparison. :P
                      First: the system does not work with the active window pid itself. it has a active processes list which contains the last n processes active. default config is 5, so when you switch between two programs which is very common, these two will both be in the active group.

                      so, even when x will not set the property on the menu windows, the focus information is not lost.

                      there are already rules that add ui apps of kde and gnome to a ui group that has more priority then any other running program, so switching desktops etc always feels fast.

                      xserver itself is placed in the group system.essential which gets lots of cpu shares.

                      Comment

                      Working...
                      X