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, false > > otherwise. > > 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 it first. How about this? * Returns true the first time called on @ref and false percpu_ref_kill() has * already been called on @ref. * * The return value can optionally be used to synchronize shutdown, when * multiple threads could try to destroy an object at the same time - if * percpu_ref_kill() returns true, then this thread should release the initial * refcount - see percpu_ref_put_initial_ref(). > > + */ > > +static inline int percpu_ref_dead(struct percpu_ref *ref) > > +{ > > + return ref->pcpu_count == NULL; > > +} > ... > > +/* > > + * The trick to implementing percpu refcounts is shutdown. We can't detect > > the > > + * ref hitting 0 on every put - this would require global synchronization > > and > > + * defeat the whole purpose of using percpu refs. > > + * > > + * What we do is require the user to keep track of the initial refcount; > > we know > > + * the ref can't hit 0 before the user drops the initial ref, so as long > > as we > > + * convert to non percpu mode before the initial ref is dropped everything > > + * works. > > Can you please also explain why per-cpu wrapping is safe somewhere? I feel like we had this exact discussion before and I came up with some sort of explanation but I can't remember what I came up with. Here's what I've got now... * Initially, a percpu refcount is just a set of percpu counters. Initially, we * don't try to detect the ref hitting 0 - which means that get/put can just * increment or decrement the local counter. Note that the counter on a * particular cpu can (and will) wrap - this is fine, when we go to shutdown the * percpu counters will all sum to the correct value (because moduler arithmatic * is commutative). > > + * Converting to non percpu mode is done with some RCUish stuff in > > + * percpu_ref_kill. Additionally, we need a bias value so that the atomic_t > > + * can't hit 0 before we've added up all the percpu refs. > > + */ > > + > > +#define PCPU_COUNT_BIAS (1ULL << 31) > > Are we sure this is enough? 1<<31 is a fairly large number but it's > just easy enough to breach from time to time and it's gonna be hellish > to reproduce / debug when it actually overflows. Maybe we want > atomic64_t w/ 1LLU << 63 bias? Or is there something else which > guarantees that the bias can't over/underflow? Well, it has the effect of halving the usable range of the refcount, which I think is probably ok - the thing is, the range of an atomic_t doesn't really correspond to anything useful on 64 bit machines so if you're concerned about overflow you probably need to be using an atomic_long_t. That is, if 32 bits is big enough 31 bits probably is too. If we need a 64-ish bit refcount in the future (I don't think it matters for AIO) I'll probably just make a percpu_ref64 - that uses u64s for the percpu counters too. Or... maybe just make this version use unsigned longs/atomic_long_ts instead of 32 bit integers. I dunno, I'll think about it a bit. I don't think it's urgent, it's easy to change the types if and when a new user comes along for which it matters. IIRC the module code uses 32 bit ints for its refcounts and that's the next thing I was trying to convert at one point. > > +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(); > > + > > + return ret; > > +} > > Why isn't the above one inline? hmm, I suppose that's like two or three more instructions than normal get, I'll make it inline. > Why no /** comment on public functions? It'd be great if you can > explicitly warn about the racy nature of the function - especially, > the function may return overflowed or zero refcnt. BTW, why is this > function necessary? What's the use case? Module code - I should probably leave count() and tryget() out until the module conversion is done. tryget() in particular is just trying to match the existing module_tryget() and it could certainly be implemented differently. > > +/** > > + * percpu_ref_kill - prepare a dynamic percpu refcount for teardown > > + * > > + * Must be called before dropping the initial ref, so that percpu_ref_put() > > + * knows to check for the refcount hitting 0. If the refcount was in percpu > > + * mode, converts it back to single atomic counter mode. > > + * > > + * The caller must issue a synchronize_rcu()/call_rcu() before calling > > + * percpu_ref_put() to drop the initial ref. > > + * > > + * Returns true the first time called on @ref and false if @ref is already > > + * shutting down, so it may be used by the caller for synchronizing other > > parts > > + * of a two stage shutdown. > > + */ > > I'm not sure I like this interface. Why does it allow being called > multiple times? Why is that necessary? Wouldn't just making it > return void and trigger WARN_ON() if it detects that it's being called > multiple times better? Also, why not bool if the return value is > true/false? bool just feels a bit strange in the kernel because it's not used that much, but yeah bool is correct here. Whether it should return bool, or void like you said and WARN_ON() is definitely debatable. I don't have a strong opinion on it - I did it this way because it's commonly needed functionality and a convenient place implement it, but if we see people misusing it in the future I would definitely rip it out. > > +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 (!pcpu_count) > > + return 0; > > + > > + old = pcpu_count; > > + pcpu_count = cmpxchg(&ref->pcpu_count, old, NULL); > > + } while (pcpu_count != old); > > + > > + synchronize_sched(); > > And this makes the whole function blocking. Why not use call_rcu() so > that the ref can be called w/o sleepable context too? Because you need to know when percpu_ref_kill() finishes so you know when it's safe to drop the initial ref - if percpu_ref_kill() used call_rcu() itself, it would then have to be doing the put itself... which means we'd have to stick a pointer to the release function in struct percpu_ref. But this is definitely going to be an issue... I was thinking about using the low bit of the pointer to indicate that the ref is dead so that the caller could use call_rcu() and then call another function to gather up the percpu counters, but that's pretty ugly. I may just stick the release function in struct percpu_ref and have percpu_ref_kill() use call_rcu() after all... > > +/** > > + * percpu_ref_put_initial_ref - safely drop the initial ref > > + * > > + * A percpu refcount needs a shutdown sequence before dropping the initial > > ref, > > + * to put it back into single atomic_t mode with the appropriate barriers > > so > > + * that percpu_ref_put() can safely check for it hitting 0 - this does so. > > + * > > + * Returns true if @ref hit 0. > > + */ > > +int percpu_ref_put_initial_ref(struct percpu_ref *ref) > > +{ > > + if (percpu_ref_kill(ref)) { > > + return percpu_ref_put(ref); > > + } else { > > + WARN_ON(1); > > + return 0; > > + } > > +} > > Can we just roll the above into percpu_ref_kill()? It's much harder > to misuse if kill puts the base ref. Possibly... if we did that we'd also be getting rid of percpu_ref_kill's synchronization functionality. I want to wait until after the call_rcu() thing is decided before futzing with this part, there's some dependancies. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/