mm synchronization question

mm synchronization question

[ms]

[-- Attachment #1: Type: text/plain, Size: 867 bytes --]

I think I found a minor bug:
do_wp_page() does not call spin_unlock() if called with bad parameters:
if "goto  bad_wp_page" is executed, then noone unlocks the page_table_lock spinlock.
 
My second question is the mm semaphore:
It seems that if in a multi threaded application several threads access a large mmaped file, that then all page-in operations are serialized (including waiting for the disk IO)
Is that correct?
Are there any plans to change that?
 
a possible alternative:
* every mm has a linked list of all pages the OS is currently working on.
* instead of just acquiring the mm semaphore, every operation must first check that there are no collisions with pending operations, then it acquires the semaphore.
* we drop the mm semaphore during long (i.e. IO) operations.

Please Cc, I´m currently not on the mailing list.
--
    Manfred

[-- Attachment #2: Type: text/html, Size: 2216 bytes --]

[PATCH] Re: mm synchronization question

[Stephen C. Tweedie]

Hi,

On Tue, 27 Jul 1999 12:30:39 +0200, "ms" <masp0008@stud.uni-sb.de> said:

> I think I found a minor bug: do_wp_page() does not call spin_unlock()
> if called with bad parameters: if "goto bad_wp_page" is executed, then
> noone unlocks the page_table_lock spinlock.

Indeed, that looks like a genuine fault.  Patch below.
 
> My second question is the mm semaphore: It seems that if in a multi
> threaded application several threads access a large mmaped file, that
> then all page-in operations are serialized (including waiting for the
> disk IO). Is that correct?  

Only partially.  The IOs are serialised, but the readahead IOs that the
page faults implicitly trigger are asynchronous to that.

> Are there any plans to change that?

Not right now afaik, but we probably could do it at some point.  It
would be very easy to do a simple solution which allowed concurrent page
faults while still barring mmap()/munmap() operations from colliding
with the fault.

--Stephen

----------------------------------------------------------------
--- mm/memory.c~	Wed Jul 28 00:52:42 1999
+++ mm/memory.c	Wed Jul 28 05:30:48 1999
@@ -846,6 +855,7 @@
 	return 1;
 
 bad_wp_page:
+	spin_unlock(&tsk->mm->page_table_lock);
 	printk("do_wp_page: bogus page at address %08lx (%08lx)\n",address,old_page);
 	return -1;
 }
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/