On Mon, 3 Jun 2013 17:31:01 -0400
J. Bruce Fields bfie...@fieldses.org wrote:
On Fri, May 31, 2013 at 11:07:23PM -0400, Jeff Layton wrote:
Executive summary (tl;dr version): This patchset represents an overhaul
of the file locking code with an aim toward improving its scalability
and
Jeff Layton wrote:
Might be nice to look at some profiles to confirm all of that. I'd also
be curious how much variation there was in the results above, as they're
pretty close.
The above is just a random representative sample. The results are
pretty close when running this
On Fri, 2013-05-31 at 23:07 -0400, Jeff Layton wrote:
This is not the first attempt at doing this. The conversion to the
i_lock was originally attempted by Bruce Fields a few years ago. His
approach was NAK'ed since it involved ripping out the deadlock
detection. People also really seem to
On Tue, 4 Jun 2013 07:56:44 -0400
Jim Rees r...@umich.edu wrote:
Jeff Layton wrote:
Might be nice to look at some profiles to confirm all of that. I'd also
be curious how much variation there was in the results above, as they're
pretty close.
The above is just a random
There are four patches this time. The first fixes a problem where the
wrong descriptor type was being written into the log for journaled data
blocks. The second fixes a race relating to the deallocation of allocator
data. The third provides a fallback if kmalloc is unable to satisfy a
request to
From: Bob Peterson rpete...@redhat.com
This patch sets the log descriptor type according to whether the
journal commit is for (journaled) data or metadata. This was
recently broken when the functions to process data and metadata
log ops were combined.
Signed-off-by: Bob Peterson
From: Bob Peterson rpete...@redhat.com
This version has one more correction: the vmalloc calls are replaced
by __vmalloc calls to preserve the GFP_NOFS flag.
When GFS2's directory management code allocates buffers for a
directory hash table, if it can't get the memory it needs, it
currently
From: Bob Peterson rpete...@redhat.com
This patch calls get_write_access in a few functions. This
merely increases inode-i_writecount for the duration of the function.
That will ensure that any file closes won't delete the inode's
multi-block reservation while the function is running.
From: Bob Peterson rpete...@redhat.com
This patch makes GFS2 immediately reclaim/delete all iopen glocks
as soon as they're dequeued. This allows deleters to get an
EXclusive lock on iopen so files are deleted properly instead of
being set as unlinked.
Signed-off-by: Bob Peterson
Hi Jeff,
There's no reason we have to protect the blocked_hash and file_lock_list
with the same spinlock. With the tests I have, breaking it in two gives
a barely measurable performance benefit, but it seems reasonable to make
this locking as granular as possible.
as file_lock_{list,lock} is
Having RCU for modification mostly workloads never is a good idea, so
I don't think it makes sense to mention it here.
If you care about the overhead it's worth trying to use per-cpu lists,
though.
On Tue, Jun 04, 2013 at 07:46:40AM -0700, Christoph Hellwig wrote:
Having RCU for modification mostly workloads never is a good idea, so
I don't think it makes sense to mention it here.
If you care about the overhead it's worth trying to use per-cpu lists,
though.
Yes. The lock and unlock
On Tue, 4 Jun 2013 07:46:40 -0700
Christoph Hellwig h...@infradead.org wrote:
Having RCU for modification mostly workloads never is a good idea, so
I don't think it makes sense to mention it here.
If you care about the overhead it's worth trying to use per-cpu lists,
though.
Yeah, I
On Tue, 4 Jun 2013 10:53:22 -0400
J. Bruce Fields bfie...@fieldses.org wrote:
On Tue, Jun 04, 2013 at 07:46:40AM -0700, Christoph Hellwig wrote:
Having RCU for modification mostly workloads never is a good idea, so
I don't think it makes sense to mention it here.
If you care about the
Hi,
Please consider pulling the following fixes for GFS2,
Steve.
--
There are four patches this time. The first fixes a problem where the
wrong descriptor type was being written into the log for journaled data
blocks.
On Fri, May 31, 2013 at 11:07:27PM -0400, Jeff Layton wrote:
...save 3 bytes of stack space.
Signed-off-by: Jeff Layton jlay...@redhat.com
ACK.--b.
---
fs/locks.c |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/fs/locks.c b/fs/locks.c
index
On Fri, May 31, 2013 at 11:07:28PM -0400, Jeff Layton wrote:
Move the fl_link list handling routines into a separate set of helpers.
Also move the global list handling out of locks_insert_block, and into
the caller that ends up triggering it as that allows us to eliminate the
IS_POSIX check
On Fri, May 31, 2013 at 11:07:29PM -0400, Jeff Layton wrote:
Having a global lock that protects all of this code is a clear
scalability problem. Instead of doing that, move most of the code to be
protected by the i_lock instead.
The exceptions are the global lists that file_lock-fl_link sits
On Fri, May 31, 2013 at 11:07:30PM -0400, Jeff Layton wrote:
Currently, when there is a lot of lock contention the kernel spends an
inordinate amount of time taking blocked locks off of the global
blocked_list and then putting them right back on again. When all of this
code was protected by a
19 matches
Mail list logo
