[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20171005110601.GA5131@linux-80c1.suse>
Date: Thu, 5 Oct 2017 04:06:01 -0700
From: Davidlohr Bueso <dave@...olabs.net>
To: Jan Kara <jack@...e.cz>
Cc: Waiman Long <longman@...hat.com>,
Alexander Viro <viro@...iv.linux.org.uk>,
Jan Kara <jack@...e.com>,
Jeff Layton <jlayton@...chiereds.net>,
"J. Bruce Fields" <bfields@...ldses.org>,
Tejun Heo <tj@...nel.org>,
Christoph Lameter <cl@...ux-foundation.org>,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
Ingo Molnar <mingo@...hat.com>,
Peter Zijlstra <peterz@...radead.org>,
Andi Kleen <andi@...stfloor.org>,
Dave Chinner <dchinner@...hat.com>,
Boqun Feng <boqun.feng@...il.com>
Subject: Re: [PATCH v6 5/6] lib/dlock-list: Enable faster lookup with hashing
On Thu, 05 Oct 2017, Jan Kara wrote:
>OK, this makes sense but do you have any particular user in mind? In
>particular I'm not sure how big advantage this API brings over an existing
>one in include/linux/list_bl.h. Sure it's a tradeoff between bitlock /
>spinlock but is there a user where it matters?
This was tailored with epoll nested callbacks in mind, we've been discussing
offline. I have not looked at list_bl.h nonetheless.
Thanks,
Davidlohr
Powered by blists - more mailing lists