On Tue, Sep 11, 2018 at 09:30:32AM -0700, Tejun Heo wrote:

On Wed, Sep 12, 2018 at 12:05:33AM +0800, Ming Lei wrote:

quoted

On Tue, Sep 11, 2018 at 08:49:59AM -0700, Tejun Heo wrote:

quoted

On Tue, Sep 11, 2018 at 11:45:41PM +0800, Ming Lei wrote:

quoted

quoted

So, this part seems wrong.  The function is called percpu_ref_reinit()
- the refcnt is expected to be in its initial state with just the base
ref once this function returns.  If you're removing the restriction on

But the comment says that 'Re-initialize @ref so that it's in the same
state as when it finished', and this invariant isn't changed with this
patch.

The comment goes "when perpcu_ref_init() finished".  The function is
called re _init_.  It should put the ref in the initial state, right?

OK, I am fine to keep the behaviour for this API, will introduce a new helper
for NVMe.

Why aren't switch_to_atomic/percpu enough?

The blk-mq's use case is this _reinit is done on one refcount which was
killed via percpu_ref_kill(), so the DEAD flag has to be cleared.

quoted

However, it is doable to switch to percpu mode from atomic mode when it
doesn't drop to zero, looks like sort of perpcu_ref_reinit(inherit_old_refcount).

Isn't that way more contorted than just switching operating modes?

As explained above.

Thanks,
Ming