Why I must keep NR_CPU slots ??
Processor and mm info are taken in account in goodness() calculation that
called as:
goodness(tsk, tsk, tsk->processor);
<<<< This means max mm goodness ( tsk->mm == tsk->mm ) and
max SMP goodness ( same processor ) >>>>
give the higher result and hence ensure that no process in slot (N - 1) will
give a goodness greater then one in slot N.
When at the end of a slot computation is executed this code:
...
/* Goodness promise has been maintained, we've found the President ! */
if (c >= SLOT_GDS_BASE(ii))
goto task_found;
...
we are sure, having task in slot N maintained his "promise", that we can
skip out
with the right process for the previous definition.
>About implementation details you are not using the helper functions in
>list.h that would make the code easily readable.
I can agree here.
I'll code a new version with linux lists.
>And it's not true that if
>there are N tasks running you have more schedule overhead and that's the
>case you must optimize. If they are all doing `for(;;);' then you will
>have the same schedule cost of one task that does `for(;;);'. I agree that
>probably N tasks are going to sleep a lot (as in the network case).
Andrea having tasks doing for(;;); is not a common environment to test,
isn't it ?
Anyway my algo has a cost near to O(1) while the previous as a cost of O(N)
where N is running tasks.
>You are allowing the
>first task with goodness > gdsmax to go ahead while there may be a more
>priority task in the higer priority slot (RT processes). Then there is
>some other minor detail that should be cleaned up according to me.
Agree.
I'll correct this behaviour.
Cheers,
Davide.
-- "Debian, the Freedom in Freedom"
- 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/