Implement refcount_releasen_if_not_last().
Make the refcount_wait() function Giant safe and add the appropriate WITNESS asserts.
Differential D21617
Improve support for refcount waiting • hselasky on Sep 12 2019, 2:26 PM. Authored by Tags None Referenced Files
Details
Diff Detail
Event Timeline
Comment Actions Minor code refactor - lock sleep queue before dropping Giant. Makes code look better.
Comment Actions Can you describe the consumer visible effect you are trying to achieve? Is it just releasn?
Comment Actions So I had a closer look and think that the introduction of support for waiting was an abuse of this API and should either be moved to another one or get dedicated routines in this one. Most consumers (including very frequently used ones like struct file) don't care for it and avoidably pay the price for its existence.
That said, I suggest a different namespace (refcountw?) for this and reverting refcount.h to pre-r351188. I offer to do the dirty work if necessary.
Comment Actions +1 for this. We are now using a single KPI for multiple distinct purposes, and the code and KPI are confusing to me. I don't know about the name. I think this pattern is similar to a classical barrier, so I would be inclined to use that terminology instead.
Comment Actions I don't care for the name for the most part, but perhaps something not sounding so refcounty will make it easier to not accidentally use the wrong API. Alternatively, perhaps it's time we de-u_int all consumers and have something of this sort: struct refcount { u_int count; }; with open-coded access prohibited. The only problem here is that 'struct refcount' already exists in opensolaris code (along with refcount_t) so we will have to use something else. Comment Actions This seems reasonable to me.
ZoL renamed it to zfs_refcount_t, we could do the same. Linux has refcount_t AFAIR.
Comment Actions I will use the completion() API in the LinuxKPI for my purpose instead. Discussed with @mjg . |