Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753694AbcCBIlg (ORCPT ); Wed, 2 Mar 2016 03:41:36 -0500 Received: from mail-wm0-f65.google.com ([74.125.82.65]:36159 "EHLO mail-wm0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751243AbcCBIle (ORCPT ); Wed, 2 Mar 2016 03:41:34 -0500 Date: Wed, 2 Mar 2016 09:41:29 +0100 From: Ingo Molnar 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 , Scott J Norton , Douglas Hatch , Linus Torvalds , Andrew Morton , Peter Zijlstra Subject: Re: [PATCH v5 5/5] lib/percpu-list: Add a config parameter for disabling per-cpu list Message-ID: <20160302084128.GA21779@gmail.com> References: <1456866003-32441-1-git-send-email-Waiman.Long@hpe.com> <1456866003-32441-6-git-send-email-Waiman.Long@hpe.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1456866003-32441-6-git-send-email-Waiman.Long@hpe.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1322 Lines: 34 * Waiman Long wrote: > As there is concern that the larger pcpu_list_node structure and the > per-cpu overhead may be a waste of resource on small system. This patch > adds a config parameter CONFIG_PERCPU_LIST to disable the per-cpu list > if the kernel builder chooses to do so. With per-cpu list disabled, > all the different groups of per-cpu lists will be degenerated into > global lists for all the CPUs. > > The current default is to enable per-cpu list. A kernel builder needs > to explicitly turn it off. > > Signed-off-by: Waiman Long > --- > fs/inode.c | 2 +- > include/linux/percpu-list.h | 93 ++++++++++++++++++++++++++++++++++++++++++- > lib/Kconfig | 14 ++++++ > lib/percpu-list.c | 24 +++++++++++- > 4 files changed, 130 insertions(+), 3 deletions(-) I think this kind of #ifdef complexity and the doubling of our Kconfig and testing space is counterproductive, and I think the per CPU locking is a win on as small as dual core CPUs, and on UP CPUs the per CPU list becomes a single global list automatically. I'm not against visible memory savings for overly clever scalability features, but this does not appear to be such a case, so: NAKed-by: Ingo Molnar Thanks, Ingo