[0/5] xen/wait: Improvements

Message

Andrew Cooper July 18, 2022, 7:18 a.m. UTC

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

 xen/common/domain.c     |   2 -
 xen/common/sched/core.c |   4 +-
 xen/common/wait.c       | 117 +++++++++++++++++++++++++-----------------------
 xen/include/xen/sched.h |   1 -
 4 files changed, 63 insertions(+), 61 deletions(-)

Comments

Jan Beulich July 18, 2022, 11:11 a.m. UTC | #1

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?

Jan

Andrew Cooper July 18, 2022, 11:24 a.m. UTC | #2

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