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 61D6DC25B47 for ; Fri, 27 Oct 2023 16:49:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D22C86B0385; Fri, 27 Oct 2023 12:49:41 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CAC936B0387; Fri, 27 Oct 2023 12:49:41 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B4C556B0389; Fri, 27 Oct 2023 12:49:41 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id A2A426B0385 for ; Fri, 27 Oct 2023 12:49:41 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 8449F1CB113 for ; Fri, 27 Oct 2023 16:49:41 +0000 (UTC) X-FDA: 81391827762.09.5BA2A6E Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf03.hostedemail.com (Postfix) with ESMTP id B27E720007 for ; Fri, 27 Oct 2023 16:49:39 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf03.hostedemail.com: domain of "SRS0=vN3B=GJ=goodmis.org=rostedt@kernel.org" designates 145.40.68.75 as permitted sender) smtp.mailfrom="SRS0=vN3B=GJ=goodmis.org=rostedt@kernel.org" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1698425379; 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; bh=WALRrWciQzWK/SZFj95QwPubKh2he0JtQ0OZ6nWqRY8=; b=0qffI/g0wFfh5jHa4rymo+Vj4c8l02dSZW4HwgKj3z9pl8maE/PpHAVGJtfxNZrx85Zk4I g6GmPeNquMIagILXp65Trf1hb5gR2BL0H+UD2e6JCkShs0XVcpOMZCKl2iwRhgqv/4I+dl kx7vQ2IEbJkznLMPJ7i6Nhe069sB0pU= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf03.hostedemail.com: domain of "SRS0=vN3B=GJ=goodmis.org=rostedt@kernel.org" designates 145.40.68.75 as permitted sender) smtp.mailfrom="SRS0=vN3B=GJ=goodmis.org=rostedt@kernel.org" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1698425379; a=rsa-sha256; cv=none; b=UrjgbaqMrhgWvsI+6aQc9cpoAb/y6Sm4cQXRwjvuQfe72QNcb0IaNK8xp2SFUbg8Waacue Rje6Vu3u+p6wGd7tIYRiO+qSuuM+BRjTpw+n2DHQYvMOA4pFJH8iQl9U7e3Xm8Vv9L9ZWu suhuTu0/wC8feJXGK8CMfMI9qvpprpQ= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by ams.source.kernel.org (Postfix) with ESMTP id CB593B808BE; Fri, 27 Oct 2023 16:49:37 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0DA1BC433C8; Fri, 27 Oct 2023 16:49:33 +0000 (UTC) Date: Fri, 27 Oct 2023 12:49:30 -0400 From: Steven Rostedt To: Mathieu Desnoyers 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 Subject: Re: [POC][RFC][PATCH v2] sched: Extended Scheduler Time Slice Message-ID: <20231027124930.3753cdd4@gandalf.local.home> In-Reply-To: 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> X-Mailer: Claws Mail 3.19.1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: B27E720007 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: dythzg635f87aodjysojug8o3qhizbib X-HE-Tag: 1698425379-839359 X-HE-Meta: U2FsdGVkX18kMYkVgfLIMJ0tehVmmoTJWa3urURrZv8NFbU4/+ct7nBGn1ra/oeMTIYTpWivrFkrBFyiuLQu1KI5Oi1d7220ZhhoMMO0IpH/NKygylDG+RYlR0Nk2H4+P3zQb0l5kPLX/C54+VqGGS9UGoui/FrcTUIVJG80zP4myh8k0LeI6UrtLsC6h5j0lonsUYfs08d7Vf8xjwbQNmH7JWXyjcxHrQ+jTC/Ob6BGaNPKGHU9fs1HjnW/4d76rmaPJ9yUrJApZOdkQU0uh6rqZ3Pr/qh+DLEv9P26NWOoQ3Jq/tCavEvzaMpCQcalqj0ryNmOJPBQ/zxC3NUbW4bp4YSiEBx3k2+hbThRCzvqwqVHa0dZ/hZRDDi6G8+kNs3I5EsvtK91JeOaevxZuMSlw02Q0UOSgvTTQzHzQQvYezonj7vArbV4qp/TBFymBlwjFhNL3fK+hEH9nFlGmxLvGTLtTeXjKimLpdqjDVaJOIePHXg0kHjEjIwW27EFtzMx9c5BdqJ2CSxVB/vD0kDFJsPJ5gNizlfMB1VSK1C/Sbe6Wo8vOZzaQHmp+Fb+ZRH1HRgH7Re4Xf1Uuj9jbbNXJ79nfbVf98Aq+M9qSBh+awzMZfIsDem3F2iw2LQj5LccDReLHVUSVtHZdxgnMLKKDxkivkQCOSvAprcB6jcab/HtPhsAEVV8hBpwuh4DjXKbD9/P2Vqio+48tdcr3KrNyCAMp7E9jEKsKagmkoNHoz4vQB/jidJW6qiDIGI5nFh0QXSeyqM0miFNHBZ8Q3SWs3OGmHwcjo3sn+qHEIJ2jybcAHcTbBhNYV7p7EfijAHhMLAfvZog8417gsLl3fLX5AldTbbVRD9LJolDcYkxn2qQilBhhHBNgtdViUJsHlDth5AvURnUay31Abq+d7JCukmf8Ra4ZvmXtRaSjwRmCjZi2fKVYR3cg6XoxscmECBzhvUom+eAkDLzcIE LQ5mo0Nq 0y/lKknp9EccQP0w+J+bmuhKPV9hvgEPYAA1bWNJJRNOjmV0bmg1b6gvEzhQLX1w4fqFDgjpvf+tdVpDp/HTxn8sA+n2nhvuVd9GU9mU7Q0TcYCbpAtSgqViICQM/ThYrQrfQ0/Tvu3Cfyka1beOtToltZU+pc5JauqGHi9IMLXDGoT4b0sqofA9AWfP9UCg6WyjuL8is/0cSN6qtOpgeRl+H897Cac6Ca6vxdFHM4Cj3x/BZZutAVZz6/L4s/kpwRam6SnMF0R4U+kTRL/pCUYPiephWkGLbn37i6M/tmlrSYc9GvFt072yHJw== 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 Fri, 27 Oct 2023 12:35:56 -0400 Mathieu Desnoyers wrote: > > 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. Note, my original implementation of nested locking was done completely in user space. int __thread lock_cnt; extend() { if (lock_cnt++) return; ... } unextend() { if (--lock_cnt) return; ... } > > 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 ? Correct. Just a per cpu atomic. Hence a "andb" instruction, or the "subl", or whatever. > > 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 ? I mentioned about placing this in different bytes, although I meant words, but yeah, if we make them separate it would make it easier. But me being frugal about memory, If this was just two bits (or even a counter with an extra bit) I didn't think about wasting two words for what can be done with one. But this is still an implementation detail, and this code is still very much in flux, and I'm not as worried about those details yet. -- Steve