[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-kernel
Subject:    Re: [Patch] shm bug introduced with pagecache in 2.3.11
From:       Linus Torvalds <torvalds () transmeta ! com>
Date:       1999-11-20 1:10:43
[Download RAW message or body]



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/

[prev in list] [next in list] [prev in thread] [next in thread]