xfs
[Top] [All Lists]

Re: [PATCH] percpu_counter: return precise count from __percpu_counter_c

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: [PATCH] percpu_counter: return precise count from __percpu_counter_compare()
From: Tejun Heo <tj@xxxxxxxxxx>
Date: Wed, 7 Oct 2015 16:20:10 -0700
Cc: Waiman Long <waiman.long@xxxxxxx>, Christoph Lameter <cl@xxxxxxxxxxxxxxxxxxxx>, linux-kernel@xxxxxxxxxxxxxxx, xfs@xxxxxxxxxxx, Scott J Norton <scott.norton@xxxxxxx>, Douglas Hatch <doug.hatch@xxxxxxx>
Delivered-to: xfs@xxxxxxxxxxx
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=C3KMflGGreRD0nqMGPHy3RJKw/skYWhm93MZ0/yZPgw=; b=yFSlRJEDvlSTOerVkGkStxQI+qVuBDuQgz6PSHHqbZ55klwe22p4ftZATTu+LaI7V3 f79bmUjrf/1lLZOI3cmibk859o+x/eisGSj1kDPK7zeTHqHxjTj4cl+8kREKz2HqRjfL xwFssUPcH7N6YCkrWtE0vobn4a/rykux4TEmR1ZOrbM0z7Baw9Hw4bmFQ8u5yBcw6Ak4 Ji8y/yzIfVprVRhri6/Lu0J+HqByHExFViWQs40Ore33LVTCbNJG8KN/UZb0iBQMihL0 i4aCDSooGufIOCaAnVDF0rV9xnNUHP7WfFNwmy/MVli4W81xqPzIDa7ppI4ehkA7n0SX 6iQA==
In-reply-to: <20151007230441.GG32150@dastard>
References: <1443806997-30792-1-git-send-email-Waiman.Long@xxxxxxx> <20151002221649.GL27164@dastard> <5613017D.7080909@xxxxxxx> <20151006002538.GO27164@dastard> <561405E1.8020008@xxxxxxx> <20151006213023.GP27164@dastard> <561579EA.60507@xxxxxxx> <20151007230441.GG32150@dastard>
Sender: Tejun Heo <htejun@xxxxxxxxx>
User-agent: Mutt/1.5.23 (2014-03-12)
Hello, Dave.

On Thu, Oct 08, 2015 at 10:04:42AM +1100, Dave Chinner wrote:
...
> As it is, the update race you pointed out is easy to solve with
> __this_cpu_cmpxchg rather than _this_cpu_sub (similar to mod_state()
> in the MM percpu counter stats code, perhaps).

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.

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.

Thanks.

-- 
tejun

<Prev in Thread] Current Thread [Next in Thread>