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 CB7DEC71153 for ; Sun, 10 Sep 2023 18:32:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BB6CD6B0145; Sun, 10 Sep 2023 14:32:55 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B676B6B0146; Sun, 10 Sep 2023 14:32:55 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A2E5C6B0147; Sun, 10 Sep 2023 14:32:55 -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 9373F6B0145 for ; Sun, 10 Sep 2023 14:32:55 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 5FA461CA1D5 for ; Sun, 10 Sep 2023 18:32:55 +0000 (UTC) X-FDA: 81221534310.10.0BBB845 Received: from mail-lj1-f179.google.com (mail-lj1-f179.google.com [209.85.208.179]) by imf21.hostedemail.com (Postfix) with ESMTP id 424CB1C0014 for ; Sun, 10 Sep 2023 18:32:52 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=W0hx0AR9; spf=pass (imf21.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.208.179 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=1694370773; 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=FMlIV4MTu5DEIKaM74ShUQPpObFts+yGqhlBt2NCN8M=; b=ZmwXiSPu/Jo5LRPLALmMeeYilHiX8zZG0sd/20btozr4XV6kbry18+GCs8QcGB1iadXNa7 YRcL7rFTz0pBSSLULJM15IUVv98Mu/ftYbPy4cK85FMjABgfkdTkTK/I35N8GiFGwYNm7v 3tTA/CwGVYCagUajkh/UtreSSoy3MRI= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1694370773; a=rsa-sha256; cv=none; b=WEpnUtsWC6J/9GNkvzqHIyv+Sf7ohgKVQJk51laK8nv2ZiPXkjLS6i9DDvqjmeQwxUJuAI LKs8YXPH+f7RE/Y7F9y6citALUk4SYW2nySvn5aWg3eDpmuKpLIyhhRC7+AbtXatwz6UAz UQbULbBKlC+IYivqvjAiZBahq0X/SoU= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=W0hx0AR9; spf=pass (imf21.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.208.179 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none Received: by mail-lj1-f179.google.com with SMTP id 38308e7fff4ca-2bcbfb3705dso60303301fa.1 for ; Sun, 10 Sep 2023 11:32:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; t=1694370771; x=1694975571; 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=FMlIV4MTu5DEIKaM74ShUQPpObFts+yGqhlBt2NCN8M=; b=W0hx0AR9Xq+IT7Rlhxi8wD7dHivg8nfo/eEOUcNIgPwj/6j2AfpAyuEP17qOHfaKA4 NezzZuvRJWRm+3jeKN+aM7zjbUFg06ei2JsA/hQHCg8jXil9l0HsgZtrEzEmSBTnxrgA N8C74q2UZAQZU/unR8Ie1jbCDIb0KGXOMPhGc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694370771; x=1694975571; 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=FMlIV4MTu5DEIKaM74ShUQPpObFts+yGqhlBt2NCN8M=; b=DC+Ox0+bGVhVlOsjs+k/Y4q+FfToJ7iC2bH29+oab0Z+fvrgOmWDxDGhqbyQIV4yxV YExZnPYSZP6wqrJceVsxhLlZI/XecsBWzOwAjk4O+Y3d3dnY9Gl2ZCUV6Uhp3E9d9PR5 UL2IzHzSMHo3fNjTQhUDUXA3WjZbde2w1CXr82lPC/CixSxVfAaJ/9GJEEhIygSqXjkm X+Vur36dCQ8XM4VDIgMiCElISWfWWhkzrdn5Qg8IbGtRgvqOhnl2AifMc3KdO9n+n/Hw i1aJQZayBZKGMHjjFhedui5LG4fajjY/+Mfp8mSE9BdKjY7yLtQX3iN11dAUkk5P1eSI laQg== X-Gm-Message-State: AOJu0Yz3CpxGQW29nEpg8ZWP2TxpLzqXaY9lgwJLw8X9uiQF2du3Q81n iScPddPTeORjidDN9y0Tl7R2Do5xGxW1qHHvEw7x4rHr X-Google-Smtp-Source: AGHT+IGT0opND6lfJfibnwzFtoxkfHUatqY+65hYWugYTacOLXT85/BT4reeaMruSHMMkwQE8uHDeg== X-Received: by 2002:a05:651c:b94:b0:2bc:e856:6208 with SMTP id bg20-20020a05651c0b9400b002bce8566208mr5866298ljb.33.1694370771249; Sun, 10 Sep 2023 11:32:51 -0700 (PDT) Received: from mail-ej1-f50.google.com (mail-ej1-f50.google.com. [209.85.218.50]) by smtp.gmail.com with ESMTPSA id s22-20020a1709064d9600b00988b8ff849csm4135633eju.108.2023.09.10.11.32.50 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 10 Sep 2023 11:32:50 -0700 (PDT) Received: by mail-ej1-f50.google.com with SMTP id a640c23a62f3a-9a65f9147ccso465698366b.1 for ; Sun, 10 Sep 2023 11:32:50 -0700 (PDT) X-Received: by 2002:a17:907:7791:b0:9a9:e41c:bcb6 with SMTP id ky17-20020a170907779100b009a9e41cbcb6mr6664791ejc.28.1694370769787; Sun, 10 Sep 2023 11:32:49 -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> <87zg1u1h5t.fsf@oracle.com> In-Reply-To: <87zg1u1h5t.fsf@oracle.com> From: Linus Torvalds Date: Sun, 10 Sep 2023 11:32:32 -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-Rspamd-Queue-Id: 424CB1C0014 X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: cpkxncbq6hru8uytr5htni9s3981cqqk X-HE-Tag: 1694370772-457410 X-HE-Meta: U2FsdGVkX1+eQaEo5ncHHFiat+/JJ/ZTwawol9EEL6gVX9uQ+84paWqSbD04Puiiajn+d9Zm2rZw/wCx0jszWfrU2qBk3sEgtX8ihTgsYtG+mc7ymo88YPJcpvza8OZkm/z6SuG1ZuGftZZdbfbPPt66Hz/9pIsYxl8m2q48z0sJUfAi0ptBp0/xfizDVjA8DAmgnJKmsid+sj9GRjYnt2yQkhuTB+hGcaRYNhPc7r6YcvzDwEiczCpekT/uvl0tYUocVFTLTvoUxQHfcjTeIqbIJtm25VzNrlL9bFa3yLivUXZzzdgUYyjyKTOwfxO7Ub3Z1rzT6gltn3Jdy+fv2vV30StOW36HPt09NHI3+HiZRlYH0G3MfIZuQULi302aXVQO67bB8mbBRofx4VwfFO3jEIb+7Xd8GkV0qWZ+jl+dQFm3d2uRLBGav1iXZLTEfO3rTCgXIs5SFXiuNKKTwzR9PsdZwlScgPcEjnQIn4Psu36jKprraKmutkqW2lSq5FWa0hdCZC+2nEdidZJPHB+Eo7xTxkmVcBP8OBb7wzallFv1o3kV3qt2fdGbbdPQxE/a1ZAonSVOVOD2cKe4WCaeH/Uu7QoSnWjXsydVpr5+612kMGNA6JCF6AXrKJNFe8hDp5OJpt+yjR16iOMTSwuTJkSfmLeU353vy42hfprBa97Lc1bOKX0Gjn6HgwoT3ss6XyN9PcrOadepJC9t73HKNQ2tPBIy5OisavSdsMwS/BNkVGcF6U6/NVoZGNbl7nrJdNrzaFeOkkIsKBURVgVCl0t1tjkoWnsasyDgCxd219uG6cHXzTIfANA4dOQ9/uha8/TzJAmSSB8kAMNqn6z500cda7OnnFcQ0xaJoyYJrwdVbS4BrtZcRKJVpT1gznuwJt1k+L+h8m8L0iATZcxexv1MdDuORqBh2MOzFbVfFBngJCClWMvVTh/oN5Mx8ekYnmgLg0NaKHIhUbw bwLUqQof 2kL4sxGNynC0kIVNREe1Y6B67JoS3V+GjSl7PqeT+uGTNFqjrmKknuxGja5uCLI/TSFrG1HfF7M7eyV8R+/n16iPH+502DNxjfqrwM/YjL1DeM0+Nph4PRLtD12UXWk003yZHwYGSlf0IZ/1t03BNzOzPcSYJP4lvVX56AyOs7DvavVUvYi4GQiYWQCkMOqEY707mh0qnbM144hs5dr3sq8oYpE8CJqEOJ43H5RmGkaByWlLMoYsShzfw8s3E+xHtWSY7OSAWNVxZzYtL57CgHvWk8TQk5BrJAEcfAblH6usRUOyFotdX6cGmgmzHCCyLCYPi9PKCcH4WgfsttvpC3o88Lxy0g+7ZQzad1lYso7bpV5+2cixmNuzAvpLxVbw5o11CIS4v3ygBOHQOQkl1IzWG8jYuaECREu+BuII9Tj401BBak1jPYhlCa52qr+K9YXKOhci/Apc4y3o27Rty5Jjbs/GAJQ+W0wZtlMpGQv6AP4Z73hZAkvBSq8vNS4zZ8HxG3EcvfBIns8im8iwRJqdjFfXLua5WLutkrxyerZ3JClMZ+WkzYuwkHbqvIWMaccDl 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 Sun, 10 Sept 2023 at 03:01, Ankur Arora wrote: > > Seems to me that associating an allow_resched flag with the stack also > has similar issue. Couldn't the context level change while we are on the > same stack? On x86-64 no, but in other situations yes. > I guess the problem is that allow_resched()/disallow_resched() really > need to demarcate a section of code having some property, but instead > set up state that has much wider scope. > > Maybe code that allows resched can be in a new .section ".text.resched" > or whatever, and we could use something like this as a check: Yes. I'm starting to think that that the only sane solution is to limit cases that can do this a lot, and the "instruciton pointer region" approach would certainly work. At the same time I really hate that, because I was hoping we'd be able to use this to not have so many of those annoying and random "cond_resched()" calls. I literally merged another batch of "random stupid crap" an hour ago: commit 3d7d72a34e05 ("x86/sgx: Break up long non-preemptible delays in sgx_vepc_release()") literally just adds manual 'cond_resched()' calls in random places. I was hoping that we'd have some generic way to deal with this where we could just say "this thing is reschedulable", and get rid of - or at least not increasingly add to - the cond_resched() mess. Of course, that was probably always unrealistic, and those random cond_resched() calls we just added probably couldn't just be replaced by "you can reschedule me" simply because the functions quite possibly end up taking some lock hidden in one of the xa_xyz() functions. For the _particular_ case of "give me a preemptible big memory copy / clear", the section model seems fine. It's just that we do have quite a bit of code where we can end up with long loops that want that cond_resched() too that I was hoping we'd _also_ be able to solve. Linus