Messages in this thread | | | Date | Fri, 11 Jun 1999 12:12:33 +0530 (IST) | From | V Ganesh <> | Subject | Re: New semaphore __wake_up() implementation ... |
| |
> From: Andrea Arcangeli <andrea@suse.de> > Date: Fri, 11 Jun 1999 04:20:57 +0200 (CEST) > Subject: Re: New semaphore __wake_up() implementation ...
[snip]
> >the total cost of a "up" operation is: > > > >TCo = L + M * W + (M - 1) * S > > The above is wrong. __wake_up in general only does a wake_up_process() for > the number of tasks in the waitqueue.
that's what he says. M = no. of tasks on waitqueue. why is it wrong ?
> The most suitable process to run in general is the last one inserted in > the waitqueue even if is going to expire its timeslice because it has more > probability to be still in cache. Anyway this is an issue only for
surely that depends on the application of the semaphore ? if it's used in one of the TASK_EXCLUSIVE cases then you can just take the last guy off the queue since it doesn't matter which one is woken up and the last guy is likely to be in cache. but if the semaphore was being used for mutual exclusion then you should wake up the highest priority process, which is what I think Davide is doing. previously we just kicked the herd in the ass and they all thundered towards a gate which would admit only one. the dirty work of calculating the highest priority buffalo was done by the scheduler. Davide does it within up() which IMHO is what should have been done in the first place. in any case, his up() can't perform worse than what's already there.
the situation here is different from the select()/accept() case: in select(), all of them _had_ to be woken up. there's no such requirement here, since M - 1 of them would again fall asleep without doing any useful work at all.
ganesh
- 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/
| |