lkml.org 
[lkml]   [1999]   [Nov]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

\
 
 \ /
  Last update: 2005-03-22 13:55    [W:0.113 / U:0.140 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site