Messages in this thread | | | Date | Thu, 25 Nov 1999 14:33:51 +0100 (CET) | From | Andrea Arcangeli <> | Subject | Re: [Patch] shm bug introduced with pagecache in 2.3.11 |
| |
On Fri, 19 Nov 1999, Linus Torvalds wrote:
>Well, the more I look at a read-write semaphore, the more I like it: it >looks like something that once the semaphore implementation itself was >done, the MM side would be absolutely trivial. It does introduce a new >issue (multiple threads updating the page tables at the same time), but >that one doesn't look that horrible..
If you allow more than one task to fault for example in the swapin path you'll get in troubles as you can't solve this race cleanly with a spinlock. That's why I added the semaphore to the shm segments in first place.
Only replacing the down() with a read_down() in do_page_fault is _not_ enough. The semaphore is not there only to protect from mmap and vma changes under us, right now it's there mainly to protect other threads to fault under us.
IMHO the semaphore make a performance difference only with threads doing paging of mmapped files while fooling readahead. The swapin case is not intersting IMHO (and we do readahead also for the swapins). Maybe we can find a way to drop the semaphore in the nopage path. The read semaphore in do_page_fault make not too much sense to me as we should do really tricky code to solve the races by hand without a performance advantage in RL.
Andrea
- 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/
| |