On Sat, 2007-04-28 at 23:53 +0200, matthieu castet wrote:
> Hi,
>
> some programs need to do some short of busyloop. It was often
> implemented as :
>
> while (1) {
> if (can_do_stuff) {
> do_stuff();
> }
> else
> //sleep a very short of time
> usleep(1);
> }
>
> usleep(1) or equivalent where used instead of sched_yield, because of
> some priority issue. IIRC doing sched_yield, make the process appears
> like an interactive process, so it has better priority and get call more
> often.
>
> But now if high res timer are enabled, these programs while cause
> something like a DOS : the context switch per second will be bigger than
> 500 000 and the cpu usage will be very high.
Well, it is not really a DoS. The rescheduling of the process is limited
by the scheduler and the available CPU time (depending on the number of
runnable tasks in the system).
>From the spec:
Implementations may place limitations on the granularity of timer
values. For each interval timer, if the requested timer value requires a
finer granularity than the implementation supports, the actual timer
value shall be rounded up to the next supported value.
The !HIGHRES enabled kernel rounds this up to the HZ interval, the
HIGHRES enabled kernel grants the request for this short sleep.
The program gets what it asked for: a stupid sleep value.
tglx
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
