From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752311AbbFYTRP (ORCPT ); Thu, 25 Jun 2015 15:17:15 -0400 Received: from mail-yk0-f170.google.com ([209.85.160.170]:33523 "EHLO mail-yk0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752334AbbFYTRF (ORCPT ); Thu, 25 Jun 2015 15:17:05 -0400 Date: Thu, 25 Jun 2015 15:17:01 -0400 From: Tejun Heo To: Peter Zijlstra Cc: Nicholas Mc Guire , oleg@redhat.com, paulmck@linux.vnet.ibm.com, 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: <20150625191701.GA5013@mtj.duckdns.org> References: <20150622121623.291363374@infradead.org> <20150622122256.064223889@infradead.org> <20150623072811.GB20073@opentech.at> <20150625190800.GW19282@twins.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150625190800.GW19282@twins.programming.kicks-ass.net> 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 Hello, On Thu, Jun 25, 2015 at 09:08:00PM +0200, Peter Zijlstra wrote: > > 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. A patch doing that is already queued for this merge window. IIRC, it's included as part of cgroup writeback updates. > > > +#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 ? percpu-defs.h would be the better place for it. > 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.. Hmmm... the only worry I have about this is people using it on u64 on 32bit machines. CPU local ops can do split updates on lower and upper halves and the remotely-read value will be surprising. We have the same issues w/ regular per_cpu accesses to but the summing function / macro is better at giving the false sense of security. Prolly limiting it upto ulong size is a good idea? Thanks. -- tejun