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 406C6EE3F01 for ; Mon, 11 Sep 2023 20:51:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AB3FA6B02FF; Mon, 11 Sep 2023 16:51:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A3CD76B0300; Mon, 11 Sep 2023 16:51:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8DCCE6B0301; Mon, 11 Sep 2023 16:51:16 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 7BB166B02FF for ; Mon, 11 Sep 2023 16:51:16 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 4D6F7120BC9 for ; Mon, 11 Sep 2023 20:51:16 +0000 (UTC) X-FDA: 81225511752.27.33EE0FE Received: from mail-lj1-f174.google.com (mail-lj1-f174.google.com [209.85.208.174]) by imf11.hostedemail.com (Postfix) with ESMTP id 5280740015 for ; Mon, 11 Sep 2023 20:51:14 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b="PV0U/7uS"; spf=pass (imf11.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.208.174 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=1694465474; 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=pIPOzP6LAN+yL7kKEyuXNnJg8Y+1WcCPbZvSjEDcprA=; b=DwDKJfWu2udx3mwBiCKOBbJ5VosyHgZIDo3s2Zo/1cMwPD+5xLMmrpQGHKs8114LbtK298 H1DxF/HQX+OtY3njjXhqNW/7qKVmuDXVqjxyibfwHEOWEUhKe8YPZ4boE/RJDnt5q9zPOi 9ERoK0vjc+nKTf4uZY8C0tBkar34Xzc= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1694465474; a=rsa-sha256; cv=none; b=y8O2Bt/iOhn1nj2XBI2a/lNN32z/VtLl8MzxsM3MY/5vyWYxXOBZtE0bSB61SA2My07FG0 ouvwxza8V4RJyVUioUIQiiaZeczCcWVXaDbkaCKH0NjT7QEIWkKzlfzkAevANEfkc9yrwF n3KpKiXmtuuodtGir/Nd+VElhHmdqzk= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b="PV0U/7uS"; spf=pass (imf11.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.208.174 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none Received: by mail-lj1-f174.google.com with SMTP id 38308e7fff4ca-2bcb0b973a5so79656461fa.3 for ; Mon, 11 Sep 2023 13:51:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; t=1694465472; x=1695070272; 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=pIPOzP6LAN+yL7kKEyuXNnJg8Y+1WcCPbZvSjEDcprA=; b=PV0U/7uSBbL9UpLfZhHfq5+AIAjziOYFzIG7eQVeeSscoUNkqURofhTq1AarqzLXtp 2DbiA7Qr/8rQFrPAf8gAaRG20wlMtn9mdWUBLgezpRLS980O5wI81xHuuprDu1cJ/QNG Xfdzmq3Die50uM6WjaDRTCYkG9xtwLxjnoZJg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694465472; x=1695070272; 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=pIPOzP6LAN+yL7kKEyuXNnJg8Y+1WcCPbZvSjEDcprA=; b=OhEK9vphdIzv0jfdOdgDFJR6/ItCv2Z3Xmp0BHDhvTyc9enUVBTvG2MwuJLbDBXPTl EAUEKvwF+GTKDH2NUGywhghhhfJATyF/Ra5pGk6XhDcBS85Bx02IYsgJYqmeVnnDalsr iUvH9Je2CMZvLQaGGHxtmvJSX5SLSMPKaoLTizmEpaEmRjfaZtFZTE6DHTES2zA+waxB tlup/0OP2FUM3tXKPrJcYIaiYKtfF6KdcYdQzIXwPrAvzcCRr/sV0USsbqDjCJ7IftBG vujxXxjKOTkXeQ2vHTwpk2WpFGgBKDjY02fPD5DfSLXXKdKvkEtqXvMJtfLkCFZmgUuC y7LQ== X-Gm-Message-State: AOJu0YxNla7MZ3f8AkOBEoxT5OyqJO7CHNyfrLnVMzQ3WogAMZun27jy c9RWDWU4lyxI4VqL8yFTHmN3Sja1FBHt8yzGz2JVmhiJ X-Google-Smtp-Source: AGHT+IHkq2icRWKxxXKyv0NLt5MLbtdUYdgYC0owAvD4AmI+x4v2MSCObnv0dDfkTODp7+gF+Ctlpg== X-Received: by 2002:a2e:b2d4:0:b0:2b6:fa3f:9230 with SMTP id 20-20020a2eb2d4000000b002b6fa3f9230mr8463243ljz.46.1694465472141; Mon, 11 Sep 2023 13:51:12 -0700 (PDT) Received: from mail-lj1-f175.google.com (mail-lj1-f175.google.com. [209.85.208.175]) by smtp.gmail.com with ESMTPSA id h4-20020a2e9ec4000000b002ba7ae1f52asm1679357ljk.0.2023.09.11.13.51.10 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 11 Sep 2023 13:51:11 -0700 (PDT) Received: by mail-lj1-f175.google.com with SMTP id 38308e7fff4ca-2bcbfb3705dso79964081fa.1 for ; Mon, 11 Sep 2023 13:51:10 -0700 (PDT) X-Received: by 2002:a2e:b2d4:0:b0:2b6:fa3f:9230 with SMTP id 20-20020a2eb2d4000000b002b6fa3f9230mr8463202ljz.46.1694465470349; Mon, 11 Sep 2023 13:51:10 -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> <20230911124856.453fba22@gandalf.local.home> In-Reply-To: <20230911124856.453fba22@gandalf.local.home> From: Linus Torvalds Date: Mon, 11 Sep 2023 13:50:53 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2 7/9] sched: define TIF_ALLOW_RESCHED To: Steven Rostedt 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 Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 5280740015 X-Rspam-User: X-Stat-Signature: 5n6utw5xszsu3exqnhbcdnwa4n6aqwta X-Rspamd-Server: rspam03 X-HE-Tag: 1694465474-795032 X-HE-Meta: U2FsdGVkX19PTLhbbyqUPXMfRInZxpOv3RaIxkOTcyvizOnNUm/0iY5ftDKTIfNs6FnjM0dwzy0lsBbTIgBRGJ7/aW3QWr8ltmFWHTmAogvlFMQknhTQdJAUvHxi5owZ4PRHDHF+Lipe97ksENhgaP7gw2JhiOlsp4oEqH67XMiqMNNnsOLk+BkjRNF5zosFnDfpAdYxYOXESFGv3Mx/FcV4rrzU+mNAHC1rzvTVqhIEorZcSz/9m7HkLIkuf726dHzxO2pZsi9cWpmKM/++j9y7uVfxrO/1vm0/bfYo9nHnzJ+0FaNxvVEekIIWEz2fVK0nGidLlrIc/ARw6fQkLGqzgLmCzGn++hqsrdYM5dy85AE2oWkUnNdTS1SNyxKGHu8XKIN4n9KSQ1LccdPvLMtUrBp76Zu2zPgiK5IoZiB4LhFXl2ZSQVp0e6Sue3CC60pNp9fNd+GBKaJVC8xuFRIv1BCHRfW2Infv4efGLsQDFhaUe59ELFPbE36FN4c90x4E7O9k11bkHZf5qgRkna69Kn9m9BKnVjwoMzHFdX462hHlokqkaTpYC2K8n5o64BAW4GjiBAUr++05fRXley3b+i1sfIAUJmDpTbUczoMvV1KV6hUZH7q+OrZn2W9CXGD94YFJ1AqP/bLvtpvP54c7oMMKu9oU8TiIIwL4g0UxfeCYc1QBfaZGvPZKnOgulh/SEaJdkv3P72stccN4bscrZYeA74k2VBGgm6DqBWtb8E5NgdZWBVKKhSeeoAtMD8z61ZXsAAtIKBvBxJfNz1+BgvUQsldBfINce+Hd4+FZWSkolQtD3LZAklZrSEy3ynYShm5bOp+aHcEa0XFaoiqmvW3tGK23XWNNkXMXxiIkfYQyydWKqmbI9xSNDO7hwO5Khf2DvqFrvn5dc5hpg2mxTnXILkQ5PpnXUR1lNCgjFqDMmvKPcHP2kwXTP1GPVpwc0mGB09so5LVxTW1 NBs2fBLT CYe7495ImNiDLuNdu5qQdcNTkotkePaoiTiUI3enVhZ1O1txEskC4yrkSav37EEjLSGVqPCIZFclFuAP65ygAdGKAc0ssbXY9JY8fzISTjP5ZzjMGbKtES6CXh/UhxwfZP7st3Fg/LDCy/XUOzSwTTqJb4t253Knx88U5gpJ1Q/DxyOLJjvj4xCv3V30LkfBZU7Gsy3DOAaYuXT2lZRBQ8uTcBAXRC27UBUTuwbiDnC7rU5iT0PYxdjuiHQN3bz+wtK3fKa5LOoh7fjtijzZgVulfKQD6TGo3Wx5I3hRYRiebtjkEzdPHYx68/gCdrMzLSsAHWYzn12oRqOlGeK4Mpt4zAy+lblXbOK77cBfGvS3dCrER7LJTd6Yq/M6QM3QsCT9xHRhbAD2f5UvQnqbRl0HBa1hCVthcMKmiSU8bZ7BsRmZnttrGpgmUhWgf+uucSf7DSoSjrpPRAN2H24GBmulldW5Nv+EHnU65HYdOt1NuiAVRmdcqw2L3GqqHyGigiASJbA2r5dhV+IIqD+8lguCNrssoUGhaQE1/EmPs4GpsHFMlXWUZgarzmeEgggF1Uox+DhjbZAhw7BlIe2P/6s1S/XtN1IArs0F8qBrb8LRd5/w= 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 Mon, 11 Sept 2023 at 09:48, Steven Rostedt wrote: > > I wonder if we should make it a rule to not allow page faults when > RESCHED_ALLOW is set? I really think that user copies might actually be one of the prime targets. Right now we special-case big user copes - see for example copy_chunked_from_user(). But that's an example of exactly the problem this code has - we literally make more complex - and objectively *WORSE* code just to deal with "I want this to be interruptible". So yes, we could limit RESCHED_ALLOW to not allow page faults, but big user copies literally are one of the worst problems. Another example of this this is just plain read/write. It's not a problem in practice right now, because large pages are effectively never used. But just imagine what happens once filemap_read() actually does big folios? Do you really want this code: copied = copy_folio_to_iter(folio, offset, bytes, iter); to forever use the artificial chunking it does now? And yes, right now it will still do things in one-page chunks in copy_page_to_iter(). It doesn't even have cond_resched() - it's currently in the caller, in filemap_read(). But just think about possible futures. Now, one option really is to do what I think PeterZ kind of alluded to - start deprecating PREEMPT_VOLUNTARY and PREEMPT_NONE entirely. Except we've actually been *adding* to this whole mess, rather than removing it. So we have actively *expanded* on that preemption choice with PREEMPT_DYNAMIC. That's actually reasonably recent, implying that distros really want to still have the option. And it seems like it's actually server people who want the "no preemption" (and presumably avoid all the preempt count stuff entirely - it's not necessarily the *preemption* that is the cost, it's the incessant preempt count updates) Linus