lkml.org 
[lkml]   [1999]   [Jun]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: New schedule() and semaphore implementation ...
Date
>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/

\
 
 \ /
  Last update: 2005-03-22 13:52    [W:0.034 / U:0.012 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site