Re: 3rd version of R/W mmap_sem patch available

Re: 3rd version of R/W mmap_sem patch available

[Stephen C. Tweedie]

Hi,

On Mon, Mar 19, 2001 at 07:35:08PM -0800, Linus Torvalds wrote:
> >
> > I can't see it.  Where did you hide it?
> 
> Ahh. The mirroring is apparently broken. I put my stuff on a faster local
> connection to "master.kernel.org", and depend on it being mirrored
> automatically. And apparently the mirroring has been down for a few days
> now. Ugh. I'll ping Peter.

Mirrored for now in

	ftp.uk.linux.org:/pub/linux/sct/kernel/

for the sake of anyone else helping with this.

Cheers,
 Stephen
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: 3rd version of R/W mmap_sem patch available

[H. Peter Anvin]

Please don't ping *me* when these things happen.  I was out of town. 
ftpadmin@kernel.org is the proper address; it goes to me and Jeff at the
moment.

	-hpa


"Stephen C. Tweedie" wrote:
> 
> Hi,
> 
> On Mon, Mar 19, 2001 at 07:35:08PM -0800, Linus Torvalds wrote:
> > >
> > > I can't see it.  Where did you hide it?
> >
> > Ahh. The mirroring is apparently broken. I put my stuff on a faster local
> > connection to "master.kernel.org", and depend on it being mirrored
> > automatically. And apparently the mirroring has been down for a few days
> > now. Ugh. I'll ping Peter.
> 
> Mirrored for now in
> 
>         ftp.uk.linux.org:/pub/linux/sct/kernel/
> 
> for the sake of anyone else helping with this.
> 
> Cheers,
>  Stephen

-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: 3rd version of R/W mmap_sem patch available

[Andrew Morton]

Linus Torvalds wrote:
> 
> On Wed, 21 Mar 2001, Andrew Morton wrote:
> >
> >       The handling of mm->rss is racy.  But I think
> >       it always has been?
> 
> It always has been. Right now I think we hold the page_table_lock over
> most of them, that the old patch to fix this might end up being just that
> one place. Somebody interested in checking?
> 

There were two places which needed fixing, and it was
pretty trivial.  With this patch, mm_struct.rss handling
is racefree on x86.  Some other archs (notably ia64/ia32)
are still a little racy on the exec() path.

I was sorely tempted to make put_dirty_page() require
that tsk->mm->page_table_lock be held by the caller,
which would save a bunch of locking.  But put_dirty_page()
is used by architectures which I don't understand.

The patch also includes a feeble attempt to document
some locking rules.



--- linux-2.4.3-pre6/include/linux/sched.h	Thu Mar 22 18:52:52 2001
+++ lk/include/linux/sched.h	Thu Mar 22 19:41:06 2001
@@ -209,9 +209,12 @@
 	atomic_t mm_count;			/* How many references to "struct mm_struct" (users count as 1) */
 	int map_count;				/* number of VMAs */
 	struct rw_semaphore mmap_sem;
-	spinlock_t page_table_lock;
+	spinlock_t page_table_lock;		/* Protects task page tables and mm->rss */
 
-	struct list_head mmlist;		/* List of all active mm's */
+	struct list_head mmlist;		/* List of all active mm's.  These are globally strung
+						 * together off init_mm.mmlist, and are protected
+						 * by mmlist_lock
+						 */
 
 	unsigned long start_code, end_code, start_data, end_data;
 	unsigned long start_brk, brk, start_stack;
--- linux-2.4.3-pre6/fs/exec.c	Thu Mar 22 18:52:52 2001
+++ lk/fs/exec.c	Thu Mar 22 19:51:35 2001
@@ -252,6 +252,8 @@
 /*
  * This routine is used to map in a page into an address space: needed by
  * execve() for the initial stack and environment pages.
+ *
+ * tsk->mmap_sem is held for writing.
  */
 void put_dirty_page(struct task_struct * tsk, struct page *page, unsigned long address)
 {
@@ -291,6 +293,7 @@
 	unsigned long stack_base;
 	struct vm_area_struct *mpnt;
 	int i;
+	unsigned long rss_increment = 0;
 
 	stack_base = STACK_TOP - MAX_ARG_PAGES*PAGE_SIZE;
 
@@ -322,11 +325,14 @@
 		struct page *page = bprm->page[i];
 		if (page) {
 			bprm->page[i] = NULL;
-			current->mm->rss++;
+			rss_increment++;
 			put_dirty_page(current,page,stack_base);
 		}
 		stack_base += PAGE_SIZE;
 	}
