mmap_sem (and generic) semaphore fairness question
Quoted 15 lines · David Mansfield
Is it possible for the following to happen repeatedly, keeping B from ever aquiring S.
1) Resource becomes available.
2) A is 'runnable' and is given an entire timeslice.
3)schedule()to A
4) A releases S
5) A returns to userspace
6) A uses much less than entire timeslice doing calculation
7) A needs some resource again
7) A enters kernel and aquires S
8) A sleeps on resource, rest of timeslice not used, A's 'goodness' isn't messed up.
9) goto 1.
Quoted 2 lines
In this scenario, as long as A never uses it's full timeslice, B will never get to aquire S.
Yes, it can happens. It for sure happens in ncpfs - as ncpfs uses ping-pong protocol, and I'm lazy to use different thing than semaphore, connection to server is guarded by semaphore.
If one task does long read/write, nobody else can perform any operation on mountpoint (these processes are listed in "D", as usual). As soon as copying task pauses (writting readed data to another FS, pagefault), other of competing tasks starts... If you'll start two copies in parallel, each task usually copies each file without any progress on other task. After copying one file, other task starts copying...
For now I solved it by adding second processor into the box ;-) But if anybody has easy (or nice) implementation of fair semaphore, or an idea how to fix it, I'd like to put it into ncpfs...
Probably creating safe_semaphore by moving sem->count++ from up() (when up does __up_wakup) to __down_failed could work. But it is not nice, as implementation of this idea requires spinlock in safe_up() fastpath...
Best regards,
Petr Vandrovec [email protected]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Quoted 3 lines · Petr Vandrovec
Yes, it can happens. It for sure happens in ncpfs - as ncpfs uses ping-pong protocol, and I'm lazy to use different thing than semaphore, connection to server is guarded by semaphore.
If you use a rw semaphore taken for writing by two writers, it will alternate between the two because the second writer will bias the lock (its next state is predetermined when the second writer goes to sleep). This is also true for the mix of reader -> writer and writer -> reader.
-ben
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/