On 18/07/2022 12:11, Jan Beulich wrote: > On 18.07.2022 09:18, Andrew Cooper wrote: >> This started out as patch 2 for a different task, and quickly identified some >> technical debt, long overdue for cleaning up. >> >> Andrew Cooper (5): >> xen/wait: Drop vestigial remnants of TRAP_regs_partial >> xen/wait: Extend the description of how this logic actually works >> xen/wait: Minor asm improvements >> xen/wait: Use relative stack adjustments >> xen/wait: Remove VCPU_AFFINITY_WAIT > While going through this series I came to notice that we build wait.c even > on Arm, and I couldn't convince myself that wait_event() is actually not > reachable there when e.g. there's an Arm-specific vm_event.c. I would > generally prefer if non-functioning code paths were actually compiled out. > > Thoughts?
I've been wanting to delete wait.c fully for a long time. It is only needed because the event/paging/access interfaces still use a single 4k shared ring, and even then, only when you happen to fill the 4k ring, which is 11 vCPUs on x86 last I checked. I could easily believe that limit has never been tripped on ARM. There are plenty of perf wins to be had by building a new Xen=>agent interface using acquire_resource, which include being able to guarantee that we never need to pause a vCPU to wait for space in the ring to post a event. With the interface fixed, wait.c ceases to have any use whatsoever. ~Andrew