+	spin_lock(&current->mm->page_table_lock);
+	current->mm->rss += rss_increment;
+	spin_unlock(&current->mm->page_table_lock);
 	up_write(&current->mm->mmap_sem);
 	
 	return 0;
--- linux-2.4.3-pre6/mm/memory.c	Thu Mar 22 18:52:52 2001
+++ lk/mm/memory.c	Thu Mar 22 21:13:29 2001
@@ -374,7 +374,6 @@
 		address = (address + PGDIR_SIZE) & PGDIR_MASK;
 		dir++;
 	} while (address && (address < end));
-	spin_unlock(&mm->page_table_lock);
 	/*
 	 * Update rss for the mm_struct (not necessarily current->mm)
 	 * Notice that rss is an unsigned long.
@@ -383,6 +382,7 @@
 		mm->rss -= freed;
 	else
 		mm->rss = 0;
+	spin_unlock(&mm->page_table_lock);
 }
 
 
@@ -792,6 +792,8 @@
  *  - flush the old one
  *  - update the page tables
  *  - inform the TLB about the new one
+ *
+ * We hold the mm semaphore for reading and vma->vm_mm->page_table_lock
  */
 static inline void establish_pte(struct vm_area_struct * vma, unsigned long address, pte_t *page_table, pte_t entry)
 {
@@ -800,6 +802,9 @@
 	update_mmu_cache(vma, address, entry);
 }
 
+/*
+ * We hold the mm semaphore for reading and vma->vm_mm->page_table_lock
+ */
 static inline void break_cow(struct vm_area_struct * vma, struct page *	old_page, struct page * new_page, unsigned long address, 
 		pte_t *page_table)
 {
@@ -1024,8 +1029,7 @@
 }
 
 /*
- * We hold the mm semaphore and the page_table_lock on entry
- * and exit.
+ * We hold the mm semaphore and the page_table_lock on entry and exit.
  */
 static int do_swap_page(struct mm_struct * mm,
 	struct vm_area_struct * vma, unsigned long address,
--- linux-2.4.3-pre6/mm/mmap.c	Thu Mar 22 18:52:52 2001
+++ lk/mm/mmap.c	Thu Mar 22 19:19:08 2001
@@ -889,8 +889,8 @@
 	spin_lock(&mm->page_table_lock);
 	mpnt = mm->mmap;
 	mm->mmap = mm->mmap_avl = mm->mmap_cache = NULL;
-	spin_unlock(&mm->page_table_lock);
 	mm->rss = 0;
+	spin_unlock(&mm->page_table_lock);
 	mm->total_vm = 0;
 	mm->locked_vm = 0;
 
--- linux-2.4.3-pre6/mm/vmscan.c	Tue Jan 16 07:36:49 2001
+++ lk/mm/vmscan.c	Thu Mar 22 19:32:11 2001
@@ -25,16 +25,15 @@
 #include <asm/pgalloc.h>
 
 /*
- * The swap-out functions return 1 if they successfully
- * threw something out, and we got a free page. It returns
- * zero if it couldn't do anything, and any other value
- * indicates it decreased rss, but the page was shared.
+ * The swap-out function returns 1 if it successfully
+ * scanned all the pages it was asked to (`count').
+ * It returns zero if it couldn't do anything,
  *
- * NOTE! If it sleeps, it *must* return 1 to make sure we
- * don't continue with the swap-out. Otherwise we may be
- * using a process that no longer actually exists (it might
- * have died while we slept).
+ * rss may decrease because pages are shared, but this
+ * doesn't count as having freed a page.
  */
+
+/* mm->page_table_lock is held. mmap_sem is not held */
 static void try_to_swap_out(struct mm_struct * mm, struct vm_area_struct* vma, unsigned long address, pte_t * page_table, struct page *page)
 {
 	pte_t pte;
@@ -129,6 +128,7 @@
 	return;
 }
 
+/* mm->page_table_lock is held. mmap_sem is not held */
 static int swap_out_pmd(struct mm_struct * mm, struct vm_area_struct * vma, pmd_t *dir, unsigned long address, unsigned long end, int count)
 {
 	pte_t * pte;
@@ -165,6 +165,7 @@
 	return count;
 }
 
+/* mm->page_table_lock is held. mmap_sem is not held */
 static inline int swap_out_pgd(struct mm_struct * mm, struct vm_area_struct * vma, pgd_t *dir, unsigned long address, unsigned long end, int count)
 {
 	pmd_t * pmd;
@@ -194,6 +195,7 @@
 	return count;
 }
 
+/* mm->page_table_lock is held. mmap_sem is not held */
 static int swap_out_vma(struct mm_struct * mm, struct vm_area_struct * vma, unsigned long address, int count)
 {
 	pgd_t *pgdir;
@@ -218,6 +220,9 @@
 	return count;
 }
 
+/*
+ * Returns non-zero if we scanned all `count' pages
+ */
 static int swap_out_mm(struct mm_struct * mm, int count)
 {
 	unsigned long address;
--- linux-2.4.3-pre6/mm/swapfile.c	Sun Feb 25 17:37:14 2001
+++ lk/mm/swapfile.c	Thu Mar 22 19:56:36 2001
@@ -209,6 +209,7 @@
  * share this swap entry, so be cautious and let do_wp_page work out
  * what to do if a write is requested later.
  */
+/* tasklist_lock and vma->vm_mm->page_table_lock are held */
 static inline void unuse_pte(struct vm_area_struct * vma, unsigned long address,
 	pte_t *dir, swp_entry_t entry, struct page* page)
 {
@@ -234,6 +235,7 @@
 	++vma->vm_mm->rss;
 }
 
+/* tasklist_lock and vma->vm_mm->page_table_lock are held */
 static inline void unuse_pmd(struct vm_area_struct * vma, pmd_t *dir,
 	unsigned long address, unsigned long size, unsigned long offset,
 	swp_entry_t entry, struct page* page)
@@ -261,6 +263,7 @@
 	} while (address && (address < end));
 }
 
