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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8977CC4332F for ; Thu, 9 Nov 2023 23:42:09 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345389AbjKIXmB (ORCPT ); Thu, 9 Nov 2023 18:42:01 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34874 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229629AbjKIXmA (ORCPT ); Thu, 9 Nov 2023 18:42:00 -0500 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D06463AB7 for ; Thu, 9 Nov 2023 15:41:57 -0800 (PST) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D6806C433C8; Thu, 9 Nov 2023 23:41:48 +0000 (UTC) Date: Thu, 9 Nov 2023 18:41:51 -0500 From: Steven Rostedt To: Dmitry Torokhov Cc: Ankur Arora , linux-kernel@vger.kernel.org, tglx@linutronix.de, peterz@infradead.org, torvalds@linux-foundation.org, paulmck@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, mingo@kernel.org, bristot@kernel.org, mathieu.desnoyers@efficios.com, geert@linux-m68k.org, glaubitz@physik.fu-berlin.de, anton.ivanov@cambridgegreys.com, mattst88@gmail.com, krypton@ulrich-teichert.org, David.Laight@aculab.com, richard@nod.at, mjguzik@gmail.com, Oded Gabbay , Miguel Ojeda , Jens Axboe , Minchan Kim , Sergey Senozhatsky , Sudip Mukherjee , Theodore Ts'o , "Jason A. Donenfeld" , Amit Shah , Gonglei , "Michael S. Tsirkin" , Jason Wang , "David S. Miller" , Davidlohr Bueso , Jonathan Cameron , Dave Jiang , Alison Schofield , Vishal Verma , Ira Weiny , Dan Williams , Sumit Semwal , Christian =?UTF-8?B?S8O2bmln?= , Andi Shyti , Ray Jui , Scott Branden , Chris Packham , Shawn Guo , Sascha Hauer , Junxian Huang , Will Deacon , Joerg Roedel , Mauro Carvalho Chehab , Srinivas Pandruvada , Hans de Goede , Ilpo =?UTF-8?B?SsOkcnZpbmVu?= , Mark Gross , Finn Thain , Michael Schmitz , "James E.J. Bottomley" , "Martin K. Petersen" , Kashyap Desai , Sumit Saxena , Shivasharan S , Mark Brown , Neil Armstrong , Jens Wiklander , Alex Williamson , Helge Deller , David Hildenbrand Subject: Re: [RFC PATCH 85/86] treewide: drivers: remove cond_resched() Message-ID: <20231109184151.52a9aa33@gandalf.local.home> In-Reply-To: References: <20231107215742.363031-1-ankur.a.arora@oracle.com> <20231107230822.371443-1-ankur.a.arora@oracle.com> <20231107230822.371443-29-ankur.a.arora@oracle.com> 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 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 9 Nov 2023 15:25:54 -0800 Dmitry Torokhov wrote: > Hi Anhur, > > On Tue, Nov 07, 2023 at 03:08:21PM -0800, Ankur Arora wrote: > > There are broadly three sets of uses of cond_resched(): > > > > 1. Calls to cond_resched() out of the goodness of our heart, > > otherwise known as avoiding lockup splats. > > ... > > What about RCU stalls? The calls to cond_resched() in evdev.c and > mousedev.c were added specifically to allow RCU to run in cases when > userspace passes a large buffer and the kernel is not fully preemptable. > First, this patch is being sent out premature as it depends on acceptance of the previous patches. When the previous patches are finished, then we don't need cond_resched() to protect against RCU stalls, because even "PREEMPT_NONE" will allow preemption inside the kernel. What the earlier patches do is introduce a concept of NEED_RESCHED_LAZY. Then when the scheduler wants to resched the task, it will set that bit instead of NEED_RESCHED (for the old PREEMPT_NONE version). For VOLUNTARY, it sets the LAZY bit of SCHED_OTHER but NEED_RESCHED for RT/DL tasks. For PREEMPT, it will always set NEED_RESCHED. NEED_RESCHED will always schedule, but NEED_RESCHED_LAZY only schedules when going to user space. Now after on tick (depending on HZ it can be 1ms, 3.3ms, 4ms 10ms) if NEED_RESCHED_LAZY is set, then it will set NEED_RESCHED, forcing a preemption at the next available moment (when preempt count is zero). This will be done even with the old PREEMPT_NONE configuration. That way we will no longer play whack-a-mole to get rid of all he long running kernel paths by inserting cond_resched() in them. -- Steve