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 1090FC83F27 for ; Tue, 15 Jul 2025 21:00:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 932B26B0089; Tue, 15 Jul 2025 17:00:06 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8E3DC6B008C; Tue, 15 Jul 2025 17:00:06 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7D2516B0093; Tue, 15 Jul 2025 17:00:06 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 6E0B06B0089 for ; Tue, 15 Jul 2025 17:00:06 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id D0D521A01DB for ; Tue, 15 Jul 2025 21:00:05 +0000 (UTC) X-FDA: 83667716370.16.A1E2B5C Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf18.hostedemail.com (Postfix) with ESMTP id E7B251C0014 for ; Tue, 15 Jul 2025 21:00:01 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=gVVDfp9p; spf=pass (imf18.hostedemail.com: domain of david@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=quarantine) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1752613203; 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:dkim-signature; bh=orfWWsl/2+Pf8r55VoCjlT3TESiqdbdfWb5bInIXtl0=; b=i/EClN1CbTsDJCom7jp9EBUt8IxkvjEZni/2j9Pv/o5o7IrGazscVmAAaLgMd07W51ef8u d+CTQk5RBi9S+rGtABn13W/Y0IL956JhTaXwvYKn4cPoAYgISMEIfNoAV8W+KnMPNOSdwg eeWxyDdGKBJS6h2lbGwqsdHFllIcmTE= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=gVVDfp9p; spf=pass (imf18.hostedemail.com: domain of david@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=quarantine) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1752613203; a=rsa-sha256; cv=none; b=zBqwYXL/z7J4e0/xMbeqUCFe2cUXD+7BbMKZNptdRGzR9iTQyvELlh8DA/DuhTBFRDYmZs d8Bbqrdp98tyxDnFEHxRIRiyfK0x79iUfYey0yxeH8WgqS4DljC+XXfEA+mudfaxCHcCGV iTeE4uNikpwByTKEFQYTRjvmD7Im5fg= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1752613201; h=from:from: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=orfWWsl/2+Pf8r55VoCjlT3TESiqdbdfWb5bInIXtl0=; b=gVVDfp9p+30WVryg3qJXaFK14ss1gf3JfFFXIzFeyuHagxJ3B4YKfEuSS3JCURzeSoTPGq 4UqDP8z8jxGNd13jayR+ij4/h9MDfDUUuRc9doZA88X7olZxqOPTlLb8Euyq9oKMvOKEQ2 1Vukn5CN0y0loqcGJOC0Ez6jb0CpqvU= Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-604--2fjcm8JP_WLVXF9Dskr_w-1; Tue, 15 Jul 2025 16:59:59 -0400 X-MC-Unique: -2fjcm8JP_WLVXF9Dskr_w-1 X-Mimecast-MFC-AGG-ID: -2fjcm8JP_WLVXF9Dskr_w_1752613198 Received: by mail-wr1-f70.google.com with SMTP id ffacd0b85a97d-3af3c860ed7so2592798f8f.1 for ; Tue, 15 Jul 2025 13:59:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1752613198; x=1753217998; h=content-transfer-encoding:in-reply-to:organization:content-language :from:references:cc:to:subject:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=orfWWsl/2+Pf8r55VoCjlT3TESiqdbdfWb5bInIXtl0=; b=w1mbICEYQ1xXQxBOu9ixvWsSvURMZWSC3Rw7O6jpiUG+shW/ME52aeokW9jiNqtku6 wB2/doLwNs6f/F9csZeIF58XQ+V89SHlr5Kz/9f0276xC9pA6CxpPKFALoQ6LZ0HSTKe D+4RakPFNlB88rtVZrKYeRTaA4JkCr+8KBaWf0Gm1rQCzspbYr3G08amZHyUFTuF0iQv 0Zk7jkalcP2JFmyY30SXSkJHh9jpGFnolESTFY98wK4BQqd+bVUQTT3cQ2RPsuwdYDLB Aiyc6EHBXhj8+HPxXsbXXRbNhg84dighnbVdAAkSMAO2Qg8m1v5Kjjxwu6iTefek77OX OI/A== X-Forwarded-Encrypted: i=1; AJvYcCUv1PHJlL2LS57LoxAtDzFhkjVrCM/VIhL6wUZDwP8DP0ItJKxOVi92UTT5eHGU7TuvyiXuOBh9gQ==@kvack.org X-Gm-Message-State: AOJu0YwONzJsRDnNNXwmxdqLH3+CtHJ5V+BlY8zpZ78Vrj4L7kvR9Fqn Rw6aoK55aXvasG7UUl6Brr10rqqEHsyBdRwf87bXM/i2kcKBG2AA8Q0nZf4Q6w14dDdPB16b5uq JMyS1iiYQJKFy1LDt4xtRFUKgtrAcQR7sP6yWRKTNTsmIFJUonZ3P X-Gm-Gg: ASbGncuzCkunptEPqhCvjarX7+Mk8b6bskgObgj45dAROhWEBQmpTvNBe4JZZrT0vyp uP2XGbyeOf6w0sXZFbBhc3apL9Ew0JVLJFt7gPvCNaExKCxb2APdw9zRSCgjn2BWuh1YiMn3+ZT 7Ol0Ibkh8ZVgg68ddsUwJDbA2fXKzl/9l9aOZWCm0oPUZgGdeNB0dmBcQKfSRmN1rmCN/PDf7CJ KAoFxH+LNmiEu9SnY7f9x14boLwXoP30wI1X1bhn1q2k4KdPsmfretjYcm5rgbXoT+Qz7J5syqM 3YJJWGNqbUxIwDoaM+41O925qaqygEhOPWKuoSyndyXpP48yQ2UsWVUtCRXxU5CGtMDLLlo= X-Received: by 2002:a05:6000:2f88:b0:3a6:d26a:f0f5 with SMTP id ffacd0b85a97d-3b60e4ed4f2mr29344f8f.21.1752613197694; Tue, 15 Jul 2025 13:59:57 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGyYymmr26QFygmkbNiXyQJM9jzV+eIWenc1xK+3dviERnxtgr6GW8Q8vgbqdgO2rkMKSnHcQ== X-Received: by 2002:a05:6000:2f88:b0:3a6:d26a:f0f5 with SMTP id ffacd0b85a97d-3b60e4ed4f2mr29322f8f.21.1752613197179; Tue, 15 Jul 2025 13:59:57 -0700 (PDT) Received: from [192.168.3.141] (p57a1ac9c.dip0.t-ipconnect.de. [87.161.172.156]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3b60e3ed902sm76138f8f.91.2025.07.15.13.59.55 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 15 Jul 2025 13:59:56 -0700 (PDT) Message-ID: <00891d95-94c1-4cc7-a152-3d243a91afd1@redhat.com> Date: Tue, 15 Jul 2025 22:59:55 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v5 12/14] mm: add config option for clearing page-extents To: Ankur Arora Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, x86@kernel.org, akpm@linux-foundation.org, bp@alien8.de, dave.hansen@linux.intel.com, hpa@zytor.com, mingo@redhat.com, mjguzik@gmail.com, luto@kernel.org, peterz@infradead.org, acme@kernel.org, namhyung@kernel.org, tglx@linutronix.de, willy@infradead.org, raghavendra.kt@amd.com, boris.ostrovsky@oracle.com, konrad.wilk@oracle.com, ziy@nvidia.com References: <20250710005926.1159009-1-ankur.a.arora@oracle.com> <20250710005926.1159009-13-ankur.a.arora@oracle.com> <87qzymocok.fsf@oracle.com> <9865895d-c9bf-42e2-b813-bdbd39ad3af1@redhat.com> <87ple2jysm.fsf@oracle.com> From: David Hildenbrand Organization: Red Hat In-Reply-To: <87ple2jysm.fsf@oracle.com> X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: jcNspS8XlnLLwsJtnfj7_fmNQQr3b-L6elU04XbUNVc_1752613198 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: E7B251C0014 X-Stat-Signature: ggbhm3iam3u8memk5jpu7i4np3ax4aan X-HE-Tag: 1752613201-456407 X-HE-Meta: U2FsdGVkX1+uudkJ0H/7XRcOpxEsEd1ukhgNg846HQwsoDHF4mBRN9ucK+lf7rC2vslTXGAEu4+KEQFZmRhz5gyOb1D9dt7RBo5+Hz4zYY4jFs4kDaQrqFXMUcGJyJp0QkYshAfryF3GRCz+eGzjRd8PnOEOZLjhBt0LhlsffFjDR3LAKRm9NoeTNwEelaiNAvkRm9+/wvNDpi6Zc0D0V37uA+kuBeTXHjPH39iwYhvrJ2ukFrW/TAVx3xe2P1RCjRslE3N8bsBxqBl721VCTbBOpqNfWPomqOOEz1t5tbLDd/nLCc4MwVDnomLb0kEnzEHjYoc3yB4dsSa4KM4Ng8JMLo958KGBiOZSxV+hv+jfx5HnXIj/NZ3IOX6ivT9UvRBDDMRK3cWGczVIujad4RUZb+o+H8PngcTD3o6QylnOnP/Bt14a9o9+hNh3i6WHYFHpWOcODBJhCt3JGfar8G/KUB2gti31r5td+ajeq/E0NoBOuYnxHQRDQ22q3Hwsn0Q5JG3+Fi3nOWno+cDgLbzD0rFMqS9W2roL71iuxxcR+X7uXCZBdTN7f4c7dAtWv+JRMNsuTnyikLGdn0kFHG+qVXJQUjfhmI/RWjraNT9irr3087tCBx70yzBBtHVhEAMc/xhmcWMg5v8c/OI9TJ3UHtHopt9+xQlKF3z5p9yQ989ShFhntFHJzKfR84TVYrFwDLzYRXKDva+rr5MI77DqQMWRXs94n+jKPlpGAlw6Pf9qIpZVwo1cDfXyzbhfYVeLb0lEyHBDLm7EhmsVx5HsmmZfBfc3Kj3HzdmmDDK78SQwrQGrZfiDPGqZxCEf6SFYvvAH3Yd0kW6Yx5QYA+wvPjj4hxbLVWfyPnngAS4Zcd42bED+OarzhVjWOrOxPQ6RB3PXZyBX0UR/LjGCz1iO7kwdanh40yQ8TFqQrOOeS2pU3os6xIndfKyUgzl+jLGkwUg+QVei7A16qel vR8UtNaE Urgr6QwAbumfSffcEoyQg70ifZZuyROiUVA6fOjrI6bT45Hg6CLgA1lKwBRCbSzwvApwQpI6rmcLZlOWhMGeCxdBoITpHHC4v/khbYHDL1J8XT+ZjhXhF4eRaeCXH9EfXPCygb/i4khNhjDhdGvu/uoV5FxOXB5P6b7NdIdLcnoau+X8aXy0TymQcQ5qzHpWf8VqyGZXzFoBPOT8UIefZY/JqOgcZBlQHl+L+5TMzKZS8l48VDz3tSIjDTvr4CZmpJmT4WkOtvyrzR0+TgDfDjRksxe/as3/XRvBA2ulZhHr+wYin2zYYytwVWvwheGac1gRkQRv7TPQbaZUG0A6wmJlYAvctAalWbILscPE7IwARjXDDZ+4oqNtMhbi7aKkghDVerdYs/Nd9fNSSkkqnJyrgTPBlXFUffFTt9IP3uuWx/PYHA3RVcd7JOQDn0p1EnkvKC+ccdfD7vsdJDi4uIkxKkA== 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 14.07.25 22:35, Ankur Arora wrote: > > [ Added Zi Yan. ] > > David Hildenbrand writes: > >> On 11.07.25 19:32, Ankur Arora wrote: >>> David Hildenbrand writes: >>> >>>> On 10.07.25 02:59, Ankur Arora wrote: >>>>> Add CONFIG_CLEAR_PAGE_EXTENT to allow clearing of page-extents >>>>> where architecturally supported. >>>>> This is only available with !CONFIG_HIGHMEM because the intent is to >>>>> use architecture support to clear contiguous extents in a single >>>>> operation (ex. via FEAT_MOPS on arm64, string instructions on x86) >>>>> which excludes any possibility of interspersing kmap()/kunmap(). >>>>> Signed-off-by: Ankur Arora >>>>> --- >>>> >>>> Staring at the next patch, I think this can easily be squashed into the next >>>> patch where you add actual MM core support. >>> I wanted to do this in a separate patch to explicitly document what the >>> responsibility of the interface provided by the architecture is. >>> That said, the commit message didn't actually do a good job of doing >>> that :D. >>> Copying the more detailed commit message from my reply to Andrew, >>> one important part of the clear_pages() is that it be interruptible >>> because clear_pages_resched() implicitly depends on it. >>> >>>> This is only enabled with !CONFIG_HIGHMEM because the intent is >>>> to use architecture support to clear contiguous extents in a >>>> single interruptible operation (ex. via FEAT_MOPS on arm64, >>>> string instructions on x86). >>> >>>> Given that we might be zeroing the whole extent with a single >>>> instruction, this excludes any possibility of constructing >>>> intermediate HIGHMEM maps. >>> Do you think it is best documented in the next patch in a comment >>> instead? >> >> I would just add + document it as part of the next patch. >> >> Looking at the bigger picture now, you introduce >> >> ARCH_HAS_CLEAR_PAGES >> >> To say whether an architecture provides clear_pages(). >> >> Now we want to conditionally use that to optimize folio_zero_user(). >> >> Remind me, why do we want to glue this to THP / HUGETLBFS only? I would assume >> that the code footprint is rather small, and the systems out there that are >> compiled with ARCH_HAS_CLEAR_PAGES but without THP / HUGETLBFS are rather ... >> rare (mostly 32BIT x86 only). Agreed. > > I thought about this some more and there are a few other interfaces that > end up clearing pages: > >> clear_highpage() >> clear_highpage_kasan_tagged() >> tag_clear_highpage() > > In this set, there are many loops of the form: > > for (i = 0; i < n; i++) > clear_highpage(); > > At least some of these (including kernel_init_pages()) could be migrated > to variations on a clear_highpages() which could be: > > static inline void clear_highpages(struct page *page, u32 num_pages) > { > if (!IS_ENABLED(CONFIG_HIGHMEM)) > clear_pages_resched(page, num_pages); > else > for (i = 0; i < num_pages; ++i) > clear_highpage(page + i); > } > > (clear_pages_resched() should be safe to be used from here because > everybody using this should be in a schedulable context.) > > (The kernel_init_pages() was also suggested by Zi Yan in a review of v3 [1].) > >> clear_user_highpage() > > Only users folio_zero_user(), __collapse_huge_page_copy() and > userfaultd. > >> clear_user_page() > Not many users apart from the highmem interface. > >> clear_page() > > Not many users apart from the highmem interface. > > I'm happy to do this work, just not sure how to stage it. In particular I > would like to avoid a series which tries to address all of the cases. > > Maybe it makes sense to handle just add the clear_highpages() variants, > folio_zero_user() handling and some of the obvious users of > clear_highpages() for v6? Yes, no need for excessive handling. What I was getting at was: could we get rid of the kconfig option and simply glue it to the availability of clear_pages() in a reasonable way. -- Cheers, David / dhildenb