From: Sam Vilain (sam_at_vilain.net)
Date: Fri 22 Oct 2004 - 01:39:54 BST
Gregory (Grisha) Trubetskoy wrote:
>
> On Thu, 21 Oct 2004, Herbert Poetzl wrote:
>
>> yes, this is if the hard scheduler is actually enabled
>
>
> That's one I forgot to mention - none of this has any visible effect
> (and by that I mean inability to drive the load to 30) unless sched_hard
> flag is set.
A load of 30 is not a real problem (in terms of CPU, anyway), if those
processes have such a low priority that everything else on the system is
pretty much real time. What you are seeing is probably just due to the
context not getting enough penalisation by the time the load hits 30, or
some secondary effect like disk load or memory exhaustion. Try it with
a smaller bucket size ;-).
When a context goes on hold with runnable processes, those processes
might not contribute to the visible load factor, but they could be said
to still be runnable. So all you're doing is hiding the problem and
underutilising your CPUs.
Having said that, because the cpu scheduler tries to avoid process
starvation (where a process gets no CPU at all), then if a context has a
*lot* of processes then it will `exploit' the anti-starvation code into
getting more CPU than allocated, without hard scheduling. To give you
an indication, this is around the number of minimum time slices
(MIN_TIMESLICE, 5ms) than fit into the starvation limit (MAX_SLEEP_AVG,
2.5s) - ie, a per-second CPU load of 500.
Turning on the hard scheduling means letting processes starve. If
you're happy to let processes starve then you can make the scheduler
perform better in other ways - that is a classic trade-off in CPU
scheduling.
-- Sam Vilain, sam /\T vilain |><>T net, PGP key ID: 0x05B52F13 (include my PGP key ID in personal replies to avoid spam filtering) _______________________________________________ Vserver mailing list Vserver_at_list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver