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 259E2EE7FF4 for ; Sun, 10 Sep 2023 04:36:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 37A0C6B0139; Sun, 10 Sep 2023 00:36:17 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 302D16B013A; Sun, 10 Sep 2023 00:36:17 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1A4246B013B; Sun, 10 Sep 2023 00:36:17 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 07CA46B0139 for ; Sun, 10 Sep 2023 00:36:17 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id BD48B12115E for ; Sun, 10 Sep 2023 04:36:16 +0000 (UTC) X-FDA: 81219425952.09.A872029 Received: from mail-ej1-f46.google.com (mail-ej1-f46.google.com [209.85.218.46]) by imf02.hostedemail.com (Postfix) with ESMTP id CA23980003 for ; Sun, 10 Sep 2023 04:36:14 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=NO3MUIKu; spf=pass (imf02.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.218.46 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1694320574; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=L8HEy6S0LdmzzzNFz4rEsIqVyXRa/Zk4t2KCxzu/Vho=; b=17GSUuQxGuQ+PUautUSV5EAkyVOJl/OPPEVCSirA9qV2EVRIpb37FBdVm6tZybf8wsylum 4kExEleNDM2GRHJbl6Qwc/29BnrKEqtgO8dWrkJvqnnfhoo7Idjy/nhqHtaLcYxCDm20gY 76Lm/i2DTHyzuzlz32VhPqsP4UYA0nU= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1694320575; a=rsa-sha256; cv=none; b=gufVBaE2NlBvgnvi9kcItI6Oz+y+J9yAoCcP4+cZz24gMYe+Bx7ZCmtze22dyUjq6waVSE UAd35VO6ybFEU8N2MFbf5aS+tgJv5Bbs4++AQHc33om91+iAZBSXGAGoymddpO2B9Vx9hC 0hlYOzRh9+P+TJR7jnSD3GqUuts/e8A= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=NO3MUIKu; spf=pass (imf02.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.218.46 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none Received: by mail-ej1-f46.google.com with SMTP id a640c23a62f3a-9aa0495f9cfso326829366b.1 for ; Sat, 09 Sep 2023 21:36:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; t=1694320573; x=1694925373; darn=kvack.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=L8HEy6S0LdmzzzNFz4rEsIqVyXRa/Zk4t2KCxzu/Vho=; b=NO3MUIKutv8oodOaf/tI4sUtHE205QqEWrvBp6cZLwPSwYwMN+FgeqRjLInEQ391nf zb+LNb5co0eQ92b9EfRI3g+tUQA3Yr9+cNbF8hmJQVt05ftNSncEUgfaBIJm/MSvT4wn DuqdfRinUEopVpK7oTieM8QIuJVlQqtJX15i8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694320573; x=1694925373; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=L8HEy6S0LdmzzzNFz4rEsIqVyXRa/Zk4t2KCxzu/Vho=; b=dim8B9texYlbjQjj9zjDPmSEQ8BFsEtmBvm7lyJYhq5gEzrMiNpliBA4QalaJcP0+U GytWXMA7uK9yTsr+gk1X7/6MnTnnJ+qLQ0MeoRM8FNNWr/oeUastGyC9NedIE1QJJN3P yhGrOKL1ZaOWdA0HFWX1Xtt8erMg0V+AHDS279CAuF4Adylcg00oWG6XRJY0n66gF87Z X7ifQV93lGnzRFZtIojUiYLTYsLV59fWwDodgprjTWGyhCCNKxjWwe2CKZhduX+yVucI VhehRcA0lr+9MJgSI75eKjZgD/F1tuhU2hhLwsB9znAnMfKWG0rKxREeJqE968HJUt6H 60bQ== X-Gm-Message-State: AOJu0YxY3seIYEbSo2vZicA5el7dShmq0ZpgH5khuFPlqO9+MGO/I483 xm2EqZrGKtO5X4zuZz4muAxpArLZ49SwyZNR6Hcgw2Ug X-Google-Smtp-Source: AGHT+IGc4iQEPYlu+O9dMB0plUcN1ziHFQQEgUT7kUFMf3ZCfVadr3nMvEAHwTrlKjVc2yVG2R2O1Q== X-Received: by 2002:a17:907:7202:b0:9a5:83f0:9bc5 with SMTP id dr2-20020a170907720200b009a583f09bc5mr13320777ejc.18.1694320572983; Sat, 09 Sep 2023 21:36:12 -0700 (PDT) Received: from mail-ej1-f43.google.com (mail-ej1-f43.google.com. [209.85.218.43]) by smtp.gmail.com with ESMTPSA id g10-20020a1709061c8a00b0099d9dee8108sm3300660ejh.149.2023.09.09.21.36.12 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 09 Sep 2023 21:36:12 -0700 (PDT) Received: by mail-ej1-f43.google.com with SMTP id a640c23a62f3a-9a9d6b98845so828387666b.0 for ; Sat, 09 Sep 2023 21:36:12 -0700 (PDT) X-Received: by 2002:a17:907:2713:b0:9a5:cc2b:50e5 with SMTP id w19-20020a170907271300b009a5cc2b50e5mr8297488ejk.32.1694320572001; Sat, 09 Sep 2023 21:36:12 -0700 (PDT) MIME-Version: 1.0 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> In-Reply-To: <87edj64rj1.fsf@oracle.com> From: Linus Torvalds Date: Sat, 9 Sep 2023 21:35:54 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2 7/9] sched: define TIF_ALLOW_RESCHED To: Ankur Arora Cc: 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, rostedt@goodmis.org, tglx@linutronix.de, jon.grimm@amd.com, bharata@amd.com, raghavendra.kt@amd.com, boris.ostrovsky@oracle.com, konrad.wilk@oracle.com Content-Type: text/plain; charset="UTF-8" X-Stat-Signature: cf4co3kh5ftfqawrzup88nrx7dbsihf8 X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: CA23980003 X-Rspam-User: X-HE-Tag: 1694320574-503785 X-HE-Meta: U2FsdGVkX19GuUd+9AUopawuJGrojZvVQxDPlMGfm/XyVxOIWsaofLYoE3uifhTqFQ+cjiLwk+KqHH+zgkNc2+MVnDgX4tP+NFFoKZjLBVnhHFWFahP/iDHnWgiUCOBSYsBHPxJ/G+CwLKIVCmu0P7K9NUtfWHMZHylnL6OmVEuInFuj0H8Unc5IdfsetkoIGzIRxF5KmDbuoFBhw9bsL3nhCbBBv1sHjhwDWHgKaxmP02bPMPCtfrHVczizmCAmzOuGj6D0I1ymvBlNAWMQyC82t3fj+dDoTZfBYh3syJ3j2xwRfGEFDdrq785qKCGHkFBAc6TteMjS5Rti18pZj+K8zlFL1HVf8JAbSN98q4hj32L1+TLvb+QpqJarBgEPdPPjt7mQBrA+DkpMG3ZiSnwN5j77fK6rFcTDIBHDrIj2nQhf2bBuJRe/Q7cPWJ6Xe2rlxw0QBx+5Tb1kTnU8HuPEViezpH5zvYYzcLju6Ia8vHXnjMFcdVuLW1feXN4F629WBJOKOyzJbhGbHWiDgkTp9EgUHaO05W9TrZCSHhUX3GnGZy7wKz2w9I9IEmkr2AAzkAXn6jNMzEV4tSA0tyakM1Gongo4mFuXV86UyKzChFzzBWJ5jaZbyEFtG25UAEu3bf1s3a2aMxqNoD16kRwDP6VDqfwa/tKWf6PKkomjZgLgagxOVdTAevBZiNTL8Likk6Ld4YH0esIh0b+4zCsEtEw1OuIiKFZX8Z53k+ZgYzpLbD0UxJmJLHcC2R5PS+FZAyUDfKC2kHeJCGCZFZ/P4aAA4XFya2ZzJZrPhN1HAdIzV3kO0pDihQ4CY2DYaiJXqqG+MGwcQfl+XlRZJIr7QntM8r4OpFx6i3bf8zbtROHLAO8eksA6OnWHLmfPgI5lASTI4L7NzxvnmhvW9v85aKB0IyHHH0YR3OocmfmetSTlcyDyQ6JknL1sSlDxlH7fU0L+HKBdzxHCprW peWDpve4 H++irF9u3dKEX7AlrxF4meqkF+lM/RGdzscpiLz73LnmmqlWkx3IZqYMPpfavt7IIccu4cB7YIn6DKHhD6SEWh9gVKbx38BqKhvywTVJ6EZHlpKlpwhMBe3sO7Ola9V2xE1o852bzJmeCt/Ga2b1wscokf7ssf15YWg0TliE8Wg3jDpW1wFtDrY1q2IlTd08vfu5S5jvcJb71+dzEW/+sTGasYSxkIpdq3dFP55nPbBjiaBxu4SD0tzmxeKEdRv4S4vjtayiqm+NQseDVjgI5BgasqywWiUiHLDXL+XFB4d/d3OK61b6j4tT+t2ugEDaZChV1JX0EYC2SblJ/q6DD4v8jwdMVddCXj9E+WEieWDx/ApVBDoXiPaZxoosY+UZKcgdRe4UlBf0hYDoyql/kg0v5qKPbfRE7IhUIaLyzDzlmflnZ3YlSFQV095mQQZ1VbvhlMP96KzSsCLq+u3XhgGdJxZdZf6NgLfLG9xJlMKC8tuwjx0kYAZQYB9GHXJvSzL5bnOAnVauieCie6EJ3AZ2ISYAFzNV7xdJRVPSJZhF2q5EgeSdG0blsyvVE0v6a4+pj 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 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). A page fault can *itself* say "feel free to preempt me", and that's one thing. But a page fault can also *interupt* something that said "feel free to preempt me", and that's a completely *different* thing. So I feel like the "tsk_thread_flag" was sadly completely the wrong place to add this bit to, and the wrong place to test it in. What we really want is "current kernel entry context". So the right thing to do would basically be to put it in the stack frame at kernel entry - whether that kernel entry was a system call (which is doing some big copy that should be preemptible without us having to add "cond_resched()" in places), or is a page fault (which will also do things like big page clearings for hugepages) And we don't have that, do we? We have "on_thread_stack()", which checks for "are we on the system call stack". But that doesn't work for page faults. PeterZ - I feel like I might be either very confused, or missing something You probably go "Duh, Linus, you're off on one of your crazy tangents, and none of this is relevant because..." Linus