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 A8A07CDB47E for ; Wed, 18 Oct 2023 17:41:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1BB938D0175; Wed, 18 Oct 2023 13:41:17 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 11C838D0016; Wed, 18 Oct 2023 13:41:17 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 00B778D0175; Wed, 18 Oct 2023 13:41:16 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id E50B78D0016 for ; Wed, 18 Oct 2023 13:41:16 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id AE1D31A024B for ; Wed, 18 Oct 2023 17:41:16 +0000 (UTC) X-FDA: 81359298552.07.295BED4 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf11.hostedemail.com (Postfix) with ESMTP id B449040012 for ; Wed, 18 Oct 2023 17:41:14 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf11.hostedemail.com: domain of "SRS0=xY8f=GA=goodmis.org=rostedt@kernel.org" designates 145.40.68.75 as permitted sender) smtp.mailfrom="SRS0=xY8f=GA=goodmis.org=rostedt@kernel.org" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1697650875; 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=F4/Uq8vkGDUl/fsie744LijKkURhPyJqG0jzyJJ7yCQ=; b=hVU/qR1evK/B46DaB2I+Ec3r5y71wonGtw5rQExdZc0E/3p1eSilSQ1FFTIxI+0KLLWl0q K/ag8b9u8rKpMWEZe5GgQvPqXnicd2uQ1UzF4NpFnLmn81XUq8iB8/N5lsbIvqNP8BTxWd EZuU6Nn47prYIc2MvVjQkMrxZnoIndg= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf11.hostedemail.com: domain of "SRS0=xY8f=GA=goodmis.org=rostedt@kernel.org" designates 145.40.68.75 as permitted sender) smtp.mailfrom="SRS0=xY8f=GA=goodmis.org=rostedt@kernel.org" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1697650875; a=rsa-sha256; cv=none; b=QHlIcwYc94rPXwSKdfxbQMP0wmCT39C84y57MyFnrwwBJ3VadakF9U+I+LvWWeb6WYPCah 2ZTPb0viyhieLCwtqf4l/UU1YjI2VBLIPmR01bKsIPz+bBAhhaKiFRvTKnANuSD5RSFV1i A1uH/E3lFT2/vUvT1fk+YtccEdu84RM= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by ams.source.kernel.org (Postfix) with ESMTP id 1BA56B821B3; Wed, 18 Oct 2023 17:41:13 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7D0DEC433C8; Wed, 18 Oct 2023 17:41:09 +0000 (UTC) Date: Wed, 18 Oct 2023 13:41:07 -0400 From: Steven Rostedt To: "Paul E. McKenney" Cc: Thomas Gleixner , Linus Torvalds , Peter Zijlstra , Ankur Arora , linux-kernel@vger.kernel.org, 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, Frederic Weisbecker Subject: Re: [PATCH v2 7/9] sched: define TIF_ALLOW_RESCHED Message-ID: <20231018134107.1941dcf5@gandalf.local.home> In-Reply-To: <61bb51f7-99ed-45bf-8c3e-f1d65137c894@paulmck-laptop> References: <87ttrngmq0.ffs@tglx> <87jzshhexi.ffs@tglx> <87pm1c3wbn.ffs@tglx> <61bb51f7-99ed-45bf-8c3e-f1d65137c894@paulmck-laptop> 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-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: B449040012 X-Stat-Signature: jrr7fe9gnf1qjb5gc7uiosrkx99hmuru X-HE-Tag: 1697650874-259594 X-HE-Meta: U2FsdGVkX1+D/GLpnCMmvaBhcBWbvQlNdqG+OKqBQlYdrDrhNKXY2jwlTt77mZOXnUvopqdjrfFFCR4+e36aw3akqVnG73QPR5VN1htWNpzQbuq30lql5UIxEIPt7JQueG/tFrAixVmedOB0d/ciDfugBYd//vL+e13pJjmVZDKnseKl+WYOQ+YA4Y79S3cPk/U4Nr4uQGH+AaCSUqF4KeszDo2jfsdYv+m4Z2QMXwcTMOHVOpsqkQheEyLpjoGVmSh8J9mFannbwyUdN2uXMFcADG8/McfWpZ/13m0fCsc4zU7AcH7pjrbWaxNZcFQvBX1FxpXpEt1+6BOwC8pmyRDiWI6N+e6VXsHTj4h8JSRIOTCxXJ0Z//RsBvv0CXlZ+DMKn9vfVTCWcIKccqd04UI1Cbx4uOyOqPRfRUmDj1xemUFv3snhfQTPXR3c6t0hf8yGHU9Sf4tjjzZFifMw+26PH7+FBX3SsX+OLQGrW2Fqq2UifXZ9hh34r7UTl9L4FVFonohKqjXyBLj9Q59kMCWe8mChNrKZN/poEA3hjq3/YJV5AbBvwa7qNf06W00OV4zm+TibjrflHfAPO2MuQz8LtvgC7vEU6d0302emRt96ueO1fynltjDE6McKwMKW29fJBspkSrKNFiXusYEMvstr8ezngpZUT2OyktSi18/gOJb+nQcjLiUQEL04EX/mYoqjWf4yYneuD6olR9H17Lq/DbEStZcSy+uk4W7Klmso53tB/XkADQaEmRzDKR+WcZ1BdH8+UogivMtfGLV2VwlJwY6cmP9ub2zSe4m3ATaJlIb5tQ7OgGUzZMKzJgEk/RerbzpkIlHpPbYEoG6Gj9fQ95nqkkh0UHWv4H12fkyGbnqnSK+2HSYi9Pv0zaw7cm9E8UCPNnuYvVquVgpazv8jLU4BTte1NjvKHpMe31jpZ4vwMoc2qTjPXPgCEgClyB5a0GoVcrIy5/mAQbB FsqDJSIj jMvu9RZzg7536Zi7AqnOzvwKI+GhX02KeF53M1YF3rMr2csqZJKSzTl2Bl0/0cMgSOqTY++8fEZknTkauApgmzQmu9L9kG99Sw+PBO/UsxJ/EgdEooAeefWbV6iq1wF6XBCH8A/zaqL/ZSz5q8Jdrige22SvO/+gNp8UNci/V/K08f05QA047+1NAXfgQ247w3zY+9FpuM4xcBECvXDSlCsjO9rCqyiW/2WjmSwPq9S+9joonzUf9/umgLcRtf374YQj72R0aErtrU7nT3AglkSULW/7VQcTzC4mlEyjGeyx8zI3jQfnKx7PNodX1eNaI5K5tb+9pDY56nnouvIYFasufMJqTNQk5IOg3+57U1ijJHuY= 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: On Wed, 18 Oct 2023 10:19:53 -0700 "Paul E. McKenney" wrote: > > Isn't rcu_read_lock() defined as preempt_disable() and rcu_read_unlock() > as preempt_enable() in this approach? I certainly hope so, as RCU > priority boosting would be a most unwelcome addition to many datacenter > workloads. > > > With this approach the kernel is by definition fully preemptible, which > > means means rcu_read_lock() is preemptible too. That's pretty much the > > same situation as with PREEMPT_DYNAMIC. > > Please, just no!!! Note, when I first read Thomas's proposal, I figured that Paul would no longer get to brag that: "In CONFIG_PREEMPT_NONE, rcu_read_lock() and rcu_read_unlock() are simply nops!" But instead, they would be: static void rcu_read_lock(void) { preempt_disable(); } static void rcu_read_unlock(void) { preempt_enable(); } as it was mentioned that today's preempt_disable() is fast and not an issue like it was in older kernels. That would mean that there will still be a "non preempt" version of RCU. As the preempt version of RCU adds a lot more logic when scheduling out in an RCU critical section, that I can envision not all workloads would want around. Adding "preempt_disable()" is now low overhead, but adding the RCU logic to handle preemption isn't as lightweight as that. Not to mention the logic to boost those threads that were preempted and being starved for some time. > > > 6. You might think that RCU Tasks (as opposed to RCU Tasks Trace > > > or RCU Tasks Rude) would need those pesky cond_resched() calls > > > to stick around. The reason is that RCU Tasks readers are ended > > > only by voluntary context switches. This means that although a > > > preemptible infinite loop in the kernel won't inconvenience a > > > real-time task (nor an non-real-time task for all that long), > > > and won't delay grace periods for the other flavors of RCU, > > > it would indefinitely delay an RCU Tasks grace period. > > > > > > However, RCU Tasks grace periods seem to be finite in preemptible > > > kernels today, so they should remain finite in limited-preemptible > > > kernels tomorrow. Famous last words... > > > > That's an issue which you have today with preempt FULL, right? So if it > > turns out to be a problem then it's not a problem of the new model. > > Agreed, and hence my last three lines of text above. Plus the guy who > requested RCU Tasks said that it was OK for its grace periods to take > a long time, and I am holding Steven Rostedt to that. ;-) Matters what your definition of "long time" is ;-) -- Steve