From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751943AbbJHBJw (ORCPT ); Wed, 7 Oct 2015 21:09:52 -0400 Received: from mail-pa0-f47.google.com ([209.85.220.47]:34259 "EHLO mail-pa0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751318AbbJHBJv (ORCPT ); Wed, 7 Oct 2015 21:09:51 -0400 Date: Wed, 7 Oct 2015 18:09:47 -0700 From: Tejun Heo To: Dave Chinner Cc: Waiman Long , Christoph Lameter , linux-kernel@vger.kernel.org, xfs@oss.sgi.com, Scott J Norton , Douglas Hatch Subject: Re: [PATCH] percpu_counter: return precise count from __percpu_counter_compare() Message-ID: <20151008010947.GB21142@mtj.duckdns.org> References: <1443806997-30792-1-git-send-email-Waiman.Long@hpe.com> <20151002221649.GL27164@dastard> <5613017D.7080909@hpe.com> <20151006002538.GO27164@dastard> <561405E1.8020008@hpe.com> <20151006213023.GP27164@dastard> <561579EA.60507@hpe.com> <20151007230441.GG32150@dastard> <20151007232010.GA21142@mtj.duckdns.org> <20151008010218.GT27164@dastard> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151008010218.GT27164@dastard> 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, Dave. On Thu, Oct 08, 2015 at 12:02:18PM +1100, Dave Chinner wrote: > > percpu cmpxchg is no different from sub or any other operations > > regarding cross-CPU synchronization. They're safe iff the operations > > are on the local CPU. They have to be made atomics if they need to be > > manipulated from remote CPUs. > > Again, another trivially solvable problem, but still irrelevant > because we don't have the data that tells us whether changing the > counter behaviour solves the problem.... Dude, it isn't trivially solvable. You either can't do it or have to pay the overhead during local access to get around it. > > That said, while we can't manipulate the percpu counters directly, we > > can add a separate global counter to cache sum result from the > > previous run which gets automatically invalidated when any percpu > > counter overflows. > > > > That should give better and in case of > > back-to-back invocations pretty good precision compared to just > > returning the global overflow counter. Interface-wise, that'd be a > > lot easier to deal with although I have no idea whether it'd fit this > > particular use case or whether this use case even exists. > > No, it doesn't help - it's effectively what Waiman's original patch > did by returning the count from the initial comparison and using > that for ENOSPC detection instead of doing a second comparison... Just chipping in purely from percpu side. If what Waiman suggested is something useable, caching the result inside percpu_counter would be a better interface. If not, no idea. Thanks. -- tejun