public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Tejun Heo <tj@kernel.org>
To: Dave Chinner <david@fromorbit.com>
Cc: Scott J Norton <scott.norton@hpe.com>,
	Christoph Lameter <cl@linux-foundation.org>,
	Douglas Hatch <doug.hatch@hpe.com>,
	linux-kernel@vger.kernel.org, Waiman Long <waiman.long@hpe.com>,
	xfs@oss.sgi.com
Subject: Re: [PATCH] percpu_counter: return precise count from __percpu_counter_compare()
Date: Wed, 7 Oct 2015 16:20:10 -0700	[thread overview]
Message-ID: <20151007232010.GA21142@mtj.duckdns.org> (raw)
In-Reply-To: <20151007230441.GG32150@dastard>

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

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  reply	other threads:[~2015-10-07 23:20 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-02 17:29 [PATCH] percpu_counter: return precise count from __percpu_counter_compare() Waiman Long
2015-10-02 18:04 ` kbuild test robot
2015-10-05 23:03   ` Waiman Long
2015-10-02 18:05 ` kbuild test robot
2015-10-02 18:12 ` kbuild test robot
2015-10-02 18:15 ` kbuild test robot
2015-10-02 22:16 ` Dave Chinner
2015-10-05 23:02   ` Waiman Long
2015-10-06  0:25     ` Dave Chinner
2015-10-06 17:33       ` Waiman Long
2015-10-06 21:30         ` Dave Chinner
2015-10-07 20:00           ` Waiman Long
2015-10-07 23:04             ` Dave Chinner
2015-10-07 23:20               ` Tejun Heo [this message]
2015-10-08  1:02                 ` Dave Chinner
2015-10-08  1:09                   ` Tejun Heo
2015-10-08 16:06                   ` Waiman Long
2015-10-08 16:01               ` Waiman Long

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20151007232010.GA21142@mtj.duckdns.org \
    --to=tj@kernel.org \
    --cc=cl@linux-foundation.org \
    --cc=david@fromorbit.com \
    --cc=doug.hatch@hpe.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=scott.norton@hpe.com \
    --cc=waiman.long@hpe.com \
    --cc=xfs@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox