In generally I also don't think it's valuable to fuss around a lot to save an instruction, however, in this case I agree with mjg. If we can eliminate a memory reference and indirection that has value.

We should go ahead and fix the bug but I would like to revisit the design.

I am researching and typing a larger note regarding this but I wanted to make these comments first.

Resolve two swapin/swapout issues. This now passes stress2.

I have some comment cleanup to commit and one uma/smr fix to commit and then I feel comfortable going forward with this.

Use a common inline for lookup and provide a more direct path to making
other lookup functions lockless. Resolve startup ordering issues.

Correct swapout. I am still testing this but I believe it is correct.

In D23463#514971, @rlibby wrote:

Logic looks fine. I trust you've checked any performance effects.

In advance you count on entry, and then also on the slow path, whereas in poll you count either fast or slow. Did you mean to approach those differently?

I just considered that it might be cleaner to test for this once in keg_free_slab but this is fine.

You are creating work for everyone who has to review this and investigate as well as anyone who has to come after and figure out which of now three refcount apis are correct for their use and you have not yet justified the value of the change beyond pointing out that there is an extra branch. Arbitrarily small performance gains do not justify code complexity. Please demonstrate that this actually matters.

I thought I tested !SMP but maybe I just built it. This LGTM.

The overflow detecting was added to refcount for struct file. If struct file is not using it then the question becomes why detect overflow in the first place.

Fixes for invariants

Review feedback. Minor nits.

One more performance update; This has less than half of the cost of enter()/exit() vs epoch. ~200 cycles vs ~500 cycles on my simple benchmark.

Review feedback. Improved comments. Some minor fixes.

Address some review feedback. Still a few comments to clear up.

The question is really whether the next user is allowed to see the state of the file while needs inactive is set. In the cases described it is not harmful. I assert that the next user can see this incomplete state and what we're concerned with is properly tearing it down in a timely fashion. I would like to focus on solutions that only implement the required invariant and not something stronger than necessary.

I'm not sure why we are still pursuing this when the bugs relating to inactive processing were fixed when vget was changed to not drop the lock.

Use sequence instead of epoch to avoid confusion with the epoch algorithm.
epoch becomes wr_seq, the write sequence number.
epoch_min becomes rd_seq, the read sequence number.

I have some quantitative data to support my performance claims. In my test SMR is ~3x faster while consuming 5% as much memory vs epoch.

Delay uz_dtor() until the memory is safe to be reclaimed. This makes UMA SMR
compatible with existing use-after-free detection and allows zones to specify
typed callbacks to be notified when an item expired. The one limitation of
this system is that the udata argument to uma_zfree_arg() is not preserved.

I am happy with this change but I have not followed all code paths to be sure none were left out.

The goto is unfortunate but I see that without the loop becomes even weirder

thank you

Merge to latest uma changes.