I've got an "interruptible_sleep_on" the issues We've talked about.
I must reconsiderabout schedule(), if You, that have a greater experience
then mine, say me that the number of ruuning tasks is < 5 even in hi
loaded environments my patch is quite useless ( sigh !, I like it ).
I'm not so sure about the semaphore one, in which my patch does exactly
the same thing with a much lower overhead ( on a semaphore queue can sleep
more then 5 tasks ).
But even if the number of tasks waiting for a chance in a semaphore is
low, I think that my patch is more correct for these reasons:
1) As I've sad before it does the same thing in _1_ wakeup and not
in N wakeups and N-1 schedule()
2) It applies the same scheduling decisions of schedule(), without
wake_one(), wake_first(), wake_last_before(), TASK_EXCLUSIVE ...
and other things like this. It simply wake up the best in the
schedule() sense.
3) It gives a chance to _every_ task waiting to exit from the queue,
accumulating task's counter during the schedule() recharge loop.
And Alan, even if sys5 gives no starvation guarantees for semaphores,
why we can't do better ?
This is for Andrea:
>Also consider that you don't know which will be the CPU
>(and its prev task) that will reschedule the task blocked in the semaphore
>so the goodness may be not completly relialable (the wakenup task may be
>rescheduled from the other CPU before you'll exit from your sem_wake_up).
I forgot to add a runqueue_lock in __sem_wake_up().
No I go to get another "interruptible_sleep_on" ... the beach,
but I'll came back, Ahh, Ahh, Ahh ....:))
Cheers,
Davide.
-
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/