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
On Tue, 04 Jun 2013 16:19:53 +0200
Stefan (metze) Metzmacher me...@samba.org wrote:
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
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
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.
--
To unsubscribe from this list: send the line unsubscribe ceph-devel in
the body of a message to
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.
Signed-off-by: Jeff Layton
