Announcement

Collapse
No announcement yet.

SCHED_DEADLINE To Be Added To Linux 3.14 Kernel

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

  • SCHED_DEADLINE To Be Added To Linux 3.14 Kernel

    Phoronix: SCHED_DEADLINE To Be Added To Linux 3.14 Kernel

    Less than 24 hours after the Linux 3.13 kernel release there's already interesting Git pull requests submitted for Linux 3.14...

    http://www.phoronix.com/vr.php?view=MTU3Njk

  • #2
    I don't really understand what this is good for... Desktop, Server, ... ?

    Comment


    • #3
      Originally posted by Article
      a real-time scheduling policy
      For real time workloads.

      Comment


      • #4
        Originally posted by droste View Post
        For real time workloads.
        Isn't SCHED_FIFO / SCHED_RR for this? Your answer doesn't help in any way. Again: Does this benefit desktop workloads (low latency) or servers or ... ?

        Comment


        • #5
          @TAXI:
          time constraints seems the key:
          http://retis.sssup.it/~jlelli/sched-deadline.php

          Comment


          • #6
            Originally posted by TAXI View Post
            Isn't SCHED_FIFO / SCHED_RR for this? Your answer doesn't help in any way. Again: Does this benefit desktop workloads (low latency) or servers or ... ?
            FIFO and RR are basic scheduling policies for realtime that considers resource allocation on a process by process basis. DEADLINE works on the entire list of tasks and is a pre-requirement for hard realtime. Real time schedulers are typically not used by either desktop or server since real time does not mean fast and they can reduce throughput considerably in some cases in order to provide the guarantees that comes as part of such scheduling. You might want to read through

            http://people.redhat.com/williams/realtime-training.odp

            Comment


            • #7
              Originally posted by RahulSundaram View Post
              FIFO and RR are basic scheduling policies for realtime that considers resource allocation on a process by process basis. DEADLINE works on the entire list of tasks and is a pre-requirement for hard realtime. Real time schedulers are typically not used by either desktop or server since real time does not mean fast and they can reduce throughput considerably in some cases in order to provide the guarantees that comes as part of such scheduling. You might want to read through

              http://people.redhat.com/williams/realtime-training.odp
              You use a realtime scheduler when Time, not performance or latency, is your most important performance metric. Embedded systems make a lot of use of real-time schedulers, for instance. When I want the task to, say, open/shut the fuel valve, I don't care about how the rest of the system performs; the task that needs to accomplish this task must be completed before "x" time, and ONLY a realtime scheduler can guarantee that will be the case.

              For normal Desktop/Server workloads, a realtime scheduler will cost you system performance.

              Comment


              • #8
                It is useful for embedded systems where meeting deadlines (determinism) is essential for real time processes (usually at the cost of less throughput)

                Comment


                • #9
                  Thanks for all the answers. But now I have to ask: I remember some discussions some time ago that realtime scheduling should be good for desktops, especially gaming. Was that just trolling?

                  Comment


                  • #10
                    Originally posted by TAXI View Post
                    Thanks for all the answers. But now I have to ask: I remember some discussions some time ago that realtime scheduling should be good for desktops, especially gaming. Was that just trolling?
                    That's a soft realtime system versus a hard realtime.

                    The difference is that hard realtime provides guarantees, while soft just does it most of the time. I think a lot of people were talking about the soft rt patches working well on games by reducing input latency. I'm somewhat skeptical of using it for the entire desktop system, but it might be ok for most people.

                    No one is going to want the hard rt scheduling on games, i don't think. The benefit of hard rt is being able to deterministically prove things so you can always 100% guarantee the system works as expected - that's important when dealing with things that could be life threatening if they go wrong, or otherwise cause legal or financial issues.

                    Comment


                    • #11
                      Originally posted by TAXI View Post
                      Thanks for all the answers. But now I have to ask: I remember some discussions some time ago that realtime scheduling should be good for desktops, especially gaming. Was that just trolling?
                      The schedulers themselves are unlikely to be useful however the core work done for realtime (less lock contention etc) has already increased Linux kernel performance for general users and will continue to do so. No other general purpose kernel has merged realtime features to the extend Linux has or is expected to do in the near future so it is taking more time than anticipated earlier to work out the kinks. The merging of DEADLINE is a major move forward however.

                      Comment


                      • #12
                        Maybe I'm naive but with an increasing number of individual cpu cores, couldn't different schedulers run on/manage different cpus? What would be needed to achieve that?

                        Comment


                        • #13
                          Originally posted by ChrisXY View Post
                          Maybe I'm naive but with an increasing number of individual cpu cores, couldn't different schedulers run on/manage different cpus? What would be needed to achieve that?
                          Well, at a minimum you would need some sort of super-scheduler to divide the jobs up among the schedulers for each CPU.

                          Comment


                          • #14
                            Originally posted by RahulSundaram View Post
                            The schedulers themselves are unlikely to be useful however the core work done for realtime (less lock contention etc) has already increased Linux kernel performance for general users and will continue to do so. No other general purpose kernel has merged realtime features to the extend Linux has or is expected to do in the near future so it is taking more time than anticipated earlier to work out the kinks. The merging of DEADLINE is a major move forward however.
                            Well osx is able to offer"real-time" guarantees according to their developer docs. The reason is that their scheduler lives on mach.
                            Osx, ootb, offers simply phenomenally consistent low latency. Same goes for iOS.

                            There was m excellent article about the deadline work on lwn awhile back. The key thing to understand is that it is designed specifically for periodic tasks (say making sure an audio/video buffer remains full during playback, or making sure a heartbeat is processed). This has been cooking for a long time and it's fantastic to see it finally appear outside of academia.

                            Comment


                            • #15
                              Desktop

                              There are two main approaches I can see:
                              • kernel automagic (mr kolivas and his brainfuckscheduler BFS, DEADLINE, others...)
                              • user-space
                                • automagic scheduling hacks (based on pam/consolekit - systemd)
                                • ULATENCYD

                              If I may, I would like to point your atention towards ULATENCYD, which as of now, is feature complete, policy based (with working default policies) userspace scheduler that utilizes CGROUPS and other kernel subsystems (optionally BFS).
                              Code is here:

                              https://github.com/poelzi/ulatencyd


                              == What is ulatency ==

                              Ulatency is a daemon that controls how the Linux kernel will spend it's
                              resources on the running processes. It uses dynamic cgroups to give the kernel
                              hints and limitations on processes.

                              It strongly supports the lua scripting language for writing rules and the
                              scheduler code.

                              == What tries it to fix ==

                              The Linux scheduler does a pretty good job to give the available resources to
                              all processes, but this may not be the best user experience in the desktop case.
                              ulatencyd monitors the system and categorizes the running processes into cgroups.
                              Processes that run wild to slow down the system by causing massive swaping will
                              be isolated.

                              == Isn't CONFIG_SCHED_DESKTOP enough ? ==

                              There is a patch for 2.6.38 in pipeline, see http://thread.gmane.org/gmane.linux.kernel/1050575

                              I think that this mimimal aproach is good for some circumstances, but does not
                              provide enough flexibility required for a true low latency desktop.
                              Perfect desktop scheduling needs a lot of heuristics, that don't belong in
                              the kernel. For example, the patch won't protect you from swap of death, fork bombs,
                              can't detect which process you are actually using and give more cpu shares to them,
                              can't give realtime priorities to processes like jackd, etc...

                              ulatencyd is designed for fixing exactly that.
                              As I am writing this, I'm listening to youtube tracklist and runing kernel AND firefox compilation simultaneously with multiple jobs on laptop i5 while still having very decent responsiveness.
                              Ulatency does all the magic as seen here:


                              Code:
                              $ ulatency --no-processes
                              /sys/fs/cgroup/cpu
                              └─┬»cpu«                 cpu.shares=1024
                                ├─┬»sys_essential«     cpu.shares=3048
                                ├─┬»usr_1000«          cpu.shares=3048
                                │ ├─┬»grp_28316«       cpu.shares=600
                                │ ├─┬»grp_9874«        cpu.shares=600
                                │ ├─┬»grp_9186«        cpu.shares=600
                                │ ├─┬»grp_9121«        cpu.shares=600
                                │ ├─┬»grp_8831«        cpu.shares=600
                                │ ├─┬»grp_7783«        cpu.shares=600
                                │ ├─┬»grp_7780«        cpu.shares=600
                                │ ├─┬»grp_6153«        cpu.shares=600
                                │ ├─┬»grp_417«         cpu.shares=600
                                │ ├─┬»grp_1000«        cpu.shares=600
                                │ ├─┬»grp_998«         cpu.shares=600
                                │ ├─┬»grp_21280«       cpu.shares=600
                                │ ├─┬»grp_425«         cpu.shares=600
                                │ ├─┬»bg_high«         cpu.shares=1000
                                │ ├─┬»ui«              cpu.shares=2000
                                │ ├─┬»grp_357«         cpu.shares=600
                                │ ├─┬»grp_353«         cpu.shares=600
                                │ └─┬»grp_23101«       cpu.shares=600
                                ├─┬»rt_tasks«          cpu.shares=3048
                                ├─┬»sys_daemon«        cpu.shares=800
                                ├─┬»iso_firefox«       cpu.shares=1024
                                ├─┬»iso_ulatency«      cpu.shares=500
                                └─┬»iso_make«          cpu.shares=1024
                              Note that cpu shares are devided between several automatically scheduled processes (grp)
                              and that my firefox (iso_firefox) and make batch jobs (iso_make) are on the same level as all other tasks in group usr_1000 and realtime tasks (pulseaudio among other things) but with different cpu.shares.

                              All this with basic to no configuration (apart from starting the daemon, sysvinit and systemd are supported).

                              TL;DR

                              I highly recommend ulatencyd, it works well for desktop and it's stable enough for desktop use.

                              Comment

                              Working...
                              X