amd64/pmap: Remove !SMP TLB invalidation routines

[markj]

Summary

The complexity of maintaining two sets of invalidation routines does not
seem worth the benefit. In particular, after spending time debugging
the problem resolved by commit 5ad29bc8d4d4, I am skeptical that the
removed code gets much testing. Let's just unconditionally use the SMP
routines.

[alc]

sys/amd64/amd64/pmap.c

10337

I think that you deleted the wrong line here,

[markj]

Fix a silly mistake

[alc]

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.

[kib]

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.

[markj]

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.

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.

[kib]

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.

[markj]

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.

[alc]

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.

Remove it.