[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130604105656.18663efa@corrin.poochiereds.net>
Date: Tue, 4 Jun 2013 10:56:56 -0400
From: Jeff Layton <jlayton@...hat.com>
To: Christoph Hellwig <hch@...radead.org>
Cc: "Stefan (metze) Metzmacher" <metze@...ba.org>,
viro@...iv.linux.org.uk, matthew@....cx, bfields@...ldses.org,
linux-cifs@...r.kernel.org, linux-nfs@...r.kernel.org,
cluster-devel@...hat.com, sage@...tank.com,
samba-technical@...ts.samba.org, Trond.Myklebust@...app.com,
linux-kernel@...r.kernel.org, linux-afs@...ts.infradead.org,
dhowells@...hat.com, smfrench@...il.com,
linux-fsdevel@...r.kernel.org, ceph-devel@...r.kernel.org,
akpm@...ux-foundation.org, swhiteho@...hat.com
Subject: Re: [PATCH v1 11/11] locks: give the blocked_hash its own spinlock
On Tue, 4 Jun 2013 07:46:40 -0700
Christoph Hellwig <hch@...radead.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 looked at those too in an earlier set and it did help some.
Moving to a hashtable for the blocked_list really seemed to help the
most there, but percpu lists with lglocks or something might help a lot
on the file_lock_list.
--
Jeff Layton <jlayton@...hat.com>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists