From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) by sourceware.org (Postfix) with ESMTPS id 226263858C20 for ; Fri, 9 Jun 2023 05:59:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 226263858C20 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=owlfolio.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=owlfolio.org Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 58A753200924 for ; Fri, 9 Jun 2023 01:59:45 -0400 (EDT) Received: from imap45 ([10.202.2.95]) by compute1.internal (MEProxy); Fri, 09 Jun 2023 01:59:45 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=owlfolio.org; h= cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to; s=fm3; t=1686290384; x=1686376784; bh=uU SNRC+U3fSXsgbc4kKd0z1goINIydTudg2NDb/Hrhw=; b=jLomObqMvWMHIeaOih xwE6FuduCj9YBB+AHWT3gEPo7qHf88pBre2vItbFU8YSsjxkZT5vlzFb4kQRBmE5 wUpEfqjU1Ifg9unvDh1qZSQN68k7/kmsh6F5E1NI0qZQkvdUjb7enOJf3eLRIk50 FTXbUSO+JyUqadZrclkCdM6T4wxv4zth7mpYFmjek9L3CzsYNjmZaUJJC03uLZch SVWr+i4tk22BQzJD5wh/xX+SHT9BhJF62bpAmKWWYHspagS6G1gahPm7bVYReSyt tix69HLdYDLYnJnMuJVTO7Q8ZQLdfGHpn9B4t8mc+PMBH84aKY9nAN3WycgBaj6B kKcQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; t=1686290384; x=1686376784; bh=uUSNRC+U3fSXs gbc4kKd0z1goINIydTudg2NDb/Hrhw=; b=v+tacmc7wZH2xxj20d1S7Zf+OPQlB bNXWUzta3cwkQpOSFzTGl0j0204qiWgqEX35OqYRaFsQ3tM6blv1J/YqO8Rld4O1 RXIRx7FSrYTPt6pWDOKghkfn0paALAy2se/y6WKzIYnjSS2IMI8iCNqICrrAA4x6 Wntm9ary8FxvH1qxkPMQ3YYX6UhkuelUQhZz9YuPCXPWAgWv3VhseI7FlOjJwxR1 4JaU7/FOARuaTIcjOoRfs4GYReeKeK9jiWZGfy5Y94lWWcwBFcbti3RkS1+x9Brc emGHkfN+xGY6VdCsxhgePm5+Ikwm49XrQYnrTcJ7REmucbr8XruALacFQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrgedtjedguddtvdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefofgggkfgjfhffhffvufgtsehttdertderredtnecuhfhrohhmpedfkggr tghkucghvghinhgsvghrghdfuceoiigrtghksehofihlfhholhhiohdrohhrgheqnecugg ftrfgrthhtvghrnhephfeuhfevueffteffgfejtefgkeekheeftdeflefgheffffevheek leefgfehffdunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepiigrtghksehofihlfhholhhiohdrohhrgh X-ME-Proxy: Feedback-ID: i876146a2:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 9F2A2272007A; Fri, 9 Jun 2023 01:59:44 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.9.0-alpha0-447-ge2460e13b3-fm-20230525.001-ge2460e13 Mime-Version: 1.0 Message-Id: In-Reply-To: <87sfb18x4d.fsf@mid.deneb.enyo.de> 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> Date: Fri, 09 Jun 2023 01:59:24 -0400 From: "Zack Weinberg" To: "GNU libc development" Subject: Re: [PATCH v1 1/2] x86: Implement sched_yield syscall for x86 only. Content-Type: text/plain X-Spam-Status: No, score=-3.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,JMQ_SPF_NEUTRAL,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,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 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