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:48:23 -0800 [thread overview]
Message-ID: <20130128214823.GH26407@google.com> (raw)
In-Reply-To: <20130128213622.GM22465@mtj.dyndns.org>
On Mon, Jan 28, 2013 at 01:36:22PM -0800, Tejun Heo wrote:
> On Mon, Jan 28, 2013 at 01:28:14PM -0800, Tejun Heo wrote:
> > 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.
>
> Note that I'm saying that there's no need to distinguish between dying
> and dead.
Yeah I got that, I _think_ that makes me like the idea.
> The only thing percpu part should care about it whether
> percpu is on or off. We need a full grace period to turn off percpu
> operations of any type but that should be the only case where full
> grace period is necessary. The rest should be synchronizable via the
> usual global synchronization. We probably can just test percpu
> variable against NULL and forget about the encoded state numbers.
Can't quite do that because initially, we use that variable for a
timestamp and when we're shutting down we don't want percpu_ref_get()
allocating percpu counters again.
You'll probably use that as an argument against dynamic allocation :P
next prev parent reply other threads:[~2013-01-28 21:48 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 [this message]
2013-01-28 21:45 ` Kent Overstreet
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=20130128214823.GH26407@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.