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

[Noah Goldstein <goldstein.w.n@gmail.com>]

On Fri, Jun 9, 2023 at 9:07 PM Gabriel Ravier <gabravier@gmail.com> wrote:
>
> On 6/10/23 03:11, Noah Goldstein via Libc-alpha wrote:
> > On Fri, Jun 9, 2023 at 12:59 AM Zack Weinberg via Libc-alpha
> > <libc-alpha@sourceware.org> wrote:
> >> 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?
> >>
> > There are some output only registers for syscalls on x86_64 at least.
> > rcx/r11. Those get clobbered by syscall anyways so writing to rcx
> > instruction beforehand would probably not break anything.
> The syscall instruction itself overwrites these with rip and rflags, so
> how is the kernel is supposed to determine what value they had beforehand ?

Oh, I thought that happened before the return to userspace, not before
the transition to the kernel. Nevermind.
> >> zw
>
>