From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751652Ab3A1Svc (ORCPT ); Mon, 28 Jan 2013 13:51:32 -0500 Received: from mx1.redhat.com ([209.132.183.28]:13685 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751068Ab3A1Sva (ORCPT ); Mon, 28 Jan 2013 13:51:30 -0500 Date: Mon, 28 Jan 2013 19:50:39 +0100 From: Oleg Nesterov To: Kent Overstreet Cc: tj@kernel.org, srivatsa.bhat@linux.vnet.ibm.com, rusty@rustcorp.com.au, linux-kernel@vger.kernel.org Subject: Re: [PATCH] generic dynamic per cpu refcounting Message-ID: <20130128185039.GA19235@redhat.com> References: <20130124232024.GA584@google.com> <20130125180941.GA16896@redhat.com> <20130125182924.GA17514@redhat.com> <20130128181001.GZ26407@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130128181001.GZ26407@google.com> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 01/28, Kent Overstreet wrote: > > On Fri, Jan 25, 2013 at 07:29:24PM +0100, Oleg Nesterov wrote: > > On 01/25, Oleg Nesterov wrote: > > > > > > > +void __percpu_ref_get(struct percpu_ref *ref, bool alloc) > > > > +{ > > > > + unsigned long pcpu_count; > > > > + uint64_t v; > > > > + > > > > + pcpu_count = ACCESS_ONCE(ref->pcpu_count); > > > > + > > > > + if (REF_STATUS(pcpu_count) == PCPU_REF_PTR) { > > > > + /* for rcu - we're not using rcu_dereference() */ > > > > + smp_read_barrier_depends(); > > > > + __this_cpu_inc(*((unsigned __percpu *) pcpu_count)); > > > > > > The comment looks confusing a bit... smp_read_barrier_depends() is not > > > for rcu, we obviously need it to access (unsigned __percpu *) pcpu_count. > > > But yes, since we didn't use rcu_dereference() we have to add it by hand. > > > > Hmm. Otoh, arch/alpha uses asm-generic/percpu.h so in theory we need > > smp_read_barrier_depends() after __this_cpu_generic_to_op() calculates the > > "real" pointer, __this_cpu_ptr() ? > > > > Just curious... > > Don't think I follow, but I don't see how... that barriers just needs to > be between the ACCESS_ONCE and touching the memory pointed to, the fact > that there's a calculation in there to get the real pointer is > irrelevant... Yes, I was wrong. I forgot that pcp is already the pointer even in _generic_ case, we only add the offset. Thanks for correcting me. Oleg.