From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751984AbbFYTIT (ORCPT ); Thu, 25 Jun 2015 15:08:19 -0400 Received: from bombadil.infradead.org ([198.137.202.9]:45189 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751252AbbFYTIN (ORCPT ); Thu, 25 Jun 2015 15:08:13 -0400 Date: Thu, 25 Jun 2015 21:08:00 +0200 From: Peter Zijlstra To: Nicholas Mc Guire Cc: oleg@redhat.com, paulmck@linux.vnet.ibm.com, tj@kernel.org, mingo@redhat.com, linux-kernel@vger.kernel.org, dave@stgolabs.net, riel@redhat.com, viro@ZenIV.linux.org.uk, torvalds@linux-foundation.org Subject: Re: [RFC][PATCH 05/13] percpu-rwsem: Optimize readers and reduce global impact Message-ID: <20150625190800.GW19282@twins.programming.kicks-ass.net> References: <20150622121623.291363374@infradead.org> <20150622122256.064223889@infradead.org> <20150623072811.GB20073@opentech.at> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150623072811.GB20073@opentech.at> User-Agent: Mutt/1.5.21 (2012-12-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jun 23, 2015 at 09:28:11AM +0200, Nicholas Mc Guire wrote: > > A bit off-topic probably > but maybe this should not be in kernel/locking/percpu-rwsem.c but in a > generic percpu location as this construct is present in the core a few times > atleast in: > kernel/irq/irqdesc.c:kstat_irqs > kernel/fork.c:nr_processes That has an odd unsigned long vs int fail, but yes. > mm/memcontrol.c:mem_cgroup_read_events > mm/memcontrol.c:mem_cgroup_read_stat Those seem to be hotplug challenged. I'm thinking dropping that nocpu_base.count[] crap and just iterating all possible CPUs would've been much easier. > > +#define per_cpu_sum(var) \ > > +({ \ > > + typeof(var) __sum = 0; \ > > + int cpu; \ > > + for_each_possible_cpu(cpu) \ > > + __sum += per_cpu(var, cpu); \ > > + __sum; \ > > +}) > > + > > so maybe put it into include/linux/percpu.h ? Yes I can do that. We can try and use it more after that, there seems to be loads of places that could use this fs/namespace.c fs/inode.c etc..