Implement pmap_advise() for arm64

[alc]

This is based on the amd64 implementation.

[markj]

arm64/arm64/pmap.c

4848 ↗

(On Diff #60122)

Would it be reasonable to handle MADV_WILLNEED by presetting ATTR_AF?

[alc]

arm64/arm64/pmap.c

4848 ↗

(On Diff #60122)

Like pmap_protect(), the machine-independent layer only expects this function to remove "things" from the PTE. In other words, it only calls pmap_advise() in these cases.

The machine-independent layer does, however, call pmap_enter_object() for MADV_WILLNEED. We could hypothetically pass a new argument to pmap_enter_object() that says preset the accessed bit (like pmap_enter()) or switch to calling pmap_enter() for MADV_WILLNEED.

4896–4900 ↗

(On Diff #60122)

By the way, I'm likely to post a patch changing this snippet on amd64, arm64, and i386. This snippet is removing the first 4KB page mapping within the superpage-sized address range. To be clear, the choice of page here is just a heuristic, and not the best heuristic. Removing the last 4KB page mapping produces more repromotions.

[alc]

Here is some data for a "make -j4 buildworld" on a 4-core, 8GB RAM machine.

Without this change:

...
  4250598 pages examined by the page daemon
...
   224966 pages reactivated by the page daemon
...
    40500 page faults requiring I/O
...

With this change:

...
  4207702 pages examined by the page daemon
...
    61162 pages reactivated by the page daemon
...
    30322 page faults requiring I/O
...

Without this change the page daemon's inactive queue scan is going to reactivate most MADV_FREE pages that it processes because they will have ATTR_AF set. We can see the effects of clearing ATTR_AF in the above data, especially, in the number of reactivations.