> [...] In fact,
> you often see that 2 non-niced tasks have to share a
> CPU while 2 niced tasks get the other CPU...
(Do you have some (simple or complex) testcase where we fail?)
> This is probably because the PROC_CHANGE_PENALTY is
> _larger_ than the priority of the niced task to begin
> with, so the niced task gets it's priority more than
> doubled and the normal task can't get through...
? it doesnt matter wether it's doubled or not, being on the 'previous' CPU
means it gets an (absolute) goodness boost. A normal task can get through
if it was running on this CPU before too, and will be sent to / scheduled
by another CPU if not.
> This patch may fix the problem by giving a large bonus
> to 'normal' processes and a smaller one to niced tasks.
why? SMP + caching issues are the same no matter what priority the task
has. Priority is mainly a way to control CPU-bound processes.
(interactive processes will have maximum priority anyway)
we already kindof penalize lower priority processes with the mechanizm you
want to have removed:
> It also removes the standard 'weight += p->priority'
> because that one was a workaround for the bug in tty_ioctl.c
> and we shouldn't need it any more now that that's fixed.
no. the point as i understand it is to have high statical priority tasks
getting scheduled before lowprio tasks, even if the higher priority task
has used up most of it's timeslice. This concept is independent of SMP
issues. We still schedule exactly along priorities though for CPU-bound
processes.
-- mingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/