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 65013C83F1B for ; Mon, 14 Jul 2025 15:30:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0836E8D0008; Mon, 14 Jul 2025 11:30:26 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 05AA08D0001; Mon, 14 Jul 2025 11:30:25 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EB2828D0008; Mon, 14 Jul 2025 11:30:25 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id DC4CF8D0001 for ; Mon, 14 Jul 2025 11:30:25 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 89ED41D8C4B for ; Mon, 14 Jul 2025 15:30:25 +0000 (UTC) X-FDA: 83663256810.17.3844917 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf28.hostedemail.com (Postfix) with ESMTP id 247DEC000B for ; Mon, 14 Jul 2025 15:30:22 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=ACuTJwJJ; dmarc=pass (policy=quarantine) header.from=redhat.com; spf=pass (imf28.hostedemail.com: domain of david@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=david@redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1752507023; a=rsa-sha256; cv=none; b=UfbQVgD/o+O9Dc8rxEYAggEUiKb0r9+WoPjlGwMxLHo/vbyYIvW7EitKZPjvfw6L6xKx3q DknMJSwWSFGgaeTZfn0614/Knj31jfdRuJsOhrQe5H1DFZrrzm0KhKxRSped/SQUNqomgW 1lSefkntxr9Wi9ExspD4hEpDNTAz8hY= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=ACuTJwJJ; dmarc=pass (policy=quarantine) header.from=redhat.com; spf=pass (imf28.hostedemail.com: domain of david@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=david@redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1752507023; 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=gohbFxz9eRg8F1mUSZnC3p7R6dVwGgRWZw+cknpicic=; b=2CPdx6sPiBVP2MF/2JPC7zCMoEehE+FN/qIkzp2BMrHMaJnUhdq2HKC+zhRc5IqIVmnoeS 6MxbdCJdDDPv34e4ehiACvdFFDnqAZuLN4X41NftqfzgN3cBwtqUIQrmIVJUAU2R8rXKEH oVUIklBYD0ZJ8sPyKKOGCJ4QHW6KCf0= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1752507022; 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=gohbFxz9eRg8F1mUSZnC3p7R6dVwGgRWZw+cknpicic=; b=ACuTJwJJo7brxnaKge/a5cKoI2G2qm1twCFWfGYCNycrC5yMHe/rMVoWejZFshswK60aoM uthEbLAQiNhb/W/fvZP5wz/sgJpfZRMFBb+0FSznN8I+5nI1TaJrOKY3vMQUTldKJhLSiJ JjwmrD9hD2yGw4/v+7CbU7KhshlB5Dw= Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-418-j4pieiwENByIZPL2fBzdsA-1; Mon, 14 Jul 2025 11:30:21 -0400 X-MC-Unique: j4pieiwENByIZPL2fBzdsA-1 X-Mimecast-MFC-AGG-ID: j4pieiwENByIZPL2fBzdsA_1752507020 Received: by mail-wm1-f71.google.com with SMTP id 5b1f17b1804b1-4532ff43376so41256275e9.3 for ; Mon, 14 Jul 2025 08:30:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1752507020; x=1753111820; 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=gohbFxz9eRg8F1mUSZnC3p7R6dVwGgRWZw+cknpicic=; b=Mq3TBuUdB1Ta1UcNLy/IO1aJMfyszff8tZirThyJZebtpD2+wO83EqPc38h2NB0qxu 4MnxjoW34A4mI0xoQ2Csgg5PRC9r0E1s+tZFvxaeH1bq+QZfdbLS2ijFU5NXeEBwSaY6 8VpnKo81d6RLaBaWd+FgHwd9vPlXMBcMHxG9vvwehC+36yl2LSOOHaDtJqQ9rqUzF7iT UPu4gY6gmDZSmGaipLsvt7lBGB9TdERgID+CxsiRp8fLGvI4Te+ppyDVdg5wk7XtbYSU IJrrVycDS8dpUXeIdLGlA9n2FKubL/sYgl3GqV/Fk25XvxCmF3isN2lxTYVWqewsaEfS X8ww== X-Forwarded-Encrypted: i=1; AJvYcCVTltttqdRIn707yAfDDkv8acGHpqJB3nBK+vBhYbRvGpyarr3ghsW4YWTQqk0AkIv/8MNvWQSNVA==@kvack.org X-Gm-Message-State: AOJu0YwdnpI7dRcNFI3LWolaOrijgkDcvHr0ec1d7PWhQssBWI5pzMYa LhW+DufJJhgApDW94WlV+6VD7s5DoLnYUuu8jk26cmtO4wS5ji4pwGBb4LYahHo7c7PMJNOn+9J 0UE9eH03HkFe36RkiA/KT9nb4cZBD4O2rKpEjUdv2v1k9RWx1VW2QswTf6azByjk= X-Gm-Gg: ASbGncs75mWS+xOmpRwXw+JmxLSBh9IUD2wCUBBthIxqKoSeDyB5EAshMEEo93tcjIe tSHxHiPjjOR6atQ+1gAdIk2I/v/F8N5D3VuH2zhj0Y6ezpXoD1ddW9vqEX1HNwnnwtmbwe0k8d9 69nzOTejpusO2Z9HtTwouKFFh4HJVvqJrzNGPiik3RaU86iuqK7qhtCtIH83IO8642l6eE7sOot hhqelcRX3bBSR3SeFnSuaJ5ebZDcWnoKxnDpx6/33p4JAvIjHzjj0BKCJTMkPbYYtlHVmb6ASQ8 5xK6Nny/q1uHT7aHP0mYFw2M6oAe41oC/ZGE9DcfPBu7No/3ZVe82jJ/fL8y4EZiRzilICSP+DN j6SYK4SqpCruB0j1TKpTDvGx+s5nRw9rptC71yf4bLEbW8sdozL15K/gR+fXieArm X-Received: by 2002:a05:600c:c4ab:b0:450:cf42:7565 with SMTP id 5b1f17b1804b1-454f4261520mr103684775e9.23.1752507019930; Mon, 14 Jul 2025 08:30:19 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFrlAgMB5C+1RW3hZQtc2HLO/XVU7Qsg5A9KDPFitWXd2QxzvhtVbrB/gIf4+x1ax/4pkIAJg== X-Received: by 2002:a05:600c:c4ab:b0:450:cf42:7565 with SMTP id 5b1f17b1804b1-454f4261520mr103684475e9.23.1752507019507; Mon, 14 Jul 2025 08:30:19 -0700 (PDT) Received: from ?IPV6:2003:d8:2f38:ca00:ca3a:83da:653e:234? (p200300d82f38ca00ca3a83da653e0234.dip0.t-ipconnect.de. [2003:d8:2f38:ca00:ca3a:83da:653e:234]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4561d19a21dsm26884725e9.24.2025.07.14.08.30.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 14 Jul 2025 08:30:18 -0700 (PDT) Message-ID: Date: Mon, 14 Jul 2025 17:30:17 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 1/2] mm/huge_memory: move unrelated code out of __split_unmapped_folio() To: Zi Yan , Balbir Singh , linux-mm@kvack.org Cc: Andrew Morton , Hugh Dickins , Kirill Shutemov , Lorenzo Stoakes , Baolin Wang , "Liam R. Howlett" , Nico Pache , Ryan Roberts , Dev Jain , Barry Song , linux-kernel@vger.kernel.org References: <20250711182355.3592618-1-ziy@nvidia.com> <20250711182355.3592618-2-ziy@nvidia.com> From: David Hildenbrand Organization: Red Hat In-Reply-To: <20250711182355.3592618-2-ziy@nvidia.com> X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: 1ovls_tNVpTTIufqXEvyWWjENGHbskWUOcyzhQ4Ko1A_1752507020 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 247DEC000B X-Stat-Signature: gaendzmq77b3fbwdx7pa44snhjchfwy1 X-Rspam-User: X-HE-Tag: 1752507022-470875 X-HE-Meta: U2FsdGVkX195+o4Mb8iWuVIRZakQEBIep/wLTJMnpUc+XG1BHvhhEx/Yw47HLKa14TOhMlsf01c9YPd0gLXhFjis7C5umh2u2BYPPVx4dWeKW2AQB83fl3Ep0kA68+UOdFxjttGysK6rL1LRzD7oPiCMj5mLXm/QygehyfDMTOPK4K/2PMaLR6ot73t4J6gIlFkxyuX004XCMfMos6fI/YCLIPJdA97M74EF4tK5jrfOJiHiJpMQWr8YQFX2gBNEjkGa8jbcGSk51sNm1E1UfvOF9r7RAgF9Uv+lOZFsFeP/WZ84apq4YiYG1Z23OmVy+0O+woZEikcswmSNHHyDVm1Rh6ABBhDKExhljifguK/Bz5B2JRlC8/zmQvkh2zCFZbyWMk/BcGocHIN3fL00zGEl9pt4PHMzXUekXd2ThoS0PXi9nd/jgXrX4OORrQgpQcF2dMDyPAnV8ovPRc3V6H1/A1m4oAX9Pk6lR/EIiNr49kS8iSd6LvKxSKmTowItQcFqZo7HXLD6i2dZYUclKQhXns5mWhaULqR3N3/vJ/EulMPA0COmcR3CH/G7XJGSPTnnpBOiEvoV7tE1mg61jSGtaok+4mQ7SJv0twx2I7G00olm9rO1I78zLgMtICLgoelvfiK57NH8s5Oa65qipD59SkTNhRoD09NZZ722vuiOYvGbjB3yLagSOPDsO6dumb0DJi6RzB22Rr6p8QO6IpMoSiHnuRRsF0p5A0iKndj3qnR9oE9qApeJz2VDYS8rOZhuecv5ap1GDL0vLYfEZO7ONzEh1cpukfHjaMa7jziH2Y71OnaLnNyn/Mwv7yXDoZsI5mExAqrPNzsF+WtBgciv0lev8fU0XsjzYVauMsSadTDiO/Zky6fcF6+LrrsFe8ehkY/eihcqRs7CR9V+0i+wtcOxdh+iUrRzTJe7G81eq/e3ms+tQF7+H29aATeO28EUI+2WcMHamXdNDfm GkhptVR9 KJMPcxOVEeFREkD4/xtCfLZPE1p0V8/2vTVEzhzGZvU7P893Z2cSINpCvo+XL+wD4pBmpl4bXFuUiVn9Y0t6yE2pWAmhhsrsVzbZv1QlySKp8d4IVxdDo3ge9S8MkO2xnaE5peMKvgi3sRrykiZJIcb4DK8PzsVwR+xRyutpHGjTi2YoSF2zUHKCVlQv9kI8CyST7xqyQU8Vl6RbsKUXatK5366vZCR/97zndTx/3OfEBL8g1up2hNcyG2lp7o89QXiDFV5Cfqk8Ew24ueeuUpJD2GWIGOz7cu2drbOk1Uae+VqtOZgRPafXTj6VFUEVGWASzGhp1xBRfEcfwra+i6cfzw3Qup8fu1mq4X8tOk1wdWsPR5IYacZHMx1T2KJNDQKAWyQ2mtcbIq4Okj9ifYX+HKXOqs2HEEUTL1kjWX1Qzyv2dMXuXJw6e9DH1tsYrZACVHU4U4s+ME1ddZneGG6vP82VMtHUH3hnUJYm/fG1jOXF4/Fr0LWAqOZXf6th5iyqbF7K8dzRL9FMRRCK6Krw/9N9fdkTRwqiLlJqJX2q9mACifQTbo7JixyFf9z2RVpfgOYNQudA+/R2uAfOJ/e8eTk+SbGzTu/ts 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 11.07.25 20:23, Zi Yan wrote: > remap(), folio_ref_unfreeze(), lru_add_split_folio() are not relevant to > splitting unmapped folio operations. Move them out to the caller so that > __split_unmapped_folio() only handles unmapped folio splits. This makes > __split_unmapped_folio() reusable. > > Convert VM_BUG_ON(mapping) to use VM_WARN_ON_ONCE_FOLIO(). > > Signed-off-by: Zi Yan > --- [...] > - if (folio_test_swapcache(folio)) { > - VM_BUG_ON(mapping); > - > - /* a swapcache folio can only be uniformly split to order-0 */ > - if (!uniform_split || new_order != 0) > - return -EINVAL; > - > - swap_cache = swap_address_space(folio->swap); > - xa_lock(&swap_cache->i_pages); > - } > - > if (folio_test_anon(folio)) > mod_mthp_stat(order, MTHP_STAT_NR_ANON, -1); > > - /* lock lru list/PageCompound, ref frozen by page_ref_freeze */ > - lruvec = folio_lruvec_lock(folio); > Nit: now double empty line. > folio_clear_has_hwpoisoned(folio); > > @@ -3480,9 +3451,9 @@ static int __split_unmapped_folio(struct folio *folio, int new_order, > for (split_order = start_order; > split_order >= new_order && !stop_split; > split_order--) { > - int old_order = folio_order(folio); > - struct folio *release; > struct folio *end_folio = folio_next(folio); > + int old_order = folio_order(folio); > + struct folio *new_folio; > > /* order-1 anonymous folio is not supported */ > if (folio_test_anon(folio) && split_order == 1) > @@ -3517,113 +3488,34 @@ static int __split_unmapped_folio(struct folio *folio, int new_order, > > after_split: > /* > - * Iterate through after-split folios and perform related > - * operations. But in buddy allocator like split, the folio > + * Iterate through after-split folios and update folio stats. > + * But in buddy allocator like split, the folio > * containing the specified page is skipped until its order > * is new_order, since the folio will be worked on in next > * iteration. > */ > - for (release = folio; release != end_folio; release = next) { > - next = folio_next(release); > + for (new_folio = folio; new_folio != end_folio; new_folio = next) { > + next = folio_next(new_folio); > /* > - * for buddy allocator like split, the folio containing > - * page will be split next and should not be released, > - * until the folio's order is new_order or stop_split > - * is set to true by the above xas_split() failure. > + * for buddy allocator like split, new_folio containing > + * page could be split again, thus do not change stats > + * yet. Wait until new_folio's order is new_order or > + * stop_split is set to true by the above xas_split() > + * failure. > */ > - if (release == page_folio(split_at)) { > - folio = release; > + if (new_folio == page_folio(split_at)) { > + folio = new_folio; > if (split_order != new_order && !stop_split) > continue; > } > - if (folio_test_anon(release)) { > - mod_mthp_stat(folio_order(release), > + if (folio_test_anon(new_folio)) { > + mod_mthp_stat(folio_order(new_folio), > MTHP_STAT_NR_ANON, 1); > } Nit: {} can be dropped Code is still confusing, so could be that I miss something, but in general looks like an improvement to me. I think we can easily get rid of the goto label in __split_unmapped_folio() doing something like diff --git a/mm/huge_memory.c b/mm/huge_memory.c index 14bc0b54cf9f0..db0ae957a0ba8 100644 --- a/mm/huge_memory.c +++ b/mm/huge_memory.c @@ -3435,18 +3435,18 @@ static int __split_unmapped_folio(struct folio *folio, int new_order, if (xas_error(xas)) { ret = xas_error(xas); stop_split = true; - goto after_split; } } } - folio_split_memcg_refs(folio, old_order, split_order); - split_page_owner(&folio->page, old_order, split_order); - pgalloc_tag_split(folio, old_order, split_order); + if (!stop_split) { + folio_split_memcg_refs(folio, old_order, split_order); + split_page_owner(&folio->page, old_order, split_order); + pgalloc_tag_split(folio, old_order, split_order); - __split_folio_to_order(folio, old_order, split_order); + __split_folio_to_order(folio, old_order, split_order); + } -after_split: /* * Iterate through after-split folios and update folio stats. * But in buddy allocator like split, the folio -- Cheers, David / dhildenb