Re: Gurus, a silly question for preemptive behavior

From: Con Kolivas
Date: Tue Dec 21 2004 - 21:18:57 EST

jesse writes:

--- Con Kolivas <kernel@xxxxxxxxxxx> wrote:

jesse wrote:
> Paulo:
> > I already said in the messsage that my user
> application has a low nice priority, i set it to
> since my application has low priority compared to
> other user space applications, it is supposed to
> interrupted. but it is not.

If your task is better priority the scheduler will
make it preempt the worse priority task. It sounds to me like you are
complaining that the worse priority task is still getting cpu? If so, you
misunderstand priority - it orders tasks according to priority
giving lower latency and preemptive behaviour to the better task, and
gives _more_ cpu but not all the cpu. The cpu must still be shared, but
with more cpu distributed to the better priority task. If you want
your better priority task to get _all_ the cpu you have to use
real time scheduling.


ok, Con, your explaining makes some sense to me , but
still not very well.

suppose I have five high process: A1, A2, A3, A4,
A5 all have nice = 0. and I also have a low priority
process B with nice = 10.

a) when process B is scheduled to run, it is given
a short time slot based on its priority, for example 5
secs. because at that point, A1/2/3/4/5 are not
started yet. B will get CPU and run at full speed. b) at the end of time slot(5 secs), scheduler
finds higher priority A1/A2/A3/A4/A5 are ready,
scheduler will interrupt process B and starts to pick a process from group A, even though B still needs CPU
c)unfortunately, process A1/2/3/4/5 are so active,
thus process B should never get opportunity to run
again, in consequence, CPU Usage% of Process B should
be very Low.
However, The above theretic assumption is in
contrary to what i observed. in my LAB, the low
priority process B seems to hold the CPU forever and
Top command always shows Process B with a 90% CPU
If _more_ cpu but not _all_ the cpu are given to
Process A1/2/3/4/5, Process B shouldn't have a 90% CPU

Thus, i can't help asking why low priority process B
gets most CPU cycle.

What you are describing is completely wrong behaviour. Please post output of top running during this workload to demonstrate/prove this is happening. Easiest thing to do is get your workload running and do 'top -b -n 1 > top.log' and post top.log please.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at