Messages in this thread | | | Date | Fri, 11 Jun 1999 15:59:51 +0200 (CEST) | From | Andrea Arcangeli <> | Subject | Re: New schedule() and semaphore implementation ... |
| |
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.
Even when there are tons of tasks in the system you may really want to get the processor and mm informations accounted. 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).
About implementation details you are not using the helper functions in list.h that would make the code easily readable. 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.
About the wake_up_sem the right thing to do is to make the semaphore sleeping a wakeone thing.
Andrea Arcangeli
- 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/
| |