Coalesce TLB shootdowns of global PTEs in pmap_advise().
ClosedPublic
Actions

Authored by markj on Jan 8 2017, 8:41 PM.

Details

Reviewers

kib
alc

Commits

rS311902: Coalesce TLB shootdowns of global PTEs in pmap_advise() on x86.

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.

Diff Detail

Repository

rS FreeBSD src repository - subversion

Lint

Lint Not Applicable

Unit

Tests Not Applicable

Event Timeline

markj updated this revision to Diff 23748.Jan 8 2017, 8:41 PM

markj retitled this revision from to Coalesce TLB shootdowns of global PTEs in pmap_advise()..

markj edited the test plan for this revision. (Show Details)

markj updated this object.

markj updated this object.Jan 8 2017, 8:43 PM

markj added reviewers: alc, kib.

The same change should apply to the i386 pmap.

This revision is now accepted and ready to land.Jan 8 2017, 10:43 PM

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 ?

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.

Optimize i386 pmap_advise() as well.

This revision now requires review to proceed.Jan 10 2017, 4:29 AM

kib added inline comments.Jan 10 2017, 9:39 AM

sys/amd64/amd64/pmap.c
6118 ↗	(On Diff #23815)	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 added inline comments.Jan 10 2017, 3:53 PM

sys/amd64/amd64/pmap.c
6118 ↗	(On Diff #23815)	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 accepted this revision.Jan 10 2017, 4:15 PM

kib edited edge metadata.

kib added inline comments.

sys/amd64/amd64/pmap.c
6118 ↗	(On Diff #23815)	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() ?