Remove old code to free PVEs that should not be there that caused panics
(merge error moving between source trees on my part).
- pmap_destroy(): pmap_remove_all() doesn't work for EPT yet, so need to catch
up on deferred PTP frees manually in the EPT case.
- pp_embedded: Remove it. It's one more variable to go wrong and another
store to be made. Just check for non-zero PTP pointer & non-zero VA
instead.
unmanaged mapping, because there is no existing pmap_page to check in
the shortcut path (it traps).
pv_pte_next(): don't assert pp_embedded because it could have been removed
(during pmap_pp_remove()).
This will mean we automatically get two-finger scrolling on multitouch
pads.
This works, but the scrolling is janky. Why does it eventually move the
mouse cursor (only one finger detected, but two are still there), and why
does it jump up slightly?
- Fix a locking bug in pmap_pp_clear_attrs() and in pmap_pp_remove() do the
TLB shootdown while still holding the target pmap's lock.
Also:
- Finish PV list locking for x86 & update comments around same.
- Keep track of the min/max index of PTEs inserted into each PTP, and use
that to clip ranges of VAs passed to pmap_remove_ptes().
- Based on the above, implement a pmap_remove_all() for x86 that clears out
the pmap in a single pass. Makes exit() / fork() much cheaper.
functions: preempt_point() and preempt_needed().
- preempt(): if the LWP has exceeded its timeslice in kernel, strip it of
any priority boost gained earlier from blocking.
pmap is emptied. Pass UVM_FLAG_VAONLY when clearing out the map and avoid
needless extra work to tear down each mapping individually.
- uvm_map_lookup_entry(): remove the code to do a linear scan of map entries
for small maps, in preference to using the RB tree. It's questionable,
and I think the code is almost never triggered because the average number
of map entries has probably exceeded the hard-coded threshold for quite
some time.
- vm_map_entry: get it aligned on a cacheline boundary, and cluster fields
used during rbtree lookup at the beginning.
true, all mappings have been removed, the pmap is totally cleared out, and
UVM can then avoid doing the work to call pmap_remove() for each map entry.
If false, either nothing has been done, or some helpful arch-specific voodoo
has taken place.
