Re: Multicores


Skybuck Flying wrote:
> > In short, time slice intervals have only a little to do with system
> > responsiveness.
>
> That's where you are 100% wrong, it has everything to do with system
> responsiveness.
>
> 1. Give an application a higher priority and it's threads will get a longer
> time slice.
> 2. Give an application a lower priority and it's threads will get a shorter
> time slice.
>
> That's why 1. lags the system when an application gets to much time.
> That's why 2. makes an application take very long to complete it's task.


Of course that's not anything like the way it actually works. If two
threads, one high and one low priority, are ready to run, the high
priority thread will be dispatched, and time slices have nothing to do
with it. In the basic case a runnable high priority thread will
prevent all low priority threads from running, period. If two threads
of equal priority are both runnable, then, and only then, will time
slices come into play to switch between those equal priority threads.
That being said, many OSs will apply a dynamic temporary priority boost
to lower priority threads if they've not been allowed to run for an
extended period of time so that they're not starved of CPU time
completely. And there are, of course, more complex schedulers that
work not just on thread priority, but take into account system policies
that say things like "guarantee at least 15 % of the CPU to job#3."
Those often work by watching the run history and adjusting a more
traditional priority scheme to meet the goals.

.

Relevant Pages

  • Re: [ANNOUNCE][RFC] PlugSched-6.3.1 for 2.6.16-rc5
    ... problem is that it uses a smaller time slice for the first time slice ... full 120 msecs at that high priority they can hose the system. ... shorter first time slice gives the scheduler a chance to reassess the ... This is supposed to represent the task with the highest CPU usage rate per share and is used to determine how fairly CPU is being distributed among the currently active tasks. ...
    (Linux-Kernel)
  • Re: [RFC] cfq: adapt slice to number of processes doing I/O
    ... In the patch, if there are more than 3 processes performing concurrent ... I/O, we scale the time slice down proportionally. ... version of the ideal number of bytes the given priority should have ...
    (Linux-Kernel)
  • Re: [ANNOUNCE][RFC] PlugSched-6.3.1 for 2.6.16-rc5
    ... But anyway, based on the evidence, I think the problem is caused by the fact that the eatm tasks are running to completion in less than one time slice without sleeping and this means that they never have their priorities reassessed. ... The reason that it does this is that it gives newly forked processes a fairly high priority and if they're left to run for a full 120 msecs at that high priority they can hose the system. ... Having a shorter first time slice gives the scheduler a chance to reassess the task's priority before it does much damage. ...
    (Linux-Kernel)
  • Re: [ANNOUNCE][RFC] PlugSched-6.3.1 for 2.6.16-rc5
    ... this lockup somewhat and starts exhibiting this problem as a choking ... problem is that it uses a smaller time slice for the first time slice ... full 120 msecs at that high priority they can hose the system. ...
    (Linux-Kernel)
  • Re: Multicores
    ... > Skybuck Flying wrote: ... time slice intervals have only a little to do with system ... Give an application a higher priority and it's threads will get a ... The threads of the high priority application will get longer time slices. ...
    (comp.arch)