[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160302084128.GA21779@gmail.com>
Date: Wed, 2 Mar 2016 09:41:29 +0100
From: Ingo Molnar <mingo@...nel.org>
To: Waiman Long <Waiman.Long@....com>
Cc: 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>,
Scott J Norton <scott.norton@...com>,
Douglas Hatch <doug.hatch@...com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>
Subject: Re: [PATCH v5 5/5] lib/percpu-list: Add a config parameter for
disabling per-cpu list
* Waiman Long <Waiman.Long@....com> 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 <Waiman.Long@....com>
> ---
> 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 <mingo@...nel.org>
Thanks,
Ingo
Powered by blists - more mailing lists