From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x22d.google.com (mail-oi1-x22d.google.com [IPv6:2607:f8b0:4864:20::22d]) by sourceware.org (Postfix) with ESMTPS id B2B383858D35 for ; Sat, 10 Jun 2023 04:59:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B2B383858D35 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-oi1-x22d.google.com with SMTP id 5614622812f47-39c7f5706f0so1114901b6e.3 for ; Fri, 09 Jun 2023 21:59:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1686373171; x=1688965171; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=JGFSqWIuZUqMm66t+yiKkz5cXF2PW0eY3EbI/cXwTVg=; b=E7hKXELxuxfQlgRT67FdGZu1d5W3AoOn+Jt0DWCupElUlLpnrfBRMCrGwAipCVczC7 prI/fWARoI5Z0iRng4Z7rHWrCoR7OGefmlvUGvVdlLhP2CZnRgz1t+OpKMgqcK4LsfCW 6tkONfhCfmCQlkqxTItwrfDHldEQPiDD8lajhug+03SyA7erRb5j6utEBzMRjKR3errV 086iDDOPs9fJnaSV/H276gpfVr/phtUKfxueDDmVbyqpAviyEcNZEymHd+ncWix7zu+L X/NQ3GUkLx4Mngr2/hZz4PnjqfUlKKH5/QzWCH3wnVs3FrvFJcx+5SYwm7IWeCWjdJpw PCeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686373171; x=1688965171; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=JGFSqWIuZUqMm66t+yiKkz5cXF2PW0eY3EbI/cXwTVg=; b=k4evAc50PH7JEJ73aiALcnXkUWImRH4xyGeWOQJcZuubcc1fSCr0erUGnjGAdM0iKT anILBdvjyz00xlqR4VvNN/0s64U678NtUv5u0sIaVAZRxR7n1lF2NNvVVCQ3TPpdsTcW Ap40Pp+KX8KR7LyryxkbQrwlZQrkgxiLFRNdq41rEnuPxNEXKLFvbhzGORfKsagKxX7d lot5bNskStGLtMCXPmNlvuYOlJFghLa/M1uzmNjv/hdeNTYyAhdoRLUl8yhQZq1XMyCa PZIrqrpRolvzjo/SFeT3qNCW1cKlREsUMn9E89kHEq/bKzz/Q8FjxRlIvkfcfSpo7ZcW 8fGg== X-Gm-Message-State: AC+VfDwAGdWxcRmjTX0ezzIEe1Ja86r6olvQdZiXcJoo5SmFlUeSiIFp M+oe8bSbWyLGZVX/7aOd5DpM9mvpLuwxZ6CwY0UsO6NG X-Google-Smtp-Source: ACHHUZ5D0kKCxk3cfqds+tCYxkGqDqRbuztLX48ns4QyALycxNgMjdpKZ+Az2IT53H/K0h0C9pyOdpGGql3+NrdPzXM= X-Received: by 2002:a05:6808:df7:b0:397:fe89:202c with SMTP id g55-20020a0568080df700b00397fe89202cmr386179oic.42.1686373170875; Fri, 09 Jun 2023 21:59:30 -0700 (PDT) MIME-Version: 1.0 References: <20230608090050.2056824-1-goldstein.w.n@gmail.com> <87fs729o2z.fsf@mid.deneb.enyo.de> <51ab6d92-6f27-52bf-c70c-c45c478a3299@linaro.org> <7cf77b35-ce05-421e-b057-c73386bb6b57@app.fastmail.com> <87wn0d91xn.fsf@mid.deneb.enyo.de> <929de107-7a06-4d29-be00-4d3230ead947@app.fastmail.com> <652146a2-4be1-42c6-8052-ad28319bb70a@app.fastmail.com> <87sfb18x4d.fsf@mid.deneb.enyo.de> In-Reply-To: From: Noah Goldstein Date: Fri, 9 Jun 2023 23:59:18 -0500 Message-ID: Subject: Re: [PATCH v1 1/2] x86: Implement sched_yield syscall for x86 only. To: Gabriel Ravier Cc: Zack Weinberg , GNU libc development Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-3.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Fri, Jun 9, 2023 at 9:07=E2=80=AFPM Gabriel Ravier = wrote: > > On 6/10/23 03:11, Noah Goldstein via Libc-alpha wrote: > > On Fri, Jun 9, 2023 at 12:59=E2=80=AFAM Zack Weinberg via Libc-alpha > > 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 i= s > >>> 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 bre= ak > >> 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 > >