+/* tasklist_lock and vma->vm_mm->page_table_lock are held */
 static inline void unuse_pgd(struct vm_area_struct * vma, pgd_t *dir,
 	unsigned long address, unsigned long size,
 	swp_entry_t entry, struct page* page)
@@ -291,6 +294,7 @@
 	} while (address && (address < end));
 }
 
+/* tasklist_lock and vma->vm_mm->page_table_lock are held */
 static void unuse_vma(struct vm_area_struct * vma, pgd_t *pgdir,
 			swp_entry_t entry, struct page* page)
 {
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: 3rd version of R/W mmap_sem patch available

[Eric W. Biederman]

Andrew Morton <andrewm@uow.edu.au> writes:

> Jeff Garzik wrote:
> > 
> > Andrew Morton wrote:
> > > General comment: an expensive part of a pagefault
> > > is zeroing the new page.  It'd be nice if we could
> > > drop the page_table_lock while doing the clear_user_page()
> > > and, if possible, copy_user_page() functions.  Very nice.
> > 
> > People have talked before about creating zero pages in the background,
> > or creating them as a side effect of another operation (don't recall
> > details), so yeah this is definitely an area where some optimizations
> > could be done.  I wouldn't want to do it until 2.5 though...
> 
> Actually, I did this for x86 last weekend :) Initial results are
> disappointing. 
> 
> It creates a special uncachable mapping and sits there
> zeroing pages in a low-priority thread (also tried
> doing it in the idle task).

Well if you are going to mess with caching make the mapping write-combining
on x86..  You get much better performance.

Eric

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: 3rd version of R/W mmap_sem patch available

[Andrew Morton]

Rik van Riel wrote:
> 
> On Tue, 20 Mar 2001, Andi Kleen wrote:
> > On Tue, Mar 20, 2001 at 05:08:36PM +0100, Linus Torvalds wrote:
> > > > General comment: an expensive part of a pagefault
> > > > is zeroing the new page.  It'd be nice if we could
> > > > drop the page_table_lock while doing the clear_user_page()
> > > > and, if possible, copy_user_page() functions.  Very nice.
> > >
> > > I don't think it's worth it. We should have basically zero contention on
> > > this lock now, and adding complexity to try to release it sounds like a
> > > bad idea when the only way to make contention on it is (a) kswapd (only
> > > when paging stuff out) and (b) multiple threads (only when taking
> > > concurrent page faults).
> >
> > Isn't (b) a rather common case in multi threaded applications ?
> 
> Multiple threads pagefaulting on the SAME page of anonymous
> memory at the same time ?
> 
> I can imagine multiple threads pagefaulting on the same page
> of some mmaped database, but on the same page of anonymous
> memory ??

