- 1. [PATCH 2/4] xfs: replace i_flock with a sleeping bitlock (score: 1)
- Author: Christoph Hellwig <hch@xxxxxxxxxxxxx>
- Date: Tue, 18 Oct 2011 16:13:06 -0400
- We almost never block on i_flock, the exception is synchronous inode flushing. Instead of bloating the inode with a 16/24-byte completion that we abuse as a semaphore just implement it as a bitlock t
- /archives/xfs/2011-10/msg00362.html (16,811 bytes)
- 2. Re: [PATCH 2/4] xfs: replace i_flock with a sleeping bitlock (score: 1)
- Author: Dave Chinner <david@xxxxxxxxxxxxx>
- Date: Wed, 19 Oct 2011 11:42:06 +1100
- ..... Given that the only way that the inode will become unlocked is for IO to complete, that makes this an IO wait, right? Perhaps this should call io_schedule() in that case? Any reason for leaving
- /archives/xfs/2011-10/msg00369.html (11,026 bytes)
- 3. Re: [PATCH 2/4] xfs: replace i_flock with a sleeping bitlock (score: 1)
- Author: Christoph Hellwig <hch@xxxxxxxxxxxxx>
- Date: Wed, 19 Oct 2011 05:01:06 -0400
- It probably should, and would help a bit with our %iowait accounting. The biggie for that is the buffer lock, though. Either we'll need a variant of the semaphore that does io_schedule, which is prob
- /archives/xfs/2011-10/msg00373.html (11,303 bytes)
- 4. [PATCH 2/4] xfs: replace i_flock with a sleeping bitlock (score: 1)
- Author: Christoph Hellwig <hch@xxxxxxxxxxxxx>
- Date: Wed, 19 Oct 2011 14:23:45 -0400
- We almost never block on i_flock, the exception is synchronous inode flushing. Instead of bloating the inode with a 16/24-byte completion that we abuse as a semaphore just implement it as a bitlock t
- /archives/xfs/2011-10/msg00398.html (17,098 bytes)
- 5. Re: [PATCH 2/4] xfs: replace i_flock with a sleeping bitlock (score: 1)
- Author: Alex Elder <aelder@xxxxxxx>
- Date: Wed, 26 Oct 2011 16:07:21 -0500
- vs faster wakeups Substitute "beeing" -> "being" throughout. There's also one thing I'd like you to check and likely fix, below. Otherwise looks good. Reviewed-by: Alex Elder <aelder@xxxxxxx> . . . i
- /archives/xfs/2011-10/msg00467.html (10,818 bytes)
This search system is powered by
Namazu