Re: changing mm->mmap_sem (was: Re: system call for processinformation?)

2001-03-18 Thread Rik van Riel
On Sun, 18 Mar 2001, Linus Torvalds wrote: > On Sun, 18 Mar 2001, Rik van Riel wrote: > > > > Indeed, having threaded apps do multiple page faults at the > > same time is the main goal of this patch. However, I don't > > see how it would be good for scalability to have multiple > > threads fault

Re: changing mm->mmap_sem (was: Re: system call for processinformation?)

2001-03-18 Thread Linus Torvalds
On Sun, 18 Mar 2001, Rik van Riel wrote: > > Indeed, having threaded apps do multiple page faults at the > same time is the main goal of this patch. However, I don't > see how it would be good for scalability to have multiple > threads fault in the same page at the same time, when they > could

Re: changing mm->mmap_sem (was: Re: system call for processinformation?)

2001-03-18 Thread Rik van Riel
On Sun, 18 Mar 2001, Linus Torvalds wrote: > In article <[EMAIL PROTECTED]>, > Rik van Riel <[EMAIL PROTECTED]> wrote: > > > >OK, I'll write some code to prevent multiple threads from > >stepping all over each other when they pagefault at the > >same address. > > > >What would be the preferred

Re: changing mm->mmap_sem (was: Re: system call for processinformation?)

2001-03-18 Thread Linus Torvalds
In article <[EMAIL PROTECTED]>, Rik van Riel <[EMAIL PROTECTED]> wrote: > >OK, I'll write some code to prevent multiple threads from >stepping all over each other when they pagefault at the >same address. > >What would be the preferred method of fixing this ? > >- fixing do_swap_page and all

Re: changing mm->mmap_sem (was: Re: system call for processinformation?)

2001-03-18 Thread Rik van Riel
On Sun, 18 Mar 2001, Mike Galbraith wrote: > > No, this was make -j30 bzImage. (nscd was running though...) > > I rebooted, shut down nscd prior to testing and did 5 builds in a row > without a single gripe. Started nscd for sixth run and instantly the > kernel griped. Yup.. threaded apps

Re: changing mm->mmap_sem (was: Re: system call for processinformation?)

2001-03-18 Thread Mike Galbraith
On Sun, 18 Mar 2001, Rik van Riel wrote: > > VFS: Mounted root (ext2 filesystem) readonly. > > Freeing unused kernel memory: 196k freed > > Adding Swap: 265064k swap-space (priority 2) > > VM: Bad swap entry 00011e00 > > VM: Bad swap entry 00058d00 > > Unused swap offset entry in swap_dup

Re: changing mm->mmap_sem (was: Re: system call for processinformation?)

2001-03-18 Thread Rik van Riel
On Sun, 18 Mar 2001, Manfred Spraul wrote: > > The problem is that mmap_sem seems to be protecting the list > > of VMAs, so taking _only_ the page_table_lock could let a VMA > > change under us while a page fault is underway ... > > No, that can't happen. > VMA changes only happen if both the

Re: changing mm->mmap_sem (was: Re: system call for processinformation?)

2001-03-18 Thread Rik van Riel
On Sun, 18 Mar 2001, Mike Galbraith wrote: > I gave this patch a try, and the initial results are extremely encouraging. > Not only do I have vmstat (SCHED_RR) info in realtime with zero delays :)) > I also have a _nice_ throughput improvement. There are some worrisome > warnings below along

Re: changing mm->mmap_sem (was: Re: system call for processinformation?)

2001-03-18 Thread Mike Galbraith
On Sun, 18 Mar 2001, Rik van Riel wrote: > On Fri, 16 Mar 2001, Stephen C. Tweedie wrote: > > > Right, I'm not suggesting removing that: making the mmap_sem > > read/write is fine, but yes, we still need that semaphore. > > Initial patch (against 2.4.2-ac20) is available at >

Re: changing mm-mmap_sem (was: Re: system call for processinformation?)

2001-03-18 Thread Mike Galbraith
On Sun, 18 Mar 2001, Rik van Riel wrote: On Fri, 16 Mar 2001, Stephen C. Tweedie wrote: Right, I'm not suggesting removing that: making the mmap_sem read/write is fine, but yes, we still need that semaphore. Initial patch (against 2.4.2-ac20) is available at

Re: changing mm-mmap_sem (was: Re: system call for processinformation?)

