[PATCH v1 1/2] x86: Implement sched_yield syscall for x86 only.

[Zack Weinberg]

On Thu, Jun 8, 2023, at 5:25 PM, Florian Weimer wrote:
> The problem is that it's not beneficial in general and might impact
> small packet receive performance with an event loop (where the
> previous poll ensures that the subsequent recvmsg etc. is pretty much
> always non-blocking).  But in other cases, receive operations are
> blocking, and would benefit from that VZEROALL.
>
> Only the kernel knows if the VZEROALL equivalent is beneficial during
> that particular execution of the system call.  But glibc still needs
> to help the kernel and communicate that discarding the vector state is
> safe in this particular context.

The negative effect on non-blocking syscalls would be due to the cost of
the VZEROALL itself, right?

I'm not having any luck thinking of a good way to communicate this
context information to the kernel.  If we could put flags in the high
bits of syscall numbers that would be very efficient, but it would break
compatibility with old kernels, old strace binaries, and lots of other
stuff.  But any other place we could put it would involve either
stomping on another register (and IIRC there are no call-clobbered
integer registers _left_ to stomp on) or making the kernel do an extra
memory load in the syscall entry path.  Have you got any ideas?

zw