Linux-kernel mailing list archive 1999-23,: Re: New semaphore __wake_up() implementation ...

# Re: New semaphore __wake_up() implementation ...

V Ganesh (ganesh@vxindia.veritas.com)
Fri, 11 Jun 1999 12:12:33 +0530 (IST)

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Davide Libenzi: "Re: New semaphore __wake_up() implementation ..."
- Previous message: Justin Hahn: "NFS message."
- Maybe in reply to: Davide Libenzi: "New semaphore __wake_up() implementation ..."
- Next in thread: Andrea Arcangeli: "Re: New semaphore __wake_up() implementation ..."
- Next in thread: Davide Libenzi: "Re: New semaphore __wake_up() implementation ..."
- Reply: Andrea Arcangeli: "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/

- Next message: Davide Libenzi: "Re: New semaphore __wake_up() implementation ..."
- Previous message: Justin Hahn: "NFS message."
- Maybe in reply to: Davide Libenzi: "New semaphore __wake_up() implementation ..."
- Next in thread: Andrea Arcangeli: "Re: New semaphore __wake_up() implementation ..."
- Next in thread: Davide Libenzi: "Re: New semaphore __wake_up() implementation ..."
- Reply: Andrea Arcangeli: "Re: New semaphore __wake_up() implementation ..."