All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kent Overstreet <koverstreet@google.com>
To: Tejun Heo <tj@kernel.org>
Cc: Oleg Nesterov <oleg@redhat.com>,
	srivatsa.bhat@linux.vnet.ibm.com, rusty@rustcorp.com.au,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] generic dynamic per cpu refcounting
Date: Mon, 28 Jan 2013 13:45:06 -0800	[thread overview]
Message-ID: <20130128214506.GG26407@google.com> (raw)
In-Reply-To: <20130128212814.GL22465@mtj.dyndns.org>

On Mon, Jan 28, 2013 at 01:28:14PM -0800, Tejun Heo wrote:
> On Mon, Jan 28, 2013 at 01:24:07PM -0800, Kent Overstreet wrote:
> > > 	set dying;
> > > 	synchronize_sched();
> > > 	collect percpu refs into global atomic_t;
> > > 	put the base ref;
> > 
> > After you set state := dying, percpu_ref_put() decrements the atomic_t,
> > but it can't check if it's 0 yet because the thread that's collecting
> > the percpu refs might not be done yet.
> > 
> > So percpu_ref_put can't check for ref == 0 until after state == dead.
> > But the put in your example might have made ref 0. When did you set
> > state to dead?
> 
> But at that point, the operation is already global, so there gotta be
> a lighter way to synchronize stuff than going through full grace
> period.  ie. You can add a bias value before marking dead so that the
> counter never reaches zero before all percpu counters are collected
> and then unbias it right before putting the base ref, that way the
> only way you can hit zero ref is all refs are actually zero.

Ahh. Bias value sounds... hacky (i.e. harder to convince myself it's
correct) but I see what you're getting at.

Something to consider is wrapping; after we set state to dying but
before we've collected the percpu counters, the atomic counter may be
negative.

But since the atomic counter is 64 bits, we can use 1 << 32 for the bias
value (and just include that when we first initialize it). Which makes
me feel like it's less of a hack too.

I'll have to think about it some more but seems like it ought t owork...

  parent reply	other threads:[~2013-01-28 21:45 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20130124232024.GA584@google.com>
2013-01-25 18:09 ` [PATCH] generic dynamic per cpu refcounting Oleg Nesterov
2013-01-25 18:29   ` Oleg Nesterov
2013-01-28 18:10     ` Kent Overstreet
2013-01-28 18:50       ` Oleg Nesterov
2013-01-25 19:11   ` Oleg Nesterov
2013-01-28 18:15     ` Kent Overstreet
2013-01-28 18:27       ` Tejun Heo
2013-01-28 18:49         ` Kent Overstreet
2013-01-28 18:55           ` Tejun Heo
2013-01-28 20:22             ` Kent Overstreet
2013-01-28 20:27               ` Tejun Heo
2013-01-28 20:55                 ` Kent Overstreet
2013-01-28 21:18                   ` Tejun Heo
2013-01-28 21:24                     ` Kent Overstreet
2013-01-28 21:28                       ` Tejun Heo
2013-01-28 21:36                         ` Tejun Heo
2013-01-28 21:48                           ` Kent Overstreet
2013-01-28 21:45                         ` Kent Overstreet [this message]
2013-01-28 21:50                           ` Tejun Heo
2013-01-29 16:39                             ` Kent Overstreet
2013-01-29 19:29                               ` Tejun Heo
2013-01-29 19:51                                 ` Kent Overstreet
2013-01-29 20:02                                   ` Tejun Heo
2013-01-29 21:45                                     ` Kent Overstreet
2013-01-29 22:06                                       ` Tejun Heo
2013-01-29 18:04                             ` [PATCH] module: Convert to generic percpu refcounts Kent Overstreet
2013-01-28 18:07   ` [PATCH] generic dynamic per cpu refcounting Kent Overstreet

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=20130128214506.GG26407@google.com \
    --to=koverstreet@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oleg@redhat.com \
    --cc=rusty@rustcorp.com.au \
    --cc=srivatsa.bhat@linux.vnet.ibm.com \
    --cc=tj@kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.