x86: Short-circuit ipi_all_but_self() on UP systems

[markj]

Summary

Apparently this is required on old intel hw, see
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275086#c3

PR: 275086
Fixes: 279cd05b7e4d ("Use APIC_IPI_DEST_OTHERS for bitmapped IPIs too.")
MFC after: 1 week
Diagnosed by: Ben Wilber <[e-mail]>

[kib]

The real fix is to remove i386 kernel, of course.

[markj]

In D48361#1102810, @kib wrote:

The real fix is to remove i386 kernel, of course.

Indeed, but I'll MFC this to 14, and perhaps the micro-optimization will be welcome on UP amd64 systems (i.e., VMs).

[ehem_freebsd_m5p.com]

I would have liked to see a comment left in the file. I suspect someone down the line will wonder why someone bothered to optimize this case. This might help uniprocessor VMs, but multiprocessor VMs are also very common. While a single branch is cheap, this still means a tiny performance loss if you've got more than one.

Too a point I wonder whether it might be worthwhile to have a kernel option to make the kernel require more than one processor. Certainly an awful lot of multiprocessor support is leaking into uniprocessor kernels.

[markj]

In D48361#1104681, @ehem_freebsd_m5p.com wrote:

I would have liked to see a comment left in the file. I suspect someone down the line will wonder why someone bothered to optimize this case. This might help uniprocessor VMs, but multiprocessor VMs are also very common. While a single branch is cheap, this still means a tiny performance loss if you've got more than one.

How about: /* Some very old Intel CPUs will raise an LAPIC error if a message is not acknowledged by any APIC. */ ?

Too a point I wonder whether it might be worthwhile to have a kernel option to make the kernel require more than one processor. Certainly an awful lot of multiprocessor support is leaking into uniprocessor kernels.

I don't see much evidence so far that it would be worthwhile. Kernels that aren't GENERIC get far less testing, and accumulate bugs that discourage users and distract developers. For instance, TLB invalidation was quite broken on amd64 with "nooptions SMP" until commit 5ad29bc8d4d4, and the only conclusion I can draw from that is that very few users are running such a configuration. So, why support it? We don't have the resources for such things.