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 C51B1EE57DF for ; Mon, 11 Sep 2023 16:48:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4F31F6B02B5; Mon, 11 Sep 2023 12:48:53 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4A2C46B02B7; Mon, 11 Sep 2023 12:48:53 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3929E6B02B9; Mon, 11 Sep 2023 12:48:53 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 2AE4D6B02B5 for ; Mon, 11 Sep 2023 12:48:53 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id D7B1C80A94 for ; Mon, 11 Sep 2023 16:48:52 +0000 (UTC) X-FDA: 81224900904.27.1C5597A Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf10.hostedemail.com (Postfix) with ESMTP id A6028C0015 for ; Mon, 11 Sep 2023 16:48:50 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf10.hostedemail.com: domain of "SRS0=M4tJ=E3=goodmis.org=rostedt@kernel.org" designates 145.40.73.55 as permitted sender) smtp.mailfrom="SRS0=M4tJ=E3=goodmis.org=rostedt@kernel.org" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1694450931; 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=tb7ZazuhEyTa2upxyZleaaw/IvCwWpx9qz+BH0om5eI=; b=nR7bsr8Jc8RlrmvHlbB73JMLL02B5JMGWwLITfLmvFQCPyID+jRIDqOF7rqrGNYYkEqpDw XNlxof8Sr0m72Y7tVcs2buT+YDZqncI30SfW83Rn0/7FsrESbhCFnUwBku4aCNM8iBrSam eh0jT0vazPa74lqZ9UXKmj7p3G/zPUU= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf10.hostedemail.com: domain of "SRS0=M4tJ=E3=goodmis.org=rostedt@kernel.org" designates 145.40.73.55 as permitted sender) smtp.mailfrom="SRS0=M4tJ=E3=goodmis.org=rostedt@kernel.org" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1694450931; a=rsa-sha256; cv=none; b=2OewfuAjTuGLk98e30uKCppflqy2gVY6zITpSbzdtB4ggik57yFS5yBX+nOVnfoQ1fOVzV uqDReoR8omGX8uZft78J7MKBUnMHeVWxtAgm9enbsPKAr/Kk49cPI1cOi1JDH5Xci2Ojcj 59TV+9c0f9v/qK220ssx79p3QTTjdGo= Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by sin.source.kernel.org (Postfix) with ESMTPS id 1C4FECE1804; Mon, 11 Sep 2023 16:48:46 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3CAE8C433C8; Mon, 11 Sep 2023 16:48:42 +0000 (UTC) Date: Mon, 11 Sep 2023 12:48:56 -0400 From: Steven Rostedt To: Linus Torvalds Cc: Ankur Arora , Peter Zijlstra , 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, tglx@linutronix.de, jon.grimm@amd.com, bharata@amd.com, raghavendra.kt@amd.com, boris.ostrovsky@oracle.com, konrad.wilk@oracle.com Subject: Re: [PATCH v2 7/9] sched: define TIF_ALLOW_RESCHED Message-ID: <20230911124856.453fba22@gandalf.local.home> In-Reply-To: References: <20230830184958.2333078-1-ankur.a.arora@oracle.com> <20230830184958.2333078-8-ankur.a.arora@oracle.com> <20230908070258.GA19320@noisy.programming.kicks-ass.net> <87zg1v3xxh.fsf@oracle.com> <87edj64rj1.fsf@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 X-Rspam-User: X-Stat-Signature: ma6ajzx1ztwykxsxtsrzjn1d4smgs3x1 X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: A6028C0015 X-HE-Tag: 1694450930-51241 X-HE-Meta: U2FsdGVkX1+Kilu/i/ghnoKx/NUAPhsYCN2bPu4AeOsQpC3odF/JwzkutuRBTVcCU7RTdgtxiFtDqTJUVuK4Bc7syYG3TJxx7SR73gNe2WspPSlALmRLu1Zy2Wu3UsgrwjQguSXDvZRioDHpLoDSzZ94tv5hUH1deRV6IjKjA1Z5Gh2Fo7OOwObExdT77tmQw86YvjaKBSfVmNR7xGaZcZzpdCDLvR8xzoJri58tTKuYoAUoiGuDdBGG+ZrfCxe//2ZrEaaKxxpSVwyf9sNzlmsxmWEnZ6L70dY/RVql3GHO3e4U6sAfjYYzMTF+iUKfmq9ZOqVuLhL4VkwIN620O2aV8R3QeiJLYvnL06ktVSaoYeUzSCX67ho9Ce52jc/mhMhYR4YvW8mvj8dipR8/LExs9vuEHjb9SauFzUK065CUA/1fAL26gevfrkPRLb5FWDxT+o51VcNLj0q0J5x3Jl0BUKj7dz7eHevlzHp82pXDBS/gfgHk75cLciNqJLtWWhjLDBX8Q0NZswtKOV8I0j1OSExILzW/ddF3G6Mke2DZZ6M0ZCShbzr5rLP1FAZ5te2r8ZgWOF8lr3DcSRA5/lcmAMMyki+D+kl/uBPRa2IY0cyulVqnabAA+A5lvy+FijBi+PmKxBOnyXspDhX7dcT6VGE8/XgENedkSouECimP/TudJkx4VvGRJd2P9PRvcKub7XUVPkEPBKXCASpYv9qyq+zUG5NDnS7W/ktS5JNIS5N7PeUZlBM8Zs0K58Qe8FHOI+TaP+ziX6wXVSKNnsev84XRx31ZTX6rs50UvT/ckoZNvt9Yv1YzpI9rFkiIkJWVj7Wx0PHqAgil/Pp1FEgN/f5ioRWSatsk5klLoosMphBT1QI4UoraUSK/yBRue/76+WKU2TAzlssY9U7L9QP9DBDUa9S39rp3AI6Ie7lsjANmEBVfq9I6jIxOSIx/9WONMsixBMrZwZDdAQ9 5/RE7OlO jk+YRbKU2EzU0Aae+RRdCOBIWnTfhSV8lE8xtvDxNtMdq4IruSLH7kOAVsOU/S6TAkvQlg9xmUMlMs3GTL45eU23EUU2Cz6plcPXu5hVRlgOxN4TBv9usZI4jjmsNFCrwD9QZRwN0vR2z0H8OIfeTSR/hCN/tBWIOOtNdeqU3/85ukRngXj2w18iamUXaV7hNsKyB/JEckFVU5JtjOrIhgyC/1doumlhIjoijH4CRKGXsyE8EYu7GPH7newQ0waULrQeodd/iy3QZyKWabuDqkHzG9bVUkQO4+wkCYo0Yg1LVa8p+Tc1vY6b/GU9XG2Rst1g/X4Obfu2ltkMQFqbPwClUqQrXNAYTQeOOUMYr8Fi4QywxNrg3YxMRoHNwL01nhwfghs3GiiBVcJuF7qhLuugjviaf7pI3z/ShVkQ/9YdeDz7kGD6qSIX2bu8B3FRLRaj5UEAbz1oXLJ2l79jhi5iO8iBMNJOJGb6J 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 Sat, 9 Sep 2023 21:35:54 -0700 Linus Torvalds wrote: > On Sat, 9 Sept 2023 at 20:49, Ankur Arora wrote: > > > > I think we can keep these checks, but with this fixed definition of > > resched_allowed(). This might be better: > > > > --- a/include/linux/sched.h > > +++ b/include/linux/sched.h > > @@ -2260,7 +2260,8 @@ static inline void disallow_resched(void) > > > > static __always_inline bool resched_allowed(void) > > { > > - return unlikely(test_tsk_thread_flag(current, TIF_RESCHED_ALLOW)); > > + return unlikely(!preempt_count() && > > + test_tsk_thread_flag(current, TIF_RESCHED_ALLOW)); > > } > > I'm not convinced (at all) that the preempt count is the right thing. > > It works for interrupts, yes, because interrupts will increment the > preempt count even on non-preempt kernels (since the preempt count is > also the interrupt context level). > > But what about any synchronous trap handling? > > In other words, just something like a page fault? A page fault doesn't > increment the preemption count (and in fact many page faults _will_ > obviously re-schedule as part of waiting for IO). I wonder if we should make it a rule to not allow page faults when RESCHED_ALLOW is set? Yeah, we can preempt in page faults, but that's not what the allow_resched() is about. Since the main purpose of that function, according to the change log, is for kernel threads. Do kernel threads page fault? (perhaps for vmalloc? but do we take locks in those cases?). That is, treat allow_resched() like preempt_disable(). If we page fault with "preempt_disable()" we usually complain about that (unless we do some magic with *_nofault() functions). Then we could just add checks in the page fault handlers to see if allow_resched() is set, and if so, complain about it like we do with preempt_disable in the might_fault() function. -- Steve