Linux Scheduler Time Quantum - Linux

This is a discussion on Linux Scheduler Time Quantum - Linux ; Hi, Unlike in Solaris and WindowsXP, Linux (2.6) gives a larger quantum to the highest priority queues compared to the lower queues. considering that the high queues are intended to group Interactive tasks (having short CPU burst duration) what is ...

+ Reply to Thread
Results 1 to 8 of 8

Thread: Linux Scheduler Time Quantum

  1. Linux Scheduler Time Quantum

    Hi,

    Unlike in Solaris and WindowsXP, Linux (2.6) gives a larger quantum to
    the highest priority queues compared to the lower queues. considering
    that the high queues are intended to group Interactive tasks (having
    short CPU burst duration) what is the rationale behind giving such
    large quantum for these I/O bound processes which will undoubtedly
    increase the average response time; and relatively smaller quantum for
    the lower queues which are dedicated to CPU bound tasks (having short
    CPU burst duration). In the last case, the scheduler will simply
    increase unnecessarily the context switch overhead for what is expected
    a non-interactive load of batch applications.

    Thanks


  2. Re: Linux Scheduler Time Quantum


    xu_feng_xu@yahoo.com wrote:

    > Unlike in Solaris and WindowsXP, Linux (2.6) gives a larger quantum to
    > the highest priority queues compared to the lower queues. considering
    > that the high queues are intended to group Interactive tasks (having
    > short CPU burst duration) what is the rationale behind giving such
    > large quantum for these I/O bound processes which will undoubtedly
    > increase the average response time; and relatively smaller quantum for
    > the lower queues which are dedicated to CPU bound tasks (having short
    > CPU burst duration). In the last case, the scheduler will simply
    > increase unnecessarily the context switch overhead for what is expected
    > a non-interactive load of batch applications.


    Your argument doesn't make sense. How will giving I/O bound tasks a
    larger quantum affect anything? If the tasks are I/O bound, they won't
    use the full quantum anyway.

    This change only matters when the high-priority tasks are sufficiently
    CPU bound that they would completely exhaust the smaller quantum they
    would get if they were at lower priority and still have work to do. In
    this case, it doesn't make sense to impose on the high-priority task
    the cost and latency of a task switch, better to let it use the CPU
    until it becomes I/O bound.

    Of course, it's to some extent a tradeoff.

    Think about it this way. You have two tasks with equal static priority.
    One is consistently using up its full quantum. The other is waiting for
    I/O. The task waiting for I/O begins to get a higher dynamic priority
    because it is voluntarily yielding. Now that task's I/O completes and
    it's ready-to-run. Doesn't it make sense to give it a bit more time to
    process the I/O that finally completed?

    Basically, enlarging the quantum for higher-priority tasks rewards
    cooperation and allows interactive applications that only occassionally
    need large chunks of CPU to get it.

    DS


  3. Re: Linux Scheduler Time Quantum

    xu_feng_xu@yahoo.com wrote:
    > Hi,
    >
    > Unlike in Solaris and WindowsXP, Linux (2.6) gives a larger quantum to
    > the highest priority queues compared to the lower queues. considering
    > that the high queues are intended to group Interactive tasks (having
    > short CPU burst duration) what is the rationale behind giving such
    > large quantum for these I/O bound processes which will undoubtedly
    > increase the average response time; and relatively smaller quantum for


    Why would the response time increase, if you are giving a high priority
    and long time quanta to the tasks which are providing that response?

    What makes you so sure that an interactive task needs only short bursts
    of CPU time? That depends entirely on the nature of the interactive
    task. The requirements of interactive tasks vary. Sometimes, in the
    foreground, the user requests things that perform a lot of I/O. At
    other times, things that do lots of computation. For instance, a user
    might load a large file into an editor (I/O-bound). Then, in the same
    thread, perform some complex regex search and replace (CPU-bound). The
    interactive task might spend most of its time waiting for user input,
    but then be expected to produce results fast.

    At times when the interactive task is I/O bound, then a longer time
    quantum doesn't have much effect on it. The time quantum ends when the
    task blocks. A longer time quantum is intended for those situations
    when the task needs to compute something.

    > the lower queues which are dedicated to CPU bound tasks (having short
    > CPU burst duration). In the last case, the scheduler will simply
    > increase unnecessarily the context switch overhead for what is expected
    > a non-interactive load of batch applications.


    A CPU-bound task will take all the time quantum you give it. If you do
    that for background tasks, then your system's response time will
    degrade.

    Consider that in a hard-real-time system, lower priority tasks do not
    get any time /at all/ whenever one or more higher priority tasks are
    runnable.


  4. Re: Linux Scheduler Time Quantum


    David Schwartz wrote:
    > xu_feng_xu@yahoo.com wrote:
    >
    > > Unlike in Solaris and WindowsXP, Linux (2.6) gives a larger quantum to
    > > the highest priority queues compared to the lower queues. considering
    > > that the high queues are intended to group Interactive tasks (having
    > > short CPU burst duration) what is the rationale behind giving such
    > > large quantum for these I/O bound processes which will undoubtedly
    > > increase the average response time; and relatively smaller quantum for
    > > the lower queues which are dedicated to CPU bound tasks (having short
    > > CPU burst duration). In the last case, the scheduler will simply
    > > increase unnecessarily the context switch overhead for what is expected
    > > a non-interactive load of batch applications.

    >
    > Your argument doesn't make sense. How will giving I/O bound tasks a
    > larger quantum affect anything? If the tasks are I/O bound, they won't
    > use the full quantum anyway.


    Many thanks for your reply. I was considering the case where the
    highest queue has more than one Ready task. Having a large queue
    quantum value will make the average response time in that queue very
    bad as some of the highest priority tasks will have to wait for a long
    time before being assigned the CPU.


  5. Re: Linux Scheduler Time Quantum


    xu_feng_xu@yahoo.com wrote:

    > Many thanks for your reply. I was considering the case where the
    > highest queue has more than one Ready task. Having a large queue
    > quantum value will make the average response time in that queue very
    > bad as some of the highest priority tasks will have to wait for a long
    > time before being assigned the CPU.


    What good is getting the CPU very quickly if you don't have it long
    enough to get the work done?

    DS


  6. Re: Linux Scheduler Time Quantum


    David Schwartz wrote:
    > xu_feng_xu@yahoo.com wrote:
    >
    > > Many thanks for your reply. I was considering the case where the
    > > highest queue has more than one Ready task. Having a large queue
    > > quantum value will make the average response time in that queue very
    > > bad as some of the highest priority tasks will have to wait for a long
    > > time before being assigned the CPU.

    >
    > What good is getting the CPU very quickly if you don't have it long
    > enough to get the work done?
    >
    > DS

    i see your point but the average response time is also a factor that
    needs to be considered. at the end a compromise should be taken. i
    think you are missing my main point. my point was that Windows XP and
    Solaris, Unlike Linux allocate shorter quantums to the highest queues.
    Surely those guys know what they are doing. why Linux opts for the
    opposite solution? is there any papers which compare the performance of
    the two approaches in real life?


  7. Re: Linux Scheduler Time Quantum


    xu_feng_xu@yahoo.com wrote:

    > i see your point but the average response time is also a factor that
    > needs to be considered. at the end a compromise should be taken. i
    > think you are missing my main point. my point was that Windows XP and
    > Solaris, Unlike Linux allocate shorter quantums to the highest queues.


    That translates into *punishing* processes for voluntarily
    relinquishing the CPU and *rewarding* processes for using up their full
    timeslice. Processes receive higher priorities in exchange for
    voluntarily relinquishing the CPU and they are rewarded for doing so
    (and presumably for being interactive) by getting more CPU time when
    they actually need it.

    DS


  8. Re: Linux Scheduler Time Quantum

    David Schwartz wrote:

    >
    > xu_feng_xu@yahoo.com wrote:
    >
    >> i see your point but the average response time is also a factor that
    >> needs to be considered. at the end a compromise should be taken. i
    >> think you are missing my main point. my point was that Windows XP and
    >> Solaris, Unlike Linux allocate shorter quantums to the highest queues.

    >
    > That translates into *punishing* processes for voluntarily
    > relinquishing the CPU and *rewarding* processes for using up their full
    > timeslice. Processes receive higher priorities in exchange for
    > voluntarily relinquishing the CPU and they are rewarded for doing so
    > (and presumably for being interactive) by getting more CPU time when
    > they actually need it.
    >
    > DS


    Please differentiate between user bound and I/O bound, it will clarify the
    timing and priority issues to no end.

    --
    JosephKK
    Gegen dummheit kampfen die Gotter Selbst, vergebens.**
    --Schiller

+ Reply to Thread