err...  If we hold mm->page_table_lock for a long time,
that's going to block all faulting threads which use this mm,
regardless of which page (or vma) they're faulting on, no?

I guess I've kind of lost the plot on why this patch exists
in the first place.  Was it simply to prevent vmstat from getting
stuck, or was it because we were seeing significant throughput
degradation for some workload?

If the latter, what workload was it?
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: 3rd version of R/W mmap_sem patch available

[Rik van Riel]

On Tue, 20 Mar 2001, Andi Kleen wrote:
> On Tue, Mar 20, 2001 at 05:08:36PM +0100, Linus Torvalds wrote:
> > > General comment: an expensive part of a pagefault
> > > is zeroing the new page.  It'd be nice if we could
> > > drop the page_table_lock while doing the clear_user_page()
> > > and, if possible, copy_user_page() functions.  Very nice.
> > 
> > I don't think it's worth it. We should have basically zero contention on
> > this lock now, and adding complexity to try to release it sounds like a
> > bad idea when the only way to make contention on it is (a) kswapd (only
> > when paging stuff out) and (b) multiple threads (only when taking
> > concurrent page faults).
> 
> Isn't (b) a rather common case in multi threaded applications ? 

Multiple threads pagefaulting on the SAME page of anonymous
memory at the same time ?

I can imagine multiple threads pagefaulting on the same page
of some mmaped database, but on the same page of anonymous
memory ??

regards,

Rik
--
Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

		http://www.surriel.com/
http://www.conectiva.com/	http://distro.conectiva.com.br/

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: 3rd version of R/W mmap_sem patch available

[Linus Torvalds]

On Tue, 20 Mar 2001, Andi Kleen wrote:
> >
> > I don't think it's worth it. We should have basically zero contention on
> > this lock now, and adding complexity to try to release it sounds like a
> > bad idea when the only way to make contention on it is (a) kswapd (only
> > when paging stuff out) and (b) multiple threads (only when taking
> > concurrent page faults).
>
> Isn't (b) a rather common case in multi threaded applications ?

Not if you're performance-sensitive, I bet. If you take so many pagefaults
that the page_table_lock ends up being a problem, you have _more_ problems
than that.

We'll see. I will certainly re-consider if it ends up being shown to be a
real problem. spinlock contention tends to be very easy to see on kernel
profiles, especially the way they're done on Linux/x86 (inline - so you
see evrey contention place separately).

		Linus

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: 3rd version of R/W mmap_sem patch available

[Andi Kleen]

On Tue, Mar 20, 2001 at 05:08:36PM +0100, Linus Torvalds wrote:
> > General comment: an expensive part of a pagefault
> > is zeroing the new page.  It'd be nice if we could
> > drop the page_table_lock while doing the clear_user_page()
> > and, if possible, copy_user_page() functions.  Very nice.
> 
> I don't think it's worth it. We should have basically zero contention on
> this lock now, and adding complexity to try to release it sounds like a
> bad idea when the only way to make contention on it is (a) kswapd (only
> when paging stuff out) and (b) multiple threads (only when taking
> concurrent page faults).

Isn't (b) a rather common case in multi threaded applications ? 

-Andi
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: 3rd version of R/W mmap_sem patch available

[Linus Torvalds]

On Wed, 21 Mar 2001, Andrew Morton wrote:
>
> I stared long and hard at expand_stack().  Its first access
> to vma->vm_start appears to be safe wrt other threads which
> can alter this, but perhaps the page_table_lock should be
> acquired earlier here?

Hmm.. Probably.

> We now have:
>
> 	free_pgd_slow();
> 	pmd_free_slow();
> 	pte_free_slow();
>
> Could we please have consistent naming back?

Yes, I want to rename free_pgd_slow() to match the others.

