Re: [patch 02/20] make the inode i_mmap_lock a reader/writer lock

2008-01-07 Thread Nick Piggin
On Thursday 03 January 2008 19:55, Ingo Molnar wrote: > * Nick Piggin <[EMAIL PROTECTED]> wrote: > > > Have you done anything more with allowing > 256 CPUS in this > > > spinlock patch? We've been testing with 1k cpus and to verify with > > > -mm kernel, we need to "unpatch" these spinlock changes

Re: [patch 02/20] make the inode i_mmap_lock a reader/writer lock

2008-01-03 Thread Ingo Molnar
* Nick Piggin <[EMAIL PROTECTED]> wrote: > > Have you done anything more with allowing > 256 CPUS in this > > spinlock patch? We've been testing with 1k cpus and to verify with > > -mm kernel, we need to "unpatch" these spinlock changes. > > Hi Mike, > > Actually I had it in my mind that 64

Re: [patch 02/20] make the inode i_mmap_lock a reader/writer lock

2008-01-02 Thread Nick Piggin
On Thursday 03 January 2008 10:35, Mike Travis wrote: > Hi Nick, > > Have you done anything more with allowing > 256 CPUS in this spinlock > patch? We've been testing with 1k cpus and to verify with -mm kernel, > we need to "unpatch" these spinlock changes. > > Thanks, > Mike Hi Mike, Actually I

Re: [patch 02/20] make the inode i_mmap_lock a reader/writer lock

2008-01-02 Thread Mike Travis
Hi Nick, Have you done anything more with allowing > 256 CPUS in this spinlock patch? We've been testing with 1k cpus and to verify with -mm kernel, we need to "unpatch" these spinlock changes. Thanks, Mike Nick Piggin wrote: > On Thursday 20 December 2007 18:04, Christoph Lameter wrote: >>> Th

Re: [patch 02/20] make the inode i_mmap_lock a reader/writer lock

2007-12-20 Thread Nick Piggin
On Thursday 20 December 2007 18:04, Christoph Lameter wrote: > > The only reason the x86 ticket locks have the 256 CPu limit is that > > if they go any bigger, we can't use the partial registers so would > > have to have a few more instructions. > > x86_64 is going up to 4k or 16k cpus soon for our

Re: [patch 02/20] make the inode i_mmap_lock a reader/writer lock

2007-12-19 Thread Christoph Lameter
> The only reason the x86 ticket locks have the 256 CPu limit is that > if they go any bigger, we can't use the partial registers so would > have to have a few more instructions. x86_64 is going up to 4k or 16k cpus soon for our new hardware. > A 32 bit spinlock would allow 64K cpus (ticket loc

Re: [patch 02/20] make the inode i_mmap_lock a reader/writer lock

2007-12-19 Thread Nick Piggin
On Thursday 20 December 2007 06:28, Peter Zijlstra wrote: > On Wed, 2007-12-19 at 11:53 -0500, Lee Schermerhorn wrote: > > On Wed, 2007-12-19 at 11:31 -0500, Rik van Riel wrote: > > > On Wed, 19 Dec 2007 10:52:09 -0500 > > > > > > Lee Schermerhorn <[EMAIL PROTECTED]> wrote: > > > > I keep these pat

Re: [patch 02/20] make the inode i_mmap_lock a reader/writer lock

2007-12-19 Thread Peter Zijlstra
On Wed, 2007-12-19 at 11:53 -0500, Lee Schermerhorn wrote: > On Wed, 2007-12-19 at 11:31 -0500, Rik van Riel wrote: > > On Wed, 19 Dec 2007 10:52:09 -0500 > > Lee Schermerhorn <[EMAIL PROTECTED]> wrote: > > > > > I keep these patches up to date for testing. I don't have conclusive > > > evidence

Re: [patch 02/20] make the inode i_mmap_lock a reader/writer lock

2007-12-19 Thread Lee Schermerhorn
On Wed, 2007-12-19 at 11:31 -0500, Rik van Riel wrote: > On Wed, 19 Dec 2007 10:52:09 -0500 > Lee Schermerhorn <[EMAIL PROTECTED]> wrote: > > > I keep these patches up to date for testing. I don't have conclusive > > evidence whether they alleviate or exacerbate the problem nor by how > > much.

Re: [patch 02/20] make the inode i_mmap_lock a reader/writer lock

2007-12-19 Thread Rik van Riel
On Wed, 19 Dec 2007 10:52:09 -0500 Lee Schermerhorn <[EMAIL PROTECTED]> wrote: > I keep these patches up to date for testing. I don't have conclusive > evidence whether they alleviate or exacerbate the problem nor by how > much. When the queued locking from Ingo's x86 tree hits mainline, I sus

Re: [patch 02/20] make the inode i_mmap_lock a reader/writer lock

2007-12-19 Thread Lee Schermerhorn
On Wed, 2007-12-19 at 11:48 +1100, Nick Piggin wrote: > On Wednesday 19 December 2007 08:15, Rik van Riel wrote: > > I have seen soft cpu lockups in page_referenced_file() due to > > contention on i_mmap_lock() for different pages. Making the > > i_mmap_lock a reader/writer lock should increase pa

Re: [patch 02/20] make the inode i_mmap_lock a reader/writer lock

2007-12-18 Thread KOSAKI Motohiro
Hi > > rmap: try_to_unmap_file() required new cond_resched_rwlock(). > > To reduce code duplication, I recast cond_resched_lock() as a > > [static inline] wrapper around reworked cond_sched_lock() => > > __cond_resched_lock(void *lock, int type). > > New cond_resched_rwlock() implemented as anoth

Re: [patch 02/20] make the inode i_mmap_lock a reader/writer lock

2007-12-18 Thread Nick Piggin
On Wednesday 19 December 2007 08:15, Rik van Riel wrote: > I have seen soft cpu lockups in page_referenced_file() due to > contention on i_mmap_lock() for different pages. Making the > i_mmap_lock a reader/writer lock should increase parallelism > in vmscan for file back pages mapped into many add

[patch 02/20] make the inode i_mmap_lock a reader/writer lock

2007-12-18 Thread Rik van Riel
I have seen soft cpu lockups in page_referenced_file() due to contention on i_mmap_lock() for different pages. Making the i_mmap_lock a reader/writer lock should increase parallelism in vmscan for file back pages mapped into many address spaces. Read lock the i_mmap_lock for all usage except: 1