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

Lint

Lint Passed

Unit

No Test Coverage

Build Status

Buildable 6678
Build 6895: arc lint + arc unit

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	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	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	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() ?