convert EBR like barrier to epoch(9)

[mmacy]

Summary

the invl_gen_mtx is currently an expensive global serialization point on pmap_remove this converts it to use epoch

• passes pho's tests post epoch kpi change

[imp]

sys/amd64/amd64/pmap.c

475

don't you still need this assert?

500–505

I see you deleted the turnstile code, but not the turnstile comment.

507

And this one?

[mmacy]

sys/amd64/amd64/pmap.c

475

No. epoch(9) can recurse.

500–505

Thanks. Removing.

507

No. If you exit an epoch without having entered one it will trigger an assert.

[mmacy]

• fix comment
• update epoch_alloc to allow locks to be held across wait

[markj]

Portions of the network stack now execute within a preemptible epoch section. In particular, we're allocating from and freeing to UMA within these sections. This means that pmap_remove() might already be getting called within an epoch section for net_epoch. Because the td_epochq linkage is embedded in the thread struct rather than living on the stack (like we do for rmlocks), preemptible epochs don't compose, so I think this change as-is is fragile.

[mmacy]

In D15983#338793, @markj wrote:

Portions of the network stack now execute within a preemptible epoch section. In particular, we're allocating from and freeing to UMA within these sections. This means that pmap_remove() might already be getting called within an epoch section for net_epoch. Because the td_epochq linkage is embedded in the thread struct rather than living on the stack (like we do for rmlocks), preemptible epochs don't compose, so I think this change as-is is fragile.

More than fragile. https://people.freebsd.org/~pho/stress/log/mmacy025.txt

Will fix when I get back.

[mmacy]

• Update to new preemptible epoch interface

[mmacy]

@kib & @markj this now passes pho's tests after addressing Mark's concerns with nesting. What further needs to be done for approval?

[kib]

In D15983#342005, @mmacy wrote:

@kib & @markj this now passes pho's tests after addressing Mark's concerns with nesting. What further needs to be done for approval?

I want to read it (globally). I currently have some very time-consuming problems, so expect around a week turn-around time from me.

[markj]

In D15983#342005, @mmacy wrote:

@kib & @markj this now passes pho's tests after addressing Mark's concerns with nesting. What further needs to be done for approval?

How does this fix the problem in the report from pho that you linked earlier?

[mmacy]

In D15983#342009, @markj wrote:

In D15983#342005, @mmacy wrote:

@kib & @markj this now passes pho's tests after addressing Mark's concerns with nesting. What further needs to be done for approval?

How does this fix the problem in the report from pho that you linked earlier?

As of r335924 different epochs can now compose.

[markj]

In D15983#342013, @mmacy wrote:

In D15983#342009, @markj wrote:

In D15983#342005, @mmacy wrote:

@kib & @markj this now passes pho's tests after addressing Mark's concerns with nesting. What further needs to be done for approval?

How does this fix the problem in the report from pho that you linked earlier?

As of r335924 different epochs can now compose.

But AFAICS you still cannot call epoch_wait() in an epoch section, which is the problem I'm referring to.

[mmacy]

In D15983#342014, @markj wrote:

In D15983#342013, @mmacy wrote:

In D15983#342009, @markj wrote:

In D15983#342005, @mmacy wrote:

@kib & @markj this now passes pho's tests after addressing Mark's concerns with nesting. What further needs to be done for approval?

How does this fix the problem in the report from pho that you linked earlier?

As of r335924 different epochs can now compose.

But AFAICS you still cannot call epoch_wait() in an epoch section, which is the problem I'm referring to.

You can't call epoch_wait(x) while in epoch x. In this case we're calling epoch_wait_preempt on pmap_epoch while inside of net_epoch_preempt. Except for a couple of teardown paths in in if.c epoch_wait is never called on net_epoch_preempt.

[markj]

In D15983#342015, @mmacy wrote:

You can't call epoch_wait(x) while in epoch x. In this case we're calling epoch_wait_preempt on pmap_epoch while inside of net_epoch_preempt. Except for a couple of teardown paths in in if.c epoch_wait is never called on net_epoch_preempt.

epoch_wait_preempt() still asserts that td_epochnest == 0 though. And if you remove that constraint it becomes possible for concurrent epoch_wait()s to deadlock.

[mmacy]

In D15983#342016, @markj wrote:

In D15983#342015, @mmacy wrote:

You can't call epoch_wait(x) while in epoch x. In this case we're calling epoch_wait_preempt on pmap_epoch while inside of net_epoch_preempt. Except for a couple of teardown paths in in if.c epoch_wait is never called on net_epoch_preempt.

epoch_wait_preempt() still asserts that td_epochnest == 0 though.

Thanks, meant to remove that.

And if you remove that constraint it becomes possible for concurrent epoch_wait()s to deadlock.

Possible in the general case. Not here. And yes, I have a WIP patch to add WITNESS support.

[mmacy]

In D15983#342016, @markj wrote:

In D15983#342015, @mmacy wrote:

You can't call epoch_wait(x) while in epoch x. In this case we're calling epoch_wait_preempt on pmap_epoch while inside of net_epoch_preempt. Except for a couple of teardown paths in in if.c epoch_wait is never called on net_epoch_preempt.

epoch_wait_preempt() still asserts that td_epochnest == 0 though. And if you remove that constraint it becomes possible for concurrent epoch_wait()s to deadlock.

And to address this particular issue, the assert can just be changed to MPASS(!in_epoch(x)) now that in_epoch takes an argument.

[kib]

sys/amd64/amd64/pmap.c

439–440

Wny is this mutex left around ?

444

Blank line after '{', there and for all other functions without locals.

Please put spaces around binary op '|'.

500–505

This is not yet handled. I see that the comment requires much more significant rewrite, e.g. there is no longer a global di gen number, am I right ?

511

Why this code is needed ? And why the pmap_invl_gen.link is needed ? Also, pmap_invl_gen.gen should be bool or int instead of long, if it can only have the values 0 and 1.

3068–3069

Is this line too long ?

3111

Put this declaration before previous static one.

[mmacy]

• address comments by @kib

[mmacy]

• style(9)