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
---
Documenta
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}
On Tue, 04 Jun 2013 16:19:53 +0200
"Stefan (metze) Metzmacher" 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 seems re
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 unl
On Tue, 4 Jun 2013 07:46:40 -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.
>
Yeah, I looked at those t
On Tue, 4 Jun 2013 10:53:22 -0400
"J. Bruce Fields" 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 overhead it