> in do_wp_page():
>
>         spin_unlock(&mm->page_table_lock);
>         new_page = alloc_page(GFP_HIGHUSER);
>         if (!new_page)
>                 return -1;
>         spin_lock(&mm->page_table_lock);
>
> Should retake the spinlock before returning.

Thanks, done.

> General comment: an expensive part of a pagefault
> is zeroing the new page.  It'd be nice if we could
> drop the page_table_lock while doing the clear_user_page()
> and, if possible, copy_user_page() functions.  Very nice.

I don't think it's worth it. We should have basically zero contention on
this lock now, and adding complexity to try to release it sounds like a
bad idea when the only way to make contention on it is (a) kswapd (only
when paging stuff out) and (b) multiple threads (only when taking
concurrent page faults).

So I don't really see the point of bothering.

> read_zero_pagealigned()->zap_page_range()
>
> 	The handling of mm->rss is racy.  But I think
> 	it always has been?

It always has been. Right now I think we hold the page_table_lock over
most of them, that the old patch to fix this might end up being just that
one place. Somebody interested in checking?

> This comment in mprotect.c:
> +       /* XXX: maybe this could be down_read ??? - Rik */
>
> I don't think so.  The decisions about where in the
> vma tree to place the new vma would be unprotected and racy.

I think we could potentially find it useful in places to have a

	down_write_start();

	down_write_commit();

in a few places, where "down_write_start()" only guarantees exclusion of
other writers (and write-startes), while down_write_commit() waits for all
the readers to go away.

		Linus

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: 3rd version of R/W mmap_sem patch available

[Andrew Morton]

Jeff Garzik wrote:
> 
> Andrew Morton wrote:
> > General comment: an expensive part of a pagefault
> > is zeroing the new page.  It'd be nice if we could
> > drop the page_table_lock while doing the clear_user_page()
> > and, if possible, copy_user_page() functions.  Very nice.
> 
> People have talked before about creating zero pages in the background,
> or creating them as a side effect of another operation (don't recall
> details), so yeah this is definitely an area where some optimizations
> could be done.  I wouldn't want to do it until 2.5 though...

Actually, I did this for x86 last weekend :) Initial results are
disappointing. 

It creates a special uncachable mapping and sits there
zeroing pages in a low-priority thread (also tried
doing it in the idle task).

It was made uncachable because a lot of the
cost of clearing a page at fault time will be in
the eviction of live, useful data.

But clearing an uncachable page takes about eight times
as long as clearing a cachable, but uncached one.  Now,
if there was a hardware peripheral which could zero pages
quickly, that'd be good.

I dunno.  I need to test it on more workloads.  I was
using kernel compiles and these have a very low
sleeping-on-IO to faulting-zeropages-in ratio.  The
walltime for kernel builds was unaltered.

Certainly one can write silly applications which
speed up by a factor of ten with this change.

I'll finish this work off sometime in the next week,
stick it on the web.


But that's all orthogonal to my comment.  We'd
get significantly better threaded use of a single
mm if we didn't block it while clearing and copying 
pages.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: 3rd version of R/W mmap_sem patch available

[Jeff Garzik]

Andrew Morton wrote:
> General comment: an expensive part of a pagefault
> is zeroing the new page.  It'd be nice if we could
> drop the page_table_lock while doing the clear_user_page()
> and, if possible, copy_user_page() functions.  Very nice.

People have talked before about creating zero pages in the background,
or creating them as a side effect of another operation (don't recall
details), so yeah this is definitely an area where some optimizations
could be done.  I wouldn't want to do it until 2.5 though...

-- 
Jeff Garzik       | May you have warm words on a cold evening,
Building 1024     | a full mooon on a dark night,
MandrakeSoft      | and a smooth road all the way to your door.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: 3rd version of R/W mmap_sem patch available

[Jeff Garzik]

-- 
Jeff Garzik       | May you have warm words on a cold evening,
Building 1024     | a full mooon on a dark night,
MandrakeSoft      | and a smooth road all the way to your door.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: 3rd version of R/W mmap_sem patch available

[Andrew Morton]

Linus Torvalds wrote:
> 
> There is a 2.4.3-pre5 in the test-directory on ftp.kernel.org.
> 