2001-03-18 Thread Rik van Riel
On Sun, 18 Mar 2001, Mike Galbraith wrote: I gave this patch a try, and the initial results are extremely encouraging. Not only do I have vmstat (SCHED_RR) info in realtime with zero delays :)) I also have a _nice_ throughput improvement. There are some worrisome warnings below along with

Re: changing mm-mmap_sem (was: Re: system call for processinformation?)

2001-03-18 Thread Mike Galbraith
On Sun, 18 Mar 2001, Rik van Riel wrote: VFS: Mounted root (ext2 filesystem) readonly. Freeing unused kernel memory: 196k freed Adding Swap: 265064k swap-space (priority 2) VM: Bad swap entry 00011e00 VM: Bad swap entry 00058d00 Unused swap offset entry in swap_dup 00058d00 Unused

Re: changing mm-mmap_sem (was: Re: system call for processinformation?)

2001-03-18 Thread Rik van Riel
On Sun, 18 Mar 2001, Mike Galbraith wrote: No, this was make -j30 bzImage. (nscd was running though...) I rebooted, shut down nscd prior to testing and did 5 builds in a row without a single gripe. Started nscd for sixth run and instantly the kernel griped. Yup.. threaded apps pushing

Re: changing mm-mmap_sem (was: Re: system call for processinformation?)

2001-03-18 Thread Linus Torvalds
In article [EMAIL PROTECTED], Rik van Riel [EMAIL PROTECTED] wrote: OK, I'll write some code to prevent multiple threads from stepping all over each other when they pagefault at the same address. What would be the preferred method of fixing this ? - fixing do_swap_page and all -nopage

Re: changing mm-mmap_sem (was: Re: system call for processinformation?)

2001-03-18 Thread Rik van Riel
On Sun, 18 Mar 2001, Linus Torvalds wrote: In article [EMAIL PROTECTED], Rik van Riel [EMAIL PROTECTED] wrote: OK, I'll write some code to prevent multiple threads from stepping all over each other when they pagefault at the same address. What would be the preferred method of fixing

Re: changing mm-mmap_sem (was: Re: system call for processinformation?)

2001-03-18 Thread Linus Torvalds
On Sun, 18 Mar 2001, Rik van Riel wrote: Indeed, having threaded apps do multiple page faults at the same time is the main goal of this patch. However, I don't see how it would be good for scalability to have multiple threads fault in the same page at the same time, when they could just

Re: changing mm-mmap_sem (was: Re: system call for processinformation?)

2001-03-18 Thread Rik van Riel
On Sun, 18 Mar 2001, Linus Torvalds wrote: On Sun, 18 Mar 2001, Rik van Riel wrote: Indeed, having threaded apps do multiple page faults at the same time is the main goal of this patch. However, I don't see how it would be good for scalability to have multiple threads fault in the same

Re: changing mm->mmap_sem (was: Re: system call for processinformation?)

2001-03-17 Thread Rik van Riel
On Fri, 16 Mar 2001, Stephen C. Tweedie wrote: > Right, I'm not suggesting removing that: making the mmap_sem > read/write is fine, but yes, we still need that semaphore. Initial patch (against 2.4.2-ac20) is available at http://www.surriel.com/patches/ > But as for the "page faults would use

Re: changing mm-mmap_sem (was: Re: system call for processinformation?)

2001-03-17 Thread Rik van Riel
On Fri, 16 Mar 2001, Stephen C. Tweedie wrote: Right, I'm not suggesting removing that: making the mmap_sem read/write is fine, but yes, we still need that semaphore. Initial patch (against 2.4.2-ac20) is available at http://www.surriel.com/patches/ But as for the "page faults would use an

Re: changing mm->mmap_sem (was: Re: system call for processinformation?)

2001-03-16 Thread Rik van Riel
On Fri, 16 Mar 2001, Stephen C. Tweedie wrote: > On Thu, Mar 15, 2001 at 09:24:59AM -0300, Rik van Riel wrote: > > On Wed, 14 Mar 2001, Rik van Riel wrote: > > > The mmap_sem is used in procfs to prevent the list of VMAs > > from changing. In the page fault code it seems to be used > > to

Re: changing mm-mmap_sem (was: Re: system call for processinformation?)

2001-03-16 Thread Rik van Riel
On Fri, 16 Mar 2001, Stephen C. Tweedie wrote: On Thu, Mar 15, 2001 at 09:24:59AM -0300, Rik van Riel wrote: On Wed, 14 Mar 2001, Rik van Riel wrote: The mmap_sem is used in procfs to prevent the list of VMAs from changing. In the page fault code it seems to be used to prevent other