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 052BBC8302D for ; Mon, 30 Jun 2025 10:57:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9DFE76B009F; Mon, 30 Jun 2025 06:57:20 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9B7666B00AC; Mon, 30 Jun 2025 06:57:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8F4926B00AD; Mon, 30 Jun 2025 06:57:20 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 7FC436B009F for ; Mon, 30 Jun 2025 06:57:20 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 2088E59019 for ; Mon, 30 Jun 2025 10:57:20 +0000 (UTC) X-FDA: 83611765440.22.C9464D1 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf18.hostedemail.com (Postfix) with ESMTP id 316771C0011 for ; Mon, 30 Jun 2025 10:57:17 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf18.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1751281038; a=rsa-sha256; cv=none; b=8m5Nmr18y+nhs+yn4nyeYkC8ay9DrOXqrmj7RM6mSU/dDTBCnt+0lvx1WW/+WKuhBD1aEB DnxJS8TYA+kx32JXg2md3JKlKGanW2ip5CfDky5Mdwr8GyBf6qH3HJ866/L60Xo6ZwLJag kN85q6+c1tSzyEsMIE32P8O/38sLH24= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf18.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1751281038; 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=eehi+p//JAKQXNYQIbE0ThOcXj2hfEN6NJ/MHlY6vI0=; b=1rqSahFPBR068jB+yerfUqRvUb5NKuzP5Uk5X4Be3tQM3wU1fRyJ3G2bngDT2RlsTORs5d OsEYJOlrEbrBmp3qxLW6ubwXQJH2EeDfae+vtEEQiQFWgmlF1r+Rv9VGwf9qdd+XIoeEi4 QXqh23EgZhKxB3mrO4WiJH06XsRKIe4= Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 3B2AB1D34; Mon, 30 Jun 2025 03:57:01 -0700 (PDT) Received: from [10.1.34.165] (XHFQ2J9959.cambridge.arm.com [10.1.34.165]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 5D7723F6A8; Mon, 30 Jun 2025 03:57:13 -0700 (PDT) Message-ID: <2ca5cbb3-9795-49ef-ae53-11c3143edee1@arm.com> Date: Mon, 30 Jun 2025 11:57:11 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 1/4] mm: convert FPB_IGNORE_* into FPB_HONOR_* Content-Language: en-GB To: David Hildenbrand , Dev Jain , linux-kernel@vger.kernel.org Cc: linux-mm@kvack.org, Andrew Morton , "Liam R. Howlett" , Lorenzo Stoakes , Vlastimil Babka , Jann Horn , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Zi Yan , Matthew Brost , Joshua Hahn , Rakie Kim , Byungchul Park , Gregory Price , Ying Huang , Alistair Popple , Pedro Falcato , Rik van Riel , Harry Yoo References: <20250627115510.3273675-1-david@redhat.com> <20250627115510.3273675-2-david@redhat.com> <5c3428c6-25be-4a94-811a-6bb6718f6c58@arm.com> <5375208d-2c11-4579-a303-e8416ab07159@arm.com> <79525362-2377-441b-8575-d2307bd77f26@arm.com> <8993dbc9-6c9a-4ac7-8c04-813851eba938@redhat.com> From: Ryan Roberts In-Reply-To: <8993dbc9-6c9a-4ac7-8c04-813851eba938@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 316771C0011 X-Stat-Signature: ebrdiga7r3nrhtcr9aahcqutmhqsiftq X-Rspam-User: X-HE-Tag: 1751281037-572134 X-HE-Meta: U2FsdGVkX19RJS6SpO6x9kYxMyadXmaezonrnAVKCKG564DoOliQQ7+68WQ3oID64xCAEWr6dwNB0ljeOBFU0TzW81YVUbQuTTrAhtL2gcyAcS0PHQkBhf9+3kCGjRL2KeDc1/+ZOQ5EAfoeL9GRcpASm0KOVGaupZQ6A452EGEqhG8uz1y3Fp+r1EEQq144l03FY+0Nc5Ow+CwVnS2qOcW8QoJiCVxbwo09VIrylBTnELGN58QkYX2bnFm2YhfuLrTUg1qP7OxZ/ReQE+Ne+1qztHFFAWBy8v/V64HdymrvOIJslyx6LhP7P9kNuidlebygujgJjxrjTV5s5gPhi118+90Veki7/X4RKCZuB2Lq3oR+p6yptWJYkH7BdrD+xbda7IurGrOCeoiB/iRt/ik8ufYgO028X0nbNttDKxvXjOJi6oiycgDSGT7AgDi/2zsu0dtG2qzCOXAIlWm00RRjtO5Ec0v66k6ZlphKQy9cI3DDrMKeHIB6QEfgRUHCj2ETOI5WuSuHdQJsDpOaBSE1TucTLaFIiRWImqp77tmDKIpHaGOTQqmg+yaZ0dXLZuODKUU4WwTU6ncr2EPTI1jc13IMeFU+fxL8WAZJkmK10UGCncyEnPqz7QaTWExkzmkUXsX0KH9RBJt+3WjWmJMaTndgta4uRl5oAN8lQmJXT0qdPeMNPhpPGi3WPI4g8yngcsglFv+VnQx6CQ8Sbhb7OxMipD46mrZSeZilayUhH6Ju69hIE7BwCJIRPY3eUaHAcCxLf3zvUZ4pXOQW7IexR/8b8dgrmY0NUb4ujP/EHkEzPxGP01JJL77yl8SrYgQNi6wb0OV9PqOqLHLlg0kiwAmK+B2C/MKyo9OQ4UYnrzBfpwVMiB8P5HscYFpFRytkg9aySkOcirCz4Zf+BkBB7E+kXr8RXClMivJdellAa1/8/cRBsyRfNdhHHg6aZ/NQnUU9h3Wqbn6cxPN qGmawri1 4jBVd0561uPY2usy2EI0CzfSWkTfncAKVAH9pAKcSBUz2yTOcY65431sV52R4zHQG8Bt+rJRgN795Nlku8b2h3w9QN4dGIOF/mTfx+6ytwjgO4pk114MzKVv3m/wKE+fGFgdmPPCFkgsM0dD1ZMISNYvxG+Wu8KCZ6aQoG4cqK3fRlvqUcbnA9/p8yqvgNaRffDBETePUcKslTQfyUzLyNzwquNwx3+IeqAx9C4nyoPv/WF5RebpqMXLcLQ== 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: List-Subscribe: List-Unsubscribe: On 30/06/2025 10:24, David Hildenbrand wrote: > On 30.06.25 11:18, Ryan Roberts wrote: >> On 30/06/2025 10:08, David Hildenbrand wrote: >>> On 30.06.25 11:04, Ryan Roberts wrote: >>>> On 30/06/2025 04:34, Dev Jain wrote: >>>>> >>>>> On 29/06/25 2:30 am, David Hildenbrand wrote: >>>>>> On 28.06.25 05:37, Dev Jain wrote: >>>>>>> >>>>>>> On 27/06/25 5:25 pm, David Hildenbrand wrote: >>>>>>>> Honoring these PTE bits is the exception, so let's invert the meaning. >>>>>>>> >>>>>>>> With this change, most callers don't have to pass any flags. >>>>>>>> >>>>>>>> No functional change intended. >>>>>>> >>>>>>> FWIW I had proposed this kind of change earlier to Ryan (CCed) and >>>>>>> he pointed out: "Doesn't that argument apply in reverse if you want >>>>>>> to ignore something new in future? >>>>>>> >>>>>>> By default we are comparing all the bits in the pte when determining the >>>>>>> batch. >>>>>>> The flags request to ignore certain bits. >>>>>> >>>>>> That statement is not true: as default we ignore the write and young bit. And >>>>>> we don't have flags for that ;) >>>>>> >>>>>> Now we also ignore the dirty and soft-dity bit as default, unless told not to >>>>>> do that by one very specific caller. >>>>>> >>>>>>> If we want to ignore extra bits in >>>>>>> future, we add new flags and the existing callers don't need to be updated. >>>>>> >>>>>> What stops you from using FPB_IGNORE_* for something else in the future? >>>>>> >>>>>> As a side note, there are not that many relevant PTE bits to worry about in >>>>>> the near future ;) >>>>>> >>>>>> I mean, uffd-wp, sure, ... and before we add a FPB_HONOR_UFFD_WP to all users >>>>>> to be safe (and changing the default to ignore), you could add a >>>>>> FPB_IGNORE_UFFD_WP first, to then check who really can tolerate just ignoring >>>>>> it (most of them, I assume). >>>>> I agree. >>>> >>>> Meh. Personally I think if you start mixing HONOR and IGNORE flags, it becomes >>>> very confusing to work out what is being checked for and what is not. I >>>> stand by >>>> my original view. But yeah, writable and young confuse it a bit... How about >>>> generalizing by explicitly requiring IGNORE flags for write and young, then >>>> also >>>> create a flags macro for the common case? >>>> >>>> #define FPB_IGNORE_COMMON (FPB_IGNORE_WRITE | FPB_IGNORE_YOUNG |    \ >>>>                 FPB_IGNORE_DIRTY | FPB_IGNORE_SOFT_DIRTY) >>>> >>>> It's not a hill I'm going to die on though... >>> >>> How about we make this function simpler, not more complicated? ;) >> >> I think here we both have different views of what is simpler... You are trying >> to optimize for the callers writing less code. I'm trying to optimize for the >> reader to be able to easily determine what the function will do for a given >> caller. > > See patch number #3: I want the default function -- folio_pte_batch() -- to not > have any flags at all. > > And I don't want to achieve that by internally using flags when calling > folio_pte_batch_ext(). > > If you don't specify flags (folio_pte_batch()), behave just as if calling > folio_pte_batch_ext() without flags. Anything else would be more confusing IMHO. OK, sorry I don't have the context of your actual series... I was just trying to defend what my quote that Dev sent. I'll go take a look at your series. > > I agree that mixing HONOR and IGNORE is not a good idea. But then, it's really > only uffd-wp that still could be batched, and likely we want it to be the > default, and respect/honor/whatever instead in the cases where we really have to. > > (If we really want to go down that path and batch it :) ) FWIW, I think we will need to honor the write bit for Dev's mprotect series (I just sent review comments against his v4). So if you want most callers to just call folio_pte_batch() and that will ignore the write bit, then I guess folio_pte_batch_ext() will have to accept a FPB_HONOR_WRITE bit? Which I guess aligns with what you are doing here to make all the flags HONOR.