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 8FD29C7EE39 for ; Mon, 30 Jun 2025 09:04:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EFDC66B009E; Mon, 30 Jun 2025 05:04:22 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id ED4F26B009F; Mon, 30 Jun 2025 05:04:22 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E11AE6B00A0; Mon, 30 Jun 2025 05:04:22 -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 CD3566B009E for ; Mon, 30 Jun 2025 05:04:22 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id A7725140400 for ; Mon, 30 Jun 2025 09:04:21 +0000 (UTC) X-FDA: 83611480722.21.DC9587D Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf01.hostedemail.com (Postfix) with ESMTP id BA91E40004 for ; Mon, 30 Jun 2025 09:04:19 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=none; spf=pass (imf01.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com; dmarc=pass (policy=none) header.from=arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1751274259; 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=CyXHZot48o+SFIXSTAE789LOEwJYLFr8RuyLjX8x9Ic=; b=DPLdqH6sbYOA8NgZxjHU1oHyxj9M4JyJJcffYEWuvvZZDVewNQIE/FyUnGJC5SHhr8a7mp AG9YzQlCXghODyZkVjFQNgD49OKEaKkKdBeaQrDmdX7bYpv9PE0yT6gU1iZT5i1h/JnZ0q 04prX3AYzs/ILUAspgwc/GOJtriheVY= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=none; spf=pass (imf01.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com; dmarc=pass (policy=none) header.from=arm.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1751274259; a=rsa-sha256; cv=none; b=GP1uuvitbbpxDMHcH4Q3Fi6o09W57RElhsL5yoQIQdbKwziWB44MYGEGqjja3pFU3Ahu0d y6jIUgXlQIQrSZCnrd+PbJVFneRjILIA3zNQOkn6/ZOBXnBpeCsAkCPrMeMTufK2IGPruU puzSrycvxeck89jNWNrRYNJUKRd9Mbs= 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 780871D34; Mon, 30 Jun 2025 02:04:02 -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 A561F3F6A8; Mon, 30 Jun 2025 02:04:14 -0700 (PDT) Message-ID: Date: Mon, 30 Jun 2025 10:04:12 +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: Dev Jain , David Hildenbrand , 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> From: Ryan Roberts In-Reply-To: <5375208d-2c11-4579-a303-e8416ab07159@arm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Stat-Signature: jzinhgyi5umfcqmtygra5nixuxurgtun X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: BA91E40004 X-Rspam-User: X-HE-Tag: 1751274259-229384 X-HE-Meta: U2FsdGVkX1+yQM416O8B/P7XpXHmAc+vZgBZwmab/mBruR4gGNQxIuXNJiAJXX4LKlziaTddiTH6xOgwcnD3fZTpyqofv5Icslt8tFJh5f6wNi3yAFgISLZNPhuO0X+bC8NyeGtpz8y6nXPXwgY5Xq7gSfk/T0DJN/UzpumNHpHQ8WnFBKysqK73aqvvSKB11Zo9L+dh6M6eO+USYXc/N9Fr/1Lc+NoK5aEwO6dhcp90wMTznYlbhqyIzAbRb4JZVWYDC01SBWaIrl9mF3s0sn2TLbDL2pkTblEBHSiIj2cRYyUnleYUsQdftPpR+VhmPYVlpZxLKoEPzpuA/oI9LOESa7bRGR8eRG1ONmRVYq8aRT+d4yJIEEzmIo+kAYPdx6H3s3JYaIDvfCcBMoVXkNH2daJ+VhUSKRxEVP/Qhk4egSyTvSgJotu84RYVHYsaRAgIBThdeujmi3rztnvHom4B7aOwU/ukJwdBhswxs3V+iEEmgOJziV6i6j6egzJmsqm+vDrRhkNVCcTDU6Zv9nHcPSLyQZqWHGn1W5yyfe/eWhhjw1OJ26oPeL2B2XdgjGTSa8X5Pxhz9eQokZ+Qgu7gWW1TB7XFYgoKwXw82vu11VhTQBM8M+EGkN4BaLJG6hBLDq3hI7mDRhq0/bv/yahM8mgP916ToL8C+IRgVsU7FNL2Nk1U5HIAtiCpspPlwMizv+9d5RlGdfsn0yKPI0nvjq0qXMPLYNr976f26Fs8JxCn93Gb4lf0Si6qIXVH5hrGXVSKZwVu4tafReDidbNYRIS6jWtWqixM0p58PmmIozBlmugXJIuarsEjX5uU5h9jeAHiktfy/ExXc1MORFvb5wEPbG1fsudOuPzZpHaxHgawD6JAJK5JSBJhdF4UzWgOtZr2Zf8lmUZaMvA5r0bV2KoJi8zwmEnbSg9e9dMUMuGUwJUTaYouPUhgdW1D/DjL/5r9sFc+96BR6hw lvFDd3tQ vwZslyOpN6nm5To8oO1cogcF+KZZMYEGcCkrgbI2BooNtjUnYLyyKnFIKT0nGXoukHb15RdqolptMP+emMUClB8aVil+4ZO211yCDaCEBvP9IoRTPvqorrpvYhxPy1zroHddh6qGe0TZk9R+WgCl5tSsgEMAWkcZPMDPJBmJYD1+RCm40Iha4cHkQ0/ic1c1h5s+5FcFqbYy0cLS4DzZnqaS+MXy3jnx84SsV9O8xOe26Q4TpWXQ4xa3t11FKsSERvv7B4mDG/Odf78A= 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 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... Thanks, Ryan