From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753474AbdKANQy (ORCPT ); Wed, 1 Nov 2017 09:16:54 -0400 Received: from mx1.redhat.com ([209.132.183.28]:57318 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751324AbdKANQw (ORCPT ); Wed, 1 Nov 2017 09:16:52 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com EBFD4C0587DC Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=longman@redhat.com Subject: Re: [PATCH v8 5/6] lib/dlock-list: Enable faster lookup with hashing To: Jan Kara 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 References: <1509475860-16139-1-git-send-email-longman@redhat.com> <1509475860-16139-6-git-send-email-longman@redhat.com> <20171101084021.GL26128@quack2.suse.cz> From: Waiman Long Organization: Red Hat Message-ID: <61a2ff76-8f5c-30e5-5645-76ca07ba77f0@redhat.com> Date: Wed, 1 Nov 2017 09:16:49 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: <20171101084021.GL26128@quack2.suse.cz> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Wed, 01 Nov 2017 13:16:52 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/01/2017 04:40 AM, Jan Kara wrote: > On Tue 31-10-17 14:50:59, 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 > Hum, do we have any users for this API? And wouldn't they also need to > control how many lists are allocated then? This patch is supposed to be used by the epoll patch from Davidlohr. As he has retracted the patch, I can drop this patch also. The number of lists scale with the number of CPU cores in the system whether it is used one way or the others. Cheers, Longman