For Programmers: Free Programming Magazines  


Home > Archive > Unix Programming > December 2004 > SCHED_RR and SMP









You are viewing an archived Text-only version of the thread. To view this thread in it's original format and/or if you want to reply to this thread please [click here]

 

Author SCHED_RR and SMP
loic-dev@gmx.net

2004-12-14, 9:07 am

Hi,

we would like to have your opinion concerning the behavior of the
current Linux kernel 2.6.x on i386 SMP machine for the SCHED_RR class,
which we believe is 'unfortunate'.

The situation is as follows. We start a thread in the SCHED_RR class
with prio 3, and say 10 threads with prio 2. We are working on a 2 CPUs
machine (happens to be a dual Pentium 3, but that doesn't matter the
discussion). Due to current the design of the Linux scheduler, some
threads of prio 2 don't get started. After some investigations, we
found out that the scheduler tries to schedule some threads of prio 2
on the same processor running the thread of priority 3. Since the
priority 3 thread is pure compute bound, it do not release the CPU. As
the result, the threads of prio 2 scheduled on that processor do not
run at all.

We found this scheduling somewhat 'unfortunate'. Intuitively, one would
expect that the prio 3 monopolizes a CPU, and that the 10 SCHED_RR prio
2 threads get scheduled in a robin fashion on the remaining CPU. Many
Unix behaves that way, BTW.

>From my understanding, the Single Unix Specification 03 leaves "a great

degree of freedoom" to the implementer regarding that fact. As a
result, I am not sure if the Linux behavior departs from Posix/SuS.
Perhaps some of you might tell us what was perhaps the intend of
Posix.1b (or of the corresponding Working Group 14 for SMP machine)?

Second, would you agree that Linux should fix that scheduling decision
to something more consistent?


Thanks in Advance,
Loic.

Sponsored Links







Also available: Server administration forum archive | Web Design forum archive | Software forum archive | Hardware reviews archive

Copyright 2008 codecomments.com