Page 1 of 2 12 LastLast
Results 1 to 10 of 16

Thread: SCHED_DEADLINE To Be Added To Linux 3.14 Kernel

  1. #1
    Join Date
    Jan 2007
    Posts
    14,645

    Default 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. #2
    Join Date
    Mar 2011
    Posts
    377

    Default

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

  3. #3
    Join Date
    Jul 2009
    Location
    Germany
    Posts
    486

    Default

    Quote Originally Posted by Article
    a real-time scheduling policy
    For real time workloads.

  4. #4
    Join Date
    Mar 2011
    Posts
    377

    Default

    Quote 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 ... ?

  5. #5
    Join Date
    Apr 2011
    Posts
    156

    Default

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

  6. #6

    Default

    Quote 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

  7. #7
    Join Date
    Jun 2012
    Posts
    343

    Default

    Quote 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.

  8. #8
    Join Date
    Dec 2012
    Posts
    196

    Default

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

  9. #9
    Join Date
    Mar 2011
    Posts
    377

    Default

    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?

  10. #10
    Join Date
    Oct 2008
    Posts
    3,102

    Default

    Quote 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.

Posting Permissions

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