I stared long and hard at expand_stack().  Its first access
to vma->vm_start appears to be safe wrt other threads which 
can alter this, but perhaps the page_table_lock should be
acquired earlier here?



We now have:

	free_pgd_slow();
	pmd_free_slow();
	pte_free_slow();

Could we please have consistent naming back?



in do_wp_page():

        spin_unlock(&mm->page_table_lock);
        new_page = alloc_page(GFP_HIGHUSER);
        if (!new_page)
                return -1;
        spin_lock(&mm->page_table_lock);

Should retake the spinlock before returning.



General comment: an expensive part of a pagefault
is zeroing the new page.  It'd be nice if we could
drop the page_table_lock while doing the clear_user_page()
and, if possible, copy_user_page() functions.  Very nice.




read_zero_pagealigned()->zap_page_range()

	The handling of mm->rss is racy.  But I think
	it always has been?




This comment in mprotect.c:
+       /* XXX: maybe this could be down_read ??? - Rik */

I don't think so.  The decisions about where in the 
vma tree to place the new vma would be unprotected and racy.



Apart from that - I looked at it (x86-only) very closely and
it seems solid.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: 3rd version of R/W mmap_sem patch available

[Eric W. Biederman]

Linus Torvalds <torvalds@transmeta.com> writes:

> On Mon, 19 Mar 2001, Linus Torvalds wrote:
> >
> > Although I'd prefer to see somebody check out the other architectures,
> > to do the (pretty trivial) changes to make them support properly
> > threaded page faults. I'd hate to have two pre-patches without any
> > input from other architectures..
> 
> These are the trivial fixes to make -pre5 be spinlock-debugging-clean and
> fix the missing unlock in copy_page_range(). I'd really like to hear from
> architecture maintainers if possible.
> 
> 		Linus

Hmm.  It looks like remap_area_pages doesn't return an error...
- return 0;
+ return error;


Eric
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: 3rd version of R/W mmap_sem patch available

[Linus Torvalds]

On Mon, 19 Mar 2001, Linus Torvalds wrote:
>
> Although I'd prefer to see somebody check out the other architectures,
> to do the (pretty trivial) changes to make them support properly
> threaded page faults. I'd hate to have two pre-patches without any
> input from other architectures..

These are the trivial fixes to make -pre5 be spinlock-debugging-clean and
fix the missing unlock in copy_page_range(). I'd really like to hear from
architecture maintainers if possible.

		Linus

----
diff -u --recursive --new-file pre5/linux/arch/i386/mm/ioremap.c linux/arch/i386/mm/ioremap.c
--- pre5/linux/arch/i386/mm/ioremap.c	Mon Mar 19 18:49:18 2001
+++ linux/arch/i386/mm/ioremap.c	Mon Mar 19 21:25:16 2001
@@ -62,6 +62,7 @@
 static int remap_area_pages(unsigned long address, unsigned long phys_addr,
 				 unsigned long size, unsigned long flags)
 {
+	int error;
 	pgd_t * dir;
 	unsigned long end = address + size;

@@ -70,17 +71,21 @@
 	flush_cache_all();
 	if (address >= end)
 		BUG();
+	spin_lock(&init_mm.page_table_lock);
 	do {
 		pmd_t *pmd;
 		pmd = pmd_alloc(&init_mm, dir, address);
+		error = -ENOMEM;
 		if (!pmd)
-			return -ENOMEM;
+			break;
 		if (remap_area_pmd(pmd, address, end - address,
 					 phys_addr + address, flags))
-			return -ENOMEM;
+			break;
+		error = 0;
 		address = (address + PGDIR_SIZE) & PGDIR_MASK;
 		dir++;
 	} while (address && (address < end));
+	spin_unlock(&init_mm.page_table_lock);
 	flush_tlb_all();
 	return 0;
 }
diff -u --recursive --new-file pre5/linux/mm/memory.c linux/mm/memory.c
--- pre5/linux/mm/memory.c	Mon Mar 19 18:49:20 2001
+++ linux/mm/memory.c	Mon Mar 19 22:49:39 2001
@@ -160,6 +160,7 @@
 	src_pgd = pgd_offset(src, address)-1;
 	dst_pgd = pgd_offset(dst, address)-1;

