It has been a long time since I looked at this man page. In the interest of making sure that these changes were written in an style consistent with the rest of the man page, I decided to take a look, and having done so the following bits concern me:

In D52744#1205856, @andrew wrote:

In D52744#1205716, @alc wrote:

In D52744#1205060, @andrew wrote:

Note that the llsc instructions have some subtly when implementing fully sequentially consistent semantics. As the acquire and release are on different instructions this means memory operations may move into the sequence & be swapped. As we don't implement them in atomic(9) this shouldn't be an issue, however will be if we latter add them.

I vaguely recall Linux having an issue with the aforementioned behavior about 8-10 years ago in the implementation of a synchronization primitive.

I've known about the issue on Linux
This is the fix for Linux issue https://github.com/torvalds/linux/commit/8e86f0b409a44193f1587e87b69c5dcf8f65be67. It's not been a problem on FreeBSD as we don't have atomic operations with a full barrier in atomic(9).

In D52744#1205060, @andrew wrote:

On arm64 atomics with an acquire then later memory operations can move before the store, however the store needs to succeed as if it doesn't then we will execute the load-acquire again.

I don't think the CAS instructions allow this. The pseudo-code has the comment All observers in the shareability domain observe the following load and store atomically before listing the load and store operations. This seems to indicate if the load has been observed the store has too.

Note that the llsc instructions have some subtly when implementing fully sequentially consistent semantics. As the acquire and release are on different instructions this means memory operations may move into the sequence & be swapped. As we don't implement them in atomic(9) this shouldn't be an issue, however will be if we latter add them.

I am happy to see how much simpler this has gotten, particularly the elimination of the range lock.

In principle, I am okay with this change. However, I do have some questions.

I have been following this, but have not given it a careful reading. I should be able to do so over the weekend.

In D52165#1191863, @imp wrote:

Generally I like it, but the name is very long and specific for the logical concept of 'map this into the physical for I/O and keep it there'. But I have no better name, so I'll just grouse because I never could remember the order of the verbs when I was writing the nvme mapping code.

Eliminate unnecessary indirection.

In D49442#1163947, @markj wrote:

In D49442#1163641, @alc wrote:

I'm really on the fence about this. I could make a respectable argument for either approach.

Perhaps it's reasonable to simply implement both approaches? The patch in review makes some sense on its own, independent of the bug which motivated it: I can't see any practical reason for madvise(DONTNEED or FREE) to have any side effects on wired mappings. On the other hand, it seems sensible to modify the demotion path to handle this case, since we have no rule which says that wired mappings must have PG_A set, so this case could arise again in the future.

In D51431#1174792, @markj wrote:

I believe this makes D49442 unnecessary, at least as far as fixing the bug is concerned.

In D51345#1173699, @markj wrote:

In D51345#1173585, @kib wrote:

In D51345#1173169, @markj wrote:

In D51345#1172943, @kib wrote:

I am curious how does the patch build.
For instance, pmap_invalidate_page() calls smp_masked_invlpg(), which is provided by amd64/mp_machdep.c. And mp_machdep.c is 'optional smp' in files.amd64.

Oops, yes. This was from a larger patch series which entirely removes the SMP option for amd64. With just this patch, a nooptions SMP kernel cannot build.

It is enough to #ifdef SMP the calls to smp_masked_*() in each of the SMP invalidation functions.

What do you think of this goal overall? My belief is that !SMP amd64 kernels are not used very much and are not worth the maintenance overhead. With the complete patch series, all of sys/amd64 simply ignores the SMP option. If you think it's the right direction, I'll post the remaining patches.

I stated publicly more than once that I would like to remove UP at all, and not only for x86. But the discussion never ignited. In other words, I fully support removing as much #ifdef SMPs as we can.

Rather than fix this commit, I propose going further: https://reviews.freebsd.org/D51403

I brought up removal of !SMP support for amd64 last year at bsdcan and there was no objection. I am not sure about the importance of !SMP in general, e.g., maybe it is somewhat important to support it for embedded arm devices. But for amd64 I think there is no reasonable objection to its removal. GENERIC with nooptions SMP is broken in multiple ways and has been for a while.

I have two related observations:

Use ADDR_IS_KERNEL.

I also have an upcoming change in this area. AMD Ryzen processors have long supported a subset of the invpcid instruction’s functionality, even though they don’t support PCID. Specifically, they support the functionality to invalidate PG_G mappings, and not surprisingly this is supposed to be faster than toggling the PGE bit in CR4.

This can be abandoned.

In D51220#1170373, @markj wrote:

Do you have some local modifications to test the ADDR_IS_KERNEL(va) code path in pmap_enter_l2()?

See inline comment for an explanation.

Rename remove_pt to demote_kl2e to better reflect what it controls.

In D51180#1168328, @kib wrote:

Should the pmap_demote_pde() in pmap_unwire() get the same treatment? As I understand, wire should saved the pt page in radix.

In D51179#1168325, @alc wrote:

This lookup originated here:

commit 87b646630c4892e21446cd096bea6bcaecea33ac
Author: Mark Johnston <markj@FreeBSD.org>
Date:   Mon Nov 15 11:35:44 2021 -0500

    vm_page: Consolidate page busy sleep mechanisms
    
    - Modify vm_page_busy_sleep() and vm_page_busy_sleep_unlocked() to take
      a VM_ALLOC_* flag indicating whether to sleep on shared-busy, and fix
      up callers.
    - Modify vm_page_busy_sleep() to return a status indicating whether the
      object lock was dropped, and fix up callers.
    - Convert callers of vm_page_sleep_if_busy() to use vm_page_busy_sleep()
      instead.
    - Remove vm_page_sleep_if_(x)busy().
    
    No functional change intended.
    
    Obtained from:  jeff (object_concurrency patches)
    Reviewed by:    kib
    MFC after:      2 weeks
    Differential Revision:  https://reviews.freebsd.org/D32947

This lookup originated here:

commit 87b646630c4892e21446cd096bea6bcaecea33ac
Author: Mark Johnston <markj@FreeBSD.org>
Date:   Mon Nov 15 11:35:44 2021 -0500

Rebase. Add lockp KASSERT.

I am rather concerned that the pathological case of having to walk up to the root and then back down will be common place. For example, consider a memory mapped file that is read sequentially. The first access, when the file is not yet memory resident, will leave the cursor at the end. Subsequent accesses well then have to walk all the way up, and all the way down to get to the first page.

In D51093#1166331, @kib wrote:

It would be useful to provide a reasoning why the setting is safe.

From my understanding, there are (at least) two situations where TCE would be unsafe:

1. Recursive pt mapping. But when we modify the kernel page table in a way that modifies the paging structure above the lowest level, we also explicitly invalidate the recursive mapping, in pmap_remove_kernel_pde(), pmap_demote_pde(), pmap_demote_pdpe().
2. Sharing page table pages, mostly relevant when sharing occurs not at the leafs of the page table radix tree. We do not do that at all.

Anything else I missing?

dougm@ has been running stress on a Ryzen processor for more than 24 hours, and seen no ill effects.

In D51091#1166112, @kib wrote:

Or, do you want me to integrate this into the series of patches for D50970?