Re: [PATCH 0/8] remove i_alloc_sem

2011-06-23 Thread Christoph Hellwig
On Wed, Jun 22, 2011 at 08:13:42PM +0200, Jan Kara wrote: No problem. Just we have to somehow coordinate with Christoph... Either he can avoid touching ext4 and merge his patch set after you merge my patch or he can take my patch instead of his ext4 change. Since my patch touches only

Re: [PATCH 0/8] remove i_alloc_sem

2011-06-22 Thread Christoph Hellwig
On Wed, Jun 22, 2011 at 01:54:25AM +0200, Jan Kara wrote: ext4 abuse should be gone when Ted merges my rewrite of ext4_page_mkwrite()... Ted, what happened to that patch. Should I resend it? So how should we coordinate merging the two? -- To unsubscribe from this list: send the line

Re: [PATCH 0/8] remove i_alloc_sem

2011-06-22 Thread Ted Ts'o
On Wed, Jun 22, 2011 at 01:54:25AM +0200, Jan Kara wrote: ext4_page_mkwrite()... Ted, what happened to that patch. Should I resend it? So assuming I fix the refcounting issue in fs/ext4/page_io.c (which I will do not dropping the page's refcount until after the workqueue finishes its job), does

Re: [PATCH 0/8] remove i_alloc_sem

2011-06-21 Thread Jan Kara
On Mon 20-06-11 16:15:33, Christoph Hellwig wrote: i_alloc_sem has always been a bit of an odd lock. It's the only remaining rw_semaphore that can be released by a different thread than the one that locked it, and it's use case in the core direct I/O code is more like a counter given that the

[PATCH 0/8] remove i_alloc_sem

2011-06-20 Thread Christoph Hellwig
i_alloc_sem has always been a bit of an odd lock. It's the only remaining rw_semaphore that can be released by a different thread than the one that locked it, and it's use case in the core direct I/O code is more like a counter given that the writers already have external serialization. This

Re: [PATCH 0/8] remove i_alloc_sem

2011-06-20 Thread Christoph Hellwig
On Mon, Jun 20, 2011 at 04:15:33PM -0400, Christoph Hellwig wrote: This series removes it in favour of a simpler counter scheme, thus getting rid of the rw_semaphore non-owner APIs as requests by Thomas, while at the same time shrinking the size of struct inode by 160 bytes on 64-bit systems.