+	spin_lock(&dst->page_table_lock);
 	for (;;) {
 		pmd_t * src_pmd, * dst_pmd;

@@ -178,7 +179,6 @@
 			continue;
 		}

-		spin_lock(&dst->page_table_lock);
 		src_pmd = pmd_offset(src_pgd, address);
 		dst_pmd = pmd_alloc(dst, dst_pgd, address);
 		if (!dst_pmd)
@@ -247,13 +247,10 @@
 cont_copy_pmd_range:	src_pmd++;
 			dst_pmd++;
 		} while ((unsigned long)src_pmd & PMD_TABLE_MASK);
-		spin_unlock(&dst->page_table_lock);
 	}
-out:
-	return 0;
-
 out_unlock:
 	spin_unlock(&src->page_table_lock);
+out:
 	spin_unlock(&dst->page_table_lock);
 	return 0;


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: 3rd version of R/W mmap_sem patch available

[Linus Torvalds]

On Tue, 20 Mar 2001, Marcelo Tosatti wrote:
>
> I'll put pre5 in and try to reproduce the problem (I hitted it while
> running pgbench + shmtest).

I found a case where pre5 will forget to unlock the page_table_lock (in
copy_page_range()), and one place where I had missed the lock altogether
(in ioremap()), so I'll make a pre6 (neither is a problem on UP, though,
so pre5 is not unusable - even on SMP it works really well until you hit
the case where it forgets to unlock ;).

Although I'd prefer to see somebody check out the other architectures, to
do the (pretty trivial) changes to make them support properly threaded
page faults. I'd hate to have two pre-patches without any input from other
architectures..

		Linus

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: 3rd version of R/W mmap_sem patch available

[Linus Torvalds]

On Tue, 20 Mar 2001, Marcelo Tosatti wrote:
>
> Could the IDE one cause corruption ?

Only with broken disks, as far as we know right now. There's been so far
just one report of this problem, and nobody has heard back about which
disk this was.. And it should be noisy about it when it happens -
complaining about lost interrupts and resetting the IDE controller.

So unlikely.

		Linus

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: 3rd version of R/W mmap_sem patch available

[Marcelo Tosatti]

On Mon, 19 Mar 2001, Linus Torvalds wrote:

> 
> 
> On Tue, 20 Mar 2001, Marcelo Tosatti wrote:
> >
> > Could the IDE one cause corruption ?
> 
> Only with broken disks, as far as we know right now. There's been so far
> just one report of this problem, and nobody has heard back about which
> disk this was.. And it should be noisy about it when it happens -
> complaining about lost interrupts and resetting the IDE controller.
> 
> So unlikely.

Ok, so I think we have a problem. The disk is OK -- no lost interrupts or
resets. Just this message on syslog and pgbench complaining about
corruption of the database.

I'll put pre5 in and try to reproduce the problem (I hitted it while
running pgbench + shmtest). 

Damn. 

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: 3rd version of R/W mmap_sem patch available

[Marcelo Tosatti]

On Mon, 19 Mar 2001, Linus Torvalds wrote:

> 
> There is a 2.4.3-pre5 in the test-directory on ftp.kernel.org.
> 
> The complete changelog is appended, but the biggest recent change is the
> mmap_sem change, which I updated with new locking rules for pte/pmd_alloc
> to avoid the race on the actual page table build.
> 
> This has only been tested on i386 without PAE, and is known to break other
> architectures. Ingo, mind checking what PAE needs? Generally, the changes
> are simple, and really only implies changing the pte/pmd allocation
> functions to _only_ allocate (ie removing the stuff that actually modifies
> the page tables, as that is now handled by generic code), and to make sure
> that the "pgd/pmd_populate()" functions do the right thing.
> 
> I have also removed the xxx_kernel() functions - for architectures that
> need them, I suspect that the right approach is to just make the
> "populate" funtions notice when "mm" is "init_mm", the kernel context.
> That removed a lot of duplicate code that had little good reason.
> 
> This pre-release is meant mainly as a synchronization point for mm
> developers, not for generic use.
> 
> 	Thanks,
> 
> 		Linus
> 
> 
> -----
> -pre5:
>   - Rik van Riel and others: mm rw-semaphore (ps/top ok when swapping)
>   - IDE: 256 sectors at a time is legal, but apparently confuses some
>     drives. Max out at 255 sectors instead.

