On Wed, May 29, 2013 at 02:29:56PM +0930, Rusty Russell wrote:
> Kent Overstreet writes:
> > I'm not sure I know of any good way of explaining it intuitively, but
> > here's this at least...
> >
> > * (More precisely: because moduler arithmatic is commutative the sum of
> > all the
> > * pcpu_c
Kent Overstreet writes:
> On Wed, May 15, 2013 at 10:37:20AM -0700, Tejun Heo wrote:
>> Can you please expand it on a bit and, more importantly, describe in
>> what limits, it's safe? This should be safe as long as the actual sum
>> of refcnts given out doesn't overflow the original type, right?
Yo,
On Tue, May 28, 2013 at 04:47:28PM -0700, Kent Overstreet wrote:
> > It'd be great if that is explained clearly in more intuitive way. The
> > only actual explanation above is "modular arithmatic is commutative"
> > which is a very compact way to put it and I really think it deserves
> > an e
On Wed, May 15, 2013 at 10:37:20AM -0700, Tejun Heo wrote:
> Ooh, I was referring to percpu_ref_dead() not percpu_ref_kill().
> percpu_ref_dead() reminds me of some of the work state query functions
> in workqueue which ended up being misused in ways that were subtly
> racy, so I'm curious why it's
Kent Overstreet writes:
> This implements a refcount with similar semantics to
> atomic_get()/atomic_dec_and_test() - but percpu.
Ah! This is why I was CC'd... Now I understand. Thanks :)
Delighted to see someone chasing this. I had an implementation of such
a thing last decade, but the slowm
Hey,
On Wed, May 15, 2013 at 02:07:42AM -0700, Kent Overstreet wrote:
> > > + __this_cpu_dec(*pcpu_count);
> > > + else
> > > + ret = atomic_dec_and_test(&ref->count);
> > > +
> > > + preempt_enable();
> > > +
> > > + return ret;
> >
> > With likely() added, I think the compiler s
Hey, Kent.
On Wed, May 15, 2013 at 01:58:56AM -0700, Kent Overstreet wrote:
> > Explanation on synchronization and use cases would be nice. People
> > tend to develop massive mis-uses for interfaces like this.
>
> hrm, kind of hard to know exactly what to say without seeing how people
> misuse i
On Tue, May 14, 2013 at 02:59:45PM -0700, Tejun Heo wrote:
> A couple more things.
>
> On Mon, May 13, 2013 at 06:18:41PM -0700, Kent Overstreet wrote:
> ...
> > +/**
> > + * percpu_ref_put - decrement a dynamic percpu refcount
> > + *
> > + * Returns true if the result is 0, otherwise false; only
On Tue, May 14, 2013 at 05:28:36PM +0200, Oleg Nesterov wrote:
> On 05/14, Tejun Heo wrote:
> >
> > > +int percpu_ref_tryget(struct percpu_ref *ref)
> > > +{
> > > + int ret = 1;
> > > +
> > > + preempt_disable();
> > > +
> > > + if (!percpu_ref_dead(ref))
> > > + percpu_ref_get(ref);
> > >
On Tue, May 14, 2013 at 07:59:32AM -0700, Tejun Heo wrote:
> Hello,
>
> On Mon, May 13, 2013 at 06:18:41PM -0700, Kent Overstreet wrote:
> > +/**
> > + * percpu_ref_dead - check if a dynamic percpu refcount is shutting down
> > + *
> > + * Returns true if percpu_ref_kill() has been called on @ref,
On Tue, May 14, 2013 at 03:51:01PM +0200, Oleg Nesterov wrote:
> On 05/13, Kent Overstreet wrote:
> >
> > +int percpu_ref_kill(struct percpu_ref *ref)
> > +{
> > + unsigned __percpu *pcpu_count;
> > + unsigned __percpu *old;
> > + unsigned count = 0;
> > + int cpu;
> > +
> > + pcpu_count
Hello, again, continuing the brain diarrehea,
On Tue, May 14, 2013 at 02:59:45PM -0700, Tejun Heo wrote:
> So, while I do like the simplicity of put() returning %true on the
> final put, I suspect it's more likely to slowing down fast paths due
> to its interface compared to having separate ->rele
A couple more things.
On Mon, May 13, 2013 at 06:18:41PM -0700, Kent Overstreet wrote:
...
> +/**
> + * percpu_ref_put - decrement a dynamic percpu refcount
> + *
> + * Returns true if the result is 0, otherwise false; only checks for the ref
> + * hitting 0 after percpu_ref_kill() has been called
On 05/14, Tejun Heo wrote:
>
> > +int percpu_ref_tryget(struct percpu_ref *ref)
> > +{
> > + int ret = 1;
> > +
> > + preempt_disable();
> > +
> > + if (!percpu_ref_dead(ref))
> > + percpu_ref_get(ref);
> > + else
> > + ret = 0;
> > +
> > + preempt_enable();
> > +
> >
Hello,
On Mon, May 13, 2013 at 06:18:41PM -0700, Kent Overstreet wrote:
> +/**
> + * percpu_ref_dead - check if a dynamic percpu refcount is shutting down
> + *
> + * Returns true if percpu_ref_kill() has been called on @ref, false
> otherwise.
Explanation on synchronization and use cases would
On 05/13, Kent Overstreet wrote:
>
> +int percpu_ref_kill(struct percpu_ref *ref)
> +{
> + unsigned __percpu *pcpu_count;
> + unsigned __percpu *old;
> + unsigned count = 0;
> + int cpu;
> +
> + pcpu_count = ACCESS_ONCE(ref->pcpu_count);
> +
> + do {
> + if (!pcp
This implements a refcount with similar semantics to
atomic_get()/atomic_dec_and_test() - but percpu.
It also implements two stage shutdown, as we need it to tear down the
percpu counts. Before dropping the initial refcount, you must call
percpu_ref_kill(); this puts the refcount in "shutting dow
17 matches
Mail list logo
