Messages in this thread | | | Date | Fri, 19 Nov 1999 17:10:43 -0800 (PST) | From | Linus Torvalds <> | Subject | Re: [Patch] shm bug introduced with pagecache in 2.3.11 |
| |
On Sat, 20 Nov 1999, Arjan van de Ven wrote: > > Do you think an implementation based on this (and the other examples from > the book) is acceptable? Since the implementation uses already available > primitives, no assembly or other architecture-specific stuff is required.
Nope, not acceptable.
The mm semaphore is one of the most timing-critical in the whole kernel. It usually has absolutely zero contention, but it needs to be FAST.
Basically, a read-lock() must look something very very similar to the read-spinlock implementation, ie something like
lock ; incl (%ecx) js fixup
for the successful fall-through case. Two instructions, no more. That's what the spinlocks do, and that's also what the semaphores do (although in the case of a semaphore, it's a "decl" in that case.
The "fixup" case is going to be more complex than for spinlocks: for spinlocks it's just a simple loop, while for semaphores you get all the complexity that you see in arch/i386/kernel/semaphore.c to handle the thing cleanly..
The read-write semaphore should be doable with the same skeleton as the normal semaphores, although it needs two counters (regular semaphores have just "sleepers", rw-semaphores need to have "read_sleeper" and "write_sleeper" counts etc).
Linus
- 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/
| |