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 F41C8CA0EC3 for ; Tue, 12 Sep 2023 03:27:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EA1D36B00B0; Mon, 11 Sep 2023 23:27:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E50DC6B00B9; Mon, 11 Sep 2023 23:27:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D18976B00BA; Mon, 11 Sep 2023 23:27:30 -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 BF20B6B00B0 for ; Mon, 11 Sep 2023 23:27:30 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 905121403A1 for ; Tue, 12 Sep 2023 03:27:30 +0000 (UTC) X-FDA: 81226510260.19.110F54D Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf29.hostedemail.com (Postfix) with ESMTP id 7385C120005 for ; Tue, 12 Sep 2023 03:27:28 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=W00Aax54; spf=none (imf29.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1694489249; a=rsa-sha256; cv=none; b=WHGGzYD5DfMae//p4Ifan1yWssgAdPsjuHN4t83DBsYamQhHO5VKw3qQLkVr6CWILbEHaL eAaahFLI2pnA6IAV4QadQdfnaIWl9SehVJwpIp8ChxU9GqITtB5r+hp4wZ7VeAwPBJSVem NBVAS+wV/ZlP71vWcb6fLwTC8eE4GJU= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=W00Aax54; spf=none (imf29.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1694489249; 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=UgGnk0nsO+8GtcffK/vuEOIa96+K8Xy5NhS6BCauH0g=; b=nljVEnfV2RLvT21KhhKx8OO2MdldHsNk8m4f8D/LR9uo0bLdeGh/AMTJvnMb2lQBGUb7uw JUpHNXeSabOFquBzMhuacT2dRpRIi8tuavWTDtRbeB/WTdwxhK44B/B8JtAtikMUbmVbGW nHukrhqeWj7ulfUfURbKJVfgcz1qL+M= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=UgGnk0nsO+8GtcffK/vuEOIa96+K8Xy5NhS6BCauH0g=; b=W00Aax54/nupH6+AnbpFTX1x6E 0fYuK85Yc9Fe2UirATONwOB73vUNW3NXPvmSKoExpnK7HZhbU4KDZ8ydCfDCd07Qa1ad0ZNrXQLky x6oER7s9M5bEPraxaLfkaNPbZAnhZrGgeNsIONaRyXXevdF3jgoKw9h8IevzvNd5JHwYSVZe6nHUk uwEYDSOOoWGmtjNNh+0LCoZGzVKoIbLske+fjZd4Vg89cSENwHq8l06dpx1tKwn7KxJhp8wGh6Cfg qCg6awZOt65Ass7iTpkQo0VDahA4PWH10QFNGCcEPHM70uJSO2AFEABZSd/951Nb1qV9BbGmHdSve cHwma6OA==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1qfu3W-004oIK-Lh; Tue, 12 Sep 2023 03:27:14 +0000 Date: Tue, 12 Sep 2023 04:27:14 +0100 From: Matthew Wilcox To: Linus Torvalds Cc: Steven Rostedt , 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, 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: 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 7385C120005 X-Stat-Signature: fq5x3er16rbkm947eraetiixjokp79x6 X-Rspam-User: X-HE-Tag: 1694489248-313630 X-HE-Meta: U2FsdGVkX19lkpRldCVWg73rbKiMK/NATz5eJU9ef/qHjg+l+Y2JlZBkHSYNBkwzE2O9iZNhFO03dsRNaIyuU755GktdQO2liRevxz26/Y/DWs/Kj6Nn7aOAJ0zPGGoG1N5YJKBVk4+I+pXrWwowPZsKeE3phVnIRgB2q4iHRwGs0RNVp/XqLyzxAWWcJ3tDKQQ6mcq6rglOb6VqCf3Gtelr9SKS07Xr5/sueuPrfUrxGh9siVahqr9GNCm52VBmNJbUlcQsIUc2vEuR9F0YxFFR1ox8Ul6lt3/5MgsmdjPYxDHzSfj7ozd3DIDqUYDlFx+nxYl4AOYWtRQplEV74vxR8KOV8aEFrtvbWku0MVu1lur5gxpoj/iLkShk4cWcElR4iLThfX1tOfDcidGv6s13UGj+9iueClts97hoD7jZ1EJQ98vI/KHbVLRxzi/SBsa5UjImEJ+V/UBxE/9/79+8gkfihANKSCazXWKxRts/s3Kb93l2MWEiQ65uRoh4fdmXcS3FVPOR61catik0MsUK6h89sLuf4bPK+BBLls2LX2PEvB7ZgsGtM/IvDuypEDyO/1ACnHkab1tUrPXJHUIa7HaW0EInIyY8jZa2A+SfimfBHQQDqSzRtduz6Do8iYUfXWGoqOctGOVsU59b7dD8/bjLNowG0P+mejffj4FOR4bqc7fml2aP9CfSk3gmLZKQSoy4oOeVUCvMKOvdg3QWjVFGjX7KXHISh5nQ+ruwS9M3ngNOnU5oZ7DbFy8vNfLFXT0Z6hDWaHF/sT42l9xAj5d9/DNF6XDjlr6ggnMtqc1uKUnXCRSQbzijbe+q0YMoe6B/0UYmxMTeiX1BfpyAVrdDwSAKjFx2MAv7bDQ8P3Ey8jbp/TQKeEJ62ny1RDCnQXWtWfYq38O80RWSBRxPwiygp1Al/zzeNvq/W/t8pBXK2c0PCKSuWuMqA1PS8alrSEox2HeAQftNy49 +wxxqYCX LW2P327Hqq80ZSh2shA2QpOr0jRhcfdJUa7eEvApz9IDmOY+cVyNWkyFsXfP9xU/M46J1HJkWQdE6265aA3lNdp8GFsT0AjGU3vtKQow3mQTYUJCnKdbE7IBegWVAuJkNVe8XHqbVhZGN8H2gaVhTdtJ7TwHv1SbUb5z1mvnUdGo6y/hCU7Yj3KPXdw== 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, Sep 11, 2023 at 01:50:53PM -0700, Linus Torvalds wrote: > 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(). Ah, um. If you take a look in fs/iomap/buffered-io.c, you'll see ... iomap_write_iter: size_t chunk = PAGE_SIZE << MAX_PAGECACHE_ORDER; struct folio *folio; bytes = min(chunk - offset, iov_iter_count(i)); if (unlikely(fault_in_iov_iter_readable(i, bytes) == bytes)) { copied = copy_folio_from_iter_atomic(folio, offset, bytes, i); So we do still cond_resched(), but we might go up to PMD_SIZE between calls. This is new code in 6.6 so it hasn't seen use by too many users yet, but it's certainly bigger than the 16 pages used by copy_chunked_from_user(). I honestly hadn't thought about preemption latency.