From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751746AbdJEJOP (ORCPT ); Thu, 5 Oct 2017 05:14:15 -0400 Received: from mx2.suse.de ([195.135.220.15]:54127 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751536AbdJEJON (ORCPT ); Thu, 5 Oct 2017 05:14:13 -0400 Date: Thu, 5 Oct 2017 11:14:06 +0200 From: Jan Kara To: Waiman Long Cc: Alexander Viro , Jan Kara , Jeff Layton , "J. Bruce Fields" , Tejun Heo , Christoph Lameter , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Ingo Molnar , Peter Zijlstra , Andi Kleen , Dave Chinner , Boqun Feng , Davidlohr Bueso Subject: Re: [PATCH v6 5/6] lib/dlock-list: Enable faster lookup with hashing Message-ID: <20171005091406.GD28132@quack2.suse.cz> References: <1507152007-28753-1-git-send-email-longman@redhat.com> <1507152007-28753-6-git-send-email-longman@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1507152007-28753-6-git-send-email-longman@redhat.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed 04-10-17 17:20:06, Waiman Long wrote: > Insertion and deletion is relatively cheap and mostly contention > free for dlock-list. Lookup, on the other hand, can be rather costly > because all the lists in a dlock-list will have to be iterated. > > Currently dlock-list insertion is based on the cpu that the task is > running on. So a given object can be inserted into any one of the > lists depending on what the current cpu is. > > This patch provides an alternative way of list selection. The caller > can provide a object context which will be hashed to one of the list > in a dlock-list. The object can then be added into that particular > list. Lookup can be done by iterating elements in the provided list > only instead of all the lists in a dlock-list. > > The new APIs are: > > struct dlock_list_head *dlock_list_hash(struct dlock_list_heads *, void *); > void dlock_list_add(struct dlock_list_node *, struct dlock_list_head *); > > Signed-off-by: Waiman Long 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? Honza -- Jan Kara SUSE Labs, CR