Messages in this thread | | | From | "Davide Libenzi" <> | Subject | Re: New schedule() and semaphore implementation ... | Date | Fri, 11 Jun 1999 16:47:04 +0200 |
| |
>On Fri, 11 Jun 1999, Davide Libenzi wrote: > >>I've done a global patch to kernel 2.3.5 that include my new >>schedule() implementation ( try it, gives great benchmarks ! ) > >Talking about design, how do you handle the `mm' and the `processor' >information in SMP? You are trashing them. For the processor thing you may >workaround the thing by using NR_CPU slots and then accounting two >different queues for every smp_num_cpus, but you would have an impressive >latency updating all such queues. For the mm thing you may browse the >higher slot and the one below in one pass but you would increase the >latency of your code this way too. >
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/
| |