In D39845#926656, @kib wrote:

Yes, I believe this is only one change from the three present in my branch. I do not have objections.

After mulling this over for a while, I'm going to suggest a different approach to address the clustering problem. Essentially, I'm pushing down the point at which we convert a hint of zero to a minimum address into vm_map_find_min().

diff --git a/sys/vm/vm_map.c b/sys/vm/vm_map.c
index f5863a9b9939..4fd0aff24b75 100644
--- a/sys/vm/vm_map.c
+++ b/sys/vm/vm_map.c
@@ -1981,14 +1981,14 @@ SYSCTL_INT(_vm, OID_AUTO, cluster_anon, CTLFLAG_RW,
     "Cluster anonymous mappings: 0 = no, 1 = yes if no hint, 2 = always");

The following aspect of the previous version of the patch has an unintended consequence:

else if (!clustering_anon_loc_const() &&
    !vm_map_lookup_entry(map, curr_min_addr, &entry))
        curr_min_addr = entry->end;

With cluster_anon set to its default value of 1, the first time that a clustered allocation is attempted (line 7186) the above code effectively lowers anon_loc to the end of the previous map entry, far from the address originally generated for anon_loc.

7195 map: 0xfffffe018592ec30, hint: 0x33c594562000, len: 0x400000, (find: 0, align: 0x200000), addr: 0x33cbdf200000
7194 map: 0xfffffe018592ec30, anon_loc: 0x33cbdf200000, addr: 0x33cbdf200000
7193 map: 0xfffffe018592ec30, hint: 0x33c594562000, len: 0x200000, (find: 0, align: 0x1000), addr: 0x33cbdf000000
7192 map: 0xfffffe018592ec30, anon_loc: 0x33cbdf000000, addr: 0x33cbdf000000
7191 map: 0xfffffe018592ec30, hint: 0x33c594562000, len: 0x200000, (find: 0, align: 0x200000), addr: 0x33cbdee00000
7190 map: 0xfffffe018592ec30, anon_loc: 0x33cbded54000, addr: 0x33cbdee00000
7189 map: 0xfffffe018592ec30, hint: 0x33c594562000, len: 0x3f0000, (find: 2, align: 0), addr: 0x33c5b69b1000
7188 map: 0xfffffe018592ec30, hint: 0x33c594562000, len: 0x17000, (find: 2, align: 0), addr: 0x33c5b6009000
7187 map: 0xfffffe018592ec30, hint: 0x33c594562000, len: 0x21000, (find: 2, align: 0), addr: 0x33cbded33000
7186 map: 0xfffffe018592ec30, anon_loc: 0x49b32b000000, addr: 0x33cbded33000
7185 map: 0xfffffe018592ec30, hint: 0x33c594562000, len: 0x20000000, (find: 1, align: 0), addr: 0x33c595237000
7184 map: 0xfffffe018592ec30, interp addr: 0x33cbded13000
7183 map: 0xfffffe018592ec30, anon_loc: 0x49b32b000000
7182 map: 0xfffffe018592ec30, dyn addr: 0x33bd94558000
7181 map: 0xfffffe018592ec30, maxv: 0x7ffffffff000

Consequently, the initial alignment of anon_loc is lost.

I did some testing with and without the previous version of the patch. I simply did a "buildworld" as the workload.

I believe that this particular change has been subsumed by 9e8174289236.

In D39845#922683, @kib wrote:

Misalignment is perhaps a different issue. We can select aligned top for stack, and aligned anon_loc each time we have to choose one.

In D39845#921521, @kib wrote:

In D39845#921390, @alc wrote:

Another option would be to pick a random virtual address for anon_loc at execve() time, and never update it. So, all virtual address allocations would be performed using an address-ordered, first-fit policy, just like we do when ASLR is turned off.

Are you proposing yet another mode for cluster_anon, or you mean to replace the mode 2 'always cluster' with this variant?

The arm64 code for the binary search is

dd4: 90000008      adrp    x8, 0x0 <vm_phys_paddr_to_vm_page+0x8>
dd8: 2a1f03e9      mov     w9, wzr
ddc: b940010a      ldr     w10, [x8]
de0: 90000008      adrp    x8, 0x0 <vm_phys_paddr_to_vm_page+0x14>
de4: 91000108      add     x8, x8, #0
de8: 3400018a      cbz     w10, 0xe18 <vm_phys_paddr_to_vm_page+0x4c>
dec: 5280070b      mov     w11, #56
df0: 2a0a03ec      mov     w12, w10
df4: 4b09018d      sub     w13, w12, w9
df8: 0b4d052d      add     w13, w9, w13, lsr #1
dfc: 9bab21ae      umaddl  x14, w13, w11, x8
e00: f94005ce      ldr     x14, [x14, #8]
e04: eb0001df      cmp     x14, x0
e08: 1a8d8529      csinc   w9, w9, w13, hi
e0c: 1a8c81ac      csel    w12, w13, w12, hi
e10: 6b09019f      cmp     w12, w9
e14: 54ffff01      b.ne    0xdf4 <vm_phys_paddr_to_vm_page+0x28>

Address Mark's comments.

Another option would be to pick a random virtual address for anon_loc at execve() time, and never update it. So, all virtual address allocations would be performed using an address-ordered, first-fit policy, just like we do when ASLR is turned off.

The riscv pmap names this macro PTE_TO_PHYS, and I will argue for using the same name both here and there. Whether that happens by renaming it here, or there, I don't care. I just don't want them to use different names for doing similar things.

I am in the middle of making up a final exam for my class. I will take a final look at this on Wednesday.

Overall, I think that this is okay.

I assume that you did not modify pmap_pti_pcid_invlpg and pmap_pti_pcid_invlrng in support.S because the broken do not require PTI. Is that correct?

Do you have any guess as to how long we might be stuck with this workaround? If the need for it persists, then we may want to have a wrapper to optimize the range operations to avoid repeating INVPCID_CTXGLOB.

Add @dougm

Update comment.

As an aside, in a few weeks, I may eliminate the requirement that PG_A/ATTR_AF is set, add a call to pmap_promote_{pde,l2}() from pmap_enter_quick_locked(), and change pmap_advise(MADV_FREE) to simply write protect one 4KB mapping after demotion (rather than destroying it).

In D36685#838132, @jhb wrote:

In D36685#838118, @alc wrote:

Everything in _pv_entry.h except for the notion of there being a struct pv_entry with at least a virtual address and TAILQ is original to peter@. I don't see a reason for a Regents copyright.

Mmmm, ok. I can drop the UCB copyright, but @peter would have to be the one to change it to a 2 clause license.

Everything in _pv_entry.h except for the notion of there being a struct pv_entry with at least a virtual address and TAILQ is original to peter@. I don't see a reason for a Regents copyright.

See D36801 for changes to the amd64 and arm64 pmaps to avoid the unnecessary pmap_enter_quick_locked() calls. I recommend merging those changes to riscv.

You might ask @dougm to take a look at this.

In D36563#832162, @markj wrote:

pmap_enter_object() is used only to prefault mappings [of a single VM object], so it is allowed to do nothing. I'm not sure if that was the intent behind the interface when it was first introduced, since the name doesn't suggest that it is advisory.

Shouldn't the same change be made on arm64?

Shouldn't the same change be made on arm64?