Could the IDE one cause corruption ?

EXT2-fs error (device ide0(3,1)): ext2_free_blocks: bit already cleared
for block 6211

Just hitted this now with pre3. 

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: 3rd version of R/W mmap_sem patch available

[Linus Torvalds]

There is a 2.4.3-pre5 in the test-directory on ftp.kernel.org.

The complete changelog is appended, but the biggest recent change is the
mmap_sem change, which I updated with new locking rules for pte/pmd_alloc
to avoid the race on the actual page table build.

This has only been tested on i386 without PAE, and is known to break other
architectures. Ingo, mind checking what PAE needs? Generally, the changes
are simple, and really only implies changing the pte/pmd allocation
functions to _only_ allocate (ie removing the stuff that actually modifies
the page tables, as that is now handled by generic code), and to make sure
that the "pgd/pmd_populate()" functions do the right thing.

I have also removed the xxx_kernel() functions - for architectures that
need them, I suspect that the right approach is to just make the
"populate" funtions notice when "mm" is "init_mm", the kernel context.
That removed a lot of duplicate code that had little good reason.

This pre-release is meant mainly as a synchronization point for mm
developers, not for generic use.

	Thanks,

		Linus


-----
-pre5:
  - Rik van Riel and others: mm rw-semaphore (ps/top ok when swapping)
  - IDE: 256 sectors at a time is legal, but apparently confuses some
    drives. Max out at 255 sectors instead.
  - Petko Manolov: USB pegasus driver update
  - make the boottime memory map printout at least almost readable.
  - USB driver updates
  - pte_alloc()/pmd_alloc() need page_table_lock.

-pre4:
  - Petr Vandrovec, Al Viro: dentry revalidation fixes
  - Stephen Tweedie / Manfred Spraul: kswapd and ptrace race
  - Neil Brown: nfsd/rpc/raid cleanups and fixes

-pre3:
  - Alan Cox: continued merging
  - Urban Widmark: smbfs fix (d_add on already hashed dentry - no-no).
  - Andrew Morton: 3c59x update
  - Jeff Garzik: network driver cleanups and fixes
  - Gerard Roudier: sym-ncr drivers update
  - Jens Axboe: more loop cleanups and fixes
  - David Miller: sparc update, some networking fixes

-pre2:
  - Jens Axboe: fix loop device deadlocks
  - Greg KH: USB updates
  - Alan Cox: continued merging
  - Tim Waugh: parport and documentation updates
  - Cort Dougan: PowerPC merge
  - Jeff Garzik: network driver updates
  - Justin Gibbs: new and much improved aic7xxx driver 6.1.5

-pre1:
  - Chris Mason: reiserfs, another null bytes bug
  - Andrea Arkangeli: make SMP Athlon build
  - Alexander Zarochentcev: reiserfs directory fsync SMP locking fix
  - Jeff Garzik: PCI network driver updates
  - Alan Cox: continue merging
  - Ingo Molnar: fix RAID AUTORUN ioctl, scheduling improvements

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

3rd version of R/W mmap_sem patch available

[Rik van Riel]

On Mon, 19 Mar 2001, Mike Galbraith wrote:

> @@ -1135,6 +1170,7 @@
	[large patch]

I've been finding small bugs in both my late-night code and in
Mike's code and have redone the changes in do_anonymous_page(),
do_no_page() and do_swap_page() much more carefully...

Now the code is beautiful and it might even be bugfree ;)

If you feel particularly adventurous, please help me test the
patch; it is available from:

	http://www.surriel.com/patches/2.4/2.4.2-ac20-rwmmap_sem3

regards,

Rik
--
Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml

Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

		http://www.surriel.com/
http://www.conectiva.com/	http://distro.conectiva.com/

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: 3rd version of R/W mmap_sem patch available

[Linus Torvalds]

> Now the code is beautiful and it might even be bugfree ;)

I'm applying this to my tree - I'm not exactly comfortable with this
during the 2.4.x timeframe, but at the same time I'm even less comfortable
with the current alternative, which is to make the regular semaphores
fairer (we tried it once, and the implementation had problems, I'm not
going to try that again during 2.4.x).

Besides, the fair semaphores would potentially slow things down, while
this potentially speeds things up. So.. It looks obvious enough.

		Linus

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/