[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130128214823.GH26407@google.com>
Date: Mon, 28 Jan 2013 13:48:23 -0800
From: Kent Overstreet <koverstreet@...gle.com>
To: Tejun Heo <tj@...nel.org>
Cc: Oleg Nesterov <oleg@...hat.com>, srivatsa.bhat@...ux.vnet.ibm.com,
rusty@...tcorp.com.au, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] generic dynamic per cpu refcounting
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists