From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 12D29C25B47 for ; Fri, 27 Oct 2023 16:35:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 661D16B0383; Fri, 27 Oct 2023 12:35:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5EAC86B0384; Fri, 27 Oct 2023 12:35:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 464136B0385; Fri, 27 Oct 2023 12:35:45 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 325906B0383 for ; Fri, 27 Oct 2023 12:35:45 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 03AF8407C0 for ; Fri, 27 Oct 2023 16:35:44 +0000 (UTC) X-FDA: 81391792650.26.CA43B1F Received: from smtpout.efficios.com (smtpout.efficios.com [167.114.26.122]) by imf19.hostedemail.com (Postfix) with ESMTP id 385181A0002 for ; Fri, 27 Oct 2023 16:35:42 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=efficios.com header.s=smtpout1 header.b=v3LVu9xF; dmarc=pass (policy=none) header.from=efficios.com; spf=pass (imf19.hostedemail.com: domain of mathieu.desnoyers@efficios.com designates 167.114.26.122 as permitted sender) smtp.mailfrom=mathieu.desnoyers@efficios.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1698424542; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=z/i01SXwi3yQ7BQFJ49OvQUV1f/0GYTj4YG4hSVJKzE=; b=xG5bwKBGr/ivgX8tgDKCSbo/WMsYvaI8OCokLc4xVV8hPxZZIFGfD0IcSFiYAoaJXbOiYS qlKr9G6lbesIFWyDxY4miv64oU7EcSind7ieX2yBnpPEagSjIWY9FkXAUg9/+SNp3feS9R bFqRDylEy4gUPfgJvCtyEMvdUOnVnfs= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=efficios.com header.s=smtpout1 header.b=v3LVu9xF; dmarc=pass (policy=none) header.from=efficios.com; spf=pass (imf19.hostedemail.com: domain of mathieu.desnoyers@efficios.com designates 167.114.26.122 as permitted sender) smtp.mailfrom=mathieu.desnoyers@efficios.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1698424542; a=rsa-sha256; cv=none; b=tLy8BFlLkfwZ2sxZS1Wl69KyO2Pbg7nhH1djZf3gc4ffFhjF8SGT2r+o/FhQzMS3Ech4Er A+3IMcEgX5TEbwnHuTJfbekd0NBJix5l2/VfvH80p6wo4EtV0fY8WE02ulcM1v+TkJapE9 ETo19DyXpcQrzTo725yJf63PQK0sYUA= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=efficios.com; s=smtpout1; t=1698424541; bh=QWdx6DFVQZind8QLaT2jE8xtG7kdYVYQ+z2J3UzCR6E=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=v3LVu9xF93x0G9KkuMjo1xbghtWV5AJI2/xDZIzZhG0FIqmXMWLSh4OhUXMLceOZS 3ECnssUtl3jEof3LrweXU+FozM1qVBQpgII5viwZhccQog9DfnjkrDCeyWAvl8LZUu ZB5Dtbqk5C1RmwmrtL+mFXJwnzMXfpoh3zGVyA4yjeQJhYggUeupHPVFqpEljRwbdb MYfqKJA/imvCyzzKkWMwORsO4VgL7+lfJWGp8BkuhuUTC6RdFNZWJMPiBAMoC8N5/v q7PpB1aWQzv+zGPPr85R+s42JYsv8P0HbBTsX07bTfCUZ6t7h7VrJ0sWz9+EnRB0cz S45DZ+sul1jFw== Received: from [172.16.0.134] (192-222-143-198.qc.cable.ebox.net [192.222.143.198]) by smtpout.efficios.com (Postfix) with ESMTPSA id 4SH7ZN6LHgz1ZmM; Fri, 27 Oct 2023 12:35:40 -0400 (EDT) Message-ID: Date: Fri, 27 Oct 2023 12:35:56 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [POC][RFC][PATCH v2] sched: Extended Scheduler Time Slice Content-Language: en-US To: Steven Rostedt Cc: Linus Torvalds , Peter Zijlstra , LKML , Thomas Gleixner , Ankur Arora , linux-mm@kvack.org, x86@kernel.org, akpm@linux-foundation.org, luto@kernel.org, bp@alien8.de, dave.hansen@linux.intel.com, hpa@zytor.com, mingo@redhat.com, juri.lelli@redhat.com, vincent.guittot@linaro.org, willy@infradead.org, mgorman@suse.de, jon.grimm@amd.com, bharata@amd.com, raghavendra.kt@amd.com, boris.ostrovsky@oracle.com, konrad.wilk@oracle.com, jgross@suse.com, andrew.cooper3@citrix.com, Joel Fernandes , Youssef Esmat , Vineeth Pillai , Suleiman Souhlal , Ingo Molnar , Daniel Bristot de Oliveira References: <20231025235413.597287e1@gandalf.local.home> <20231026105944.GJ33965@noisy.programming.kicks-ass.net> <20231026071413.4ed47b0e@gandalf.local.home> <7871472b-a0c4-4475-9671-69a3244f956d@efficios.com> <20231026164549.14d45c60@gandalf.local.home> <644da047-2f7a-4d55-a339-f2dc28d2c852@efficios.com> <20231027122442.5c76dd62@gandalf.local.home> From: Mathieu Desnoyers In-Reply-To: <20231027122442.5c76dd62@gandalf.local.home> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 385181A0002 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: 7dfca9byy5qqip1zqor7urgakch19mbh X-HE-Tag: 1698424542-509972 X-HE-Meta: U2FsdGVkX1/2fIpR9SUH/6H66dM0X5s+N0Xjk2aLXcvWdsKDSlzohqJQl63nGlld6ghqiH5bsGI5WRIK4HcQqG/8rpY9FJw2pEPbs9Hhyp/P4E1qbgwUvmyJVTL8aCTTlgoQecJfGWYbwtUHGcjSGogk1S5w5O98rGRrN3xmySMujL5iY0zZQJRyr3NuWfz7xs56tDXkyNvPCC9CSSYfPvkJRYYFm04XIeLhbaowtof2v2O6MZE521Z6+bSrOSYthwpAA3vUS8+OYXtI3J9pZ4GdkvnHJ5+Pnfr+uOSp+pUQ8aexJb2vMKhsOiauN7J1ezILtQ3FfM+cy/2qoztTIlNpgzN1qB2b70apNLVsaZ2b4nN2v2bFhYPTm+I6sGBVbgtrSeQOKYvqoeA3wS3A50dMdeQSK5nl2QepkKm4nBM+rgLP4+u5ulmFemlDI7bBgyZEJO5KVL4H9ahy5btDOIUIAa4Q2SLLuGAYAaC4pzsID7HGWZhizOXbRQciYloEo3NCmThml5Q7jJyZv15FsHvDZl8YZGBWO7r1sdU+MZRKVXks/cyn/bcFsXd9nWNV3eJfJp/Ng/bwG8HFMyiM8mw0M1siJCc9jFiUUi2NmOWe0yI8DdZHdS2+TP03Fr6YwsxWlVvmCGsT3py7YkgP6i3l6w7EJghL7eyZzYuVPVqOgifotc8WaigdCDNreFdjUe14NomeikS0gRLPIn22QKDLlsY+ueR0CZbJXtUFUv0z3dSKZdYyGFQQHmHpZrD7xIHGdC1/lxyrJDXwCJ5KmT0qpoUkebal55RGaUZUPw7ryd1Z7/JPUwWH1idYdo5UvoO1R3fi298bCFYSRthes9k2M7PpnIEGAtyJ7NCWONOXZ+9SXDfhN5MN7cRn92wQ1bOf15j5TNcBh+GwKA+eHmflKPBeAuu1O5LUC01RT96q98EreLra4tGjlWCJDiMKevqDL0w+aXqwtvZ3PRu N4ufSoLx GWV5gr+PrRfamxQjSUR+QBch07nL+CHm3IQfIdLb2LcvisBeKwOY/LCVQoQQzgyL/+s9NSfq+TOYCcVxGTVPIiYX4uMyxk8h1zzdE8Pj8vmWtg9iOhYcJX9xT47KBI7mVjcqDqqDGwJvCsdIs4YwVU/jrO5Z9b02nej3Y4X7MhUgdBxof2T/t1uZOZt8aeQAbRcmWzb0Dg4EbRIVzqSkn3HXKPVEat3Tp/hC1+oRBpjc+usOsMdc/F0d1bTU5smYiIK9+pm/HPKtnm1fEaCYzwu5/D4s/HP7mQt18A31CqfkIPGY= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On 2023-10-27 12:24, Steven Rostedt wrote: > On Fri, 27 Oct 2023 12:09:56 -0400 > Mathieu Desnoyers wrote: > >>> I need to clear one bit while seeing if another bit is set. I could also >>> use subl, as that would also atomically clear the bit. >> >> Ah ok, I did not get that you needed to test for a different bit than >> the one you clear. > > Yeah, maybe I'm not articulating the implementation as well. > > bit 0: Set by user space to tell the kernel it's in a critical section > > bit 1: Set by kernel that it gave user space extend time slice > > Bit 1 will only be set by the kernel if bit 0 is set. > > When entering a critical section, user space will set bit 0. When it leaves > the critical section, it needs to clear bit 0, but also needs to handle the > race condition from where it clears the bit and where the kernel could > preempt it and set bit 1. Thus it needs an atomic operation to clear bit 0 > without affecting bit 1. Once bit 0 is cleared, it does not need to worry > about bit 1 being set after that as the kernel will only set bit 1 if it > sees that bit 0 was set. After user space clears bit 0, it must check bit 1 > to see if it should now schedule. And it's also up to user space to clear > bit 1, but it can do that at any time with bit 0 cleared. > > extend() { > cr_flags = 1; > } > > unextend() { > cr_flags &= ~1; /* Must be atomic */ > if (cr_flags & 2) { > cr_flags = 0; /* May not be necessary as it gets cleared by extend() */ > sched_yield(); > } > } > > Does that make more sense? Not really. Please see my other email about the need for a reference count here, for nested locks use-cases. By "atomic" operation I suspect you only mean "single instruction" which can alter the state of the field and keep its prior content in a register, not a lock-prefixed atomic operation, right ? The only reason why you have this asm trickiness is because both states are placed into different bits from the same word, which is just an optimization. You could achieve the same much more simply by splitting this state in two different words, e.g.: extend() { WRITE_ONCE(__rseq_abi->cr_nest, __rseq_abi->cr_nest + 1); barrier() } unextend() { barrier() WRITE_ONCE(__rseq_abi->cr_nest, __rseq_abi->cr_nest - 1); if (READ_ONCE(__rseq_abi->must_yield)) { WRITE_ONCE(__rseq_abi->must_yield, 0); sched_yield(); } } Or am I missing something ? Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. https://www.efficios.com