Coalesce TLB shootdowns of global PTEs in pmap_advise().

[markj]

Summary

As of r311346, execve frequently calls pmap_advise() on multi-page
subranges of the kernel pmap. Right now, we invalidate consecutive entries
individually, resulting in more IPIs than necessary.

[alc]

The same change should apply to the i386 pmap.

[kib]

Why do we need to apply such great accuracy to the kernel pmap invalidation, while we do not care at all for the user pmaps ? What if you always set `anychanged``` if a pte was changed, and then at the end, near PMAP_UNLOCK(), do the pmap_invalidate_range() call if the var is true ?

[kib]

In D9094#188033, @kib wrote:

Why do we need to apply such great accuracy to the kernel pmap invalidation, while we do not care at all for the user pmaps ? What if you always set anychanged if a pte was changed, and then at the end, near PMAP_UNLOCK(), do the pmap_invalidate_range() call if the var is true ?

Replying to myself, we must not invalidate unmapped ranges.

[markj]

Optimize i386 pmap_advise() as well.

[kib]

sys/amd64/amd64/pmap.c

6118

In fact, returning to the merge of kernel_pmap and !kernel_pmap cases. After you added exact range invalidation, we still can remove anychanged and checks for PG_G. Always do range invalidation, regardless of the kernel/user pmap.

[alc]

sys/amd64/amd64/pmap.c

6118

I think that we should consider this issue separately. Right now, this revision follows the same approach as pmap_protect() and pmap_remove().

To be clear, I think that we should reconsider our utilization of range invalidations, or really lack thereof, on user-space pmaps. Things have changed, e.g., TLBs have gotten larger and we have made pmap_invalidate_all() work on the kernel pmap.

[kib]

sys/amd64/amd64/pmap.c

6118

I do not object.

Do you mean, by the second paragraph of your reply, that we should start doing range invalidations, or that instead, kernel range invalidations converted to _all() ?

[alc]

sys/amd64/amd64/pmap.c

6118

Some of both.