Message ID | 20230403201839.4097845-1-zi.yan@sent.com |
---|---|
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp2563710vqo; Mon, 3 Apr 2023 13:23:56 -0700 (PDT) X-Google-Smtp-Source: AKy350ZrMEikekBsGA9AvGTnHYfGo3ZcLjn2JZGAFVXjBS8G5PDIZMyOBplqqyDrWq/YDvftCq27 X-Received: by 2002:a17:902:e40b:b0:19e:786f:4cac with SMTP id m11-20020a170902e40b00b0019e786f4cacmr181534ple.53.1680553436363; Mon, 03 Apr 2023 13:23:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1680553436; cv=none; d=google.com; s=arc-20160816; b=L18Bz0AjQ8i7/cu9ey2UQtuzYru40w598iI+wdZ25pYgXnxedg/kGiestOZny/TKpI 98OFX1Naxw+JO/cSoG7O+hXmFjsJwSsUEjYDmNHZ649XtuRPzk0Z1abKNMlPM0Orpgxm aTBus6G9v1yp54k2x2ZodzTUfQDUYFLlk/Qd8yXSBZnSd82t9THFSbLYXuDL/LB+6ouu H/fz7IVrnTGLw9FJJiOCdYRu03BSDAsSUVEZK1Iu0g3rnIRmvHQnPNlQaqAwWBRsbzUH /QQYBtaVh1cKBFIntU2aFgSnTXNX3g6aPNOQE+I78COEsw6iJ0m6Bl5gcGW0bio5zQ/3 ZiSQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version:reply-to :message-id:date:subject:cc:to:from:feedback-id:dkim-signature :dkim-signature; bh=PtE34Mi5e7fcyqY/yn1ZOTjs4FeBAcshGnyuLTQZvAU=; b=nFrDJ7g+5gLMcKtr3a1CteoY3S07p9fToJ34SnAWF5RpWhfX1uBGBNkWsCnF8FP7ea gRvVREXlPmXcd0kElZPhuwWBgCx3cgp4SoZ7OIxyendVNB7NEZCq+FO2sTDpuOvAhU8b PqRwTWfUKbbBkV5EVZbR4EZAmG8pLSqDCdPOjEvJcuYpUU8kyHdUPGEx/dgS009Axdwb nhfl0gVQj25dB7JEYyrTBf8ZA+X8pGfA2H0/3WdXD8dsJ0GaC+piFnC9XgKYZYX/Ir/F FaOV+jgVvEZrAHuUprErpPsqhIsblF6eCf3jOzTwxA43Lr7n8aiyma1Gh+BoD8hb2IKw Zb1g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@sent.com header.s=fm2 header.b="B9s/caMa"; dkim=pass header.i=@messagingengine.com header.s=fm2 header.b=hdQl9dH6; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=sent.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id x11-20020a1709028ecb00b001a1cef2acbdsi8682132plo.170.2023.04.03.13.23.44; Mon, 03 Apr 2023 13:23:56 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@sent.com header.s=fm2 header.b="B9s/caMa"; dkim=pass header.i=@messagingengine.com header.s=fm2 header.b=hdQl9dH6; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=sent.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232938AbjDCUTJ (ORCPT <rfc822;zwp10758@gmail.com> + 99 others); Mon, 3 Apr 2023 16:19:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54934 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229446AbjDCUTH (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Mon, 3 Apr 2023 16:19:07 -0400 Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8913F3586; Mon, 3 Apr 2023 13:19:06 -0700 (PDT) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 3E05D5C0081; Mon, 3 Apr 2023 16:19:03 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Mon, 03 Apr 2023 16:19:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sent.com; h=cc :cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:message-id:mime-version:reply-to:reply-to:sender :subject:subject:to:to; s=fm2; t=1680553143; x=1680639543; bh=Pt E34Mi5e7fcyqY/yn1ZOTjs4FeBAcshGnyuLTQZvAU=; b=B9s/caMaukwcV+M6dZ kL9rfGdE67qmnEh6DZ+AUJ55B1lwYnKkiaFZvFvxWifT6Qeb1s+1Qzsdmuhybud9 yEJBjwhl17/yloWHzzlfAv0RE9u/jJDvDsBPxlC3V/+RtFzChmK/Iew9OQXh+BnW vTvWyK6zGm2BkJ3cYwL/+pUM0bq2Q/612wWE9WO7Y8w7gx1bxVRfySjBY8ffm+2S ouTUAk1Df/BVj5cSdbAM3AJY67x4h7boC1NsLkdywmHS5e/oU/GBeCPrrA795zDu mVP7OA8dK3cDuGuXOCDx9ca+E4uiXThMzuwRIeF+5edpSmRg7vFYqsxfu4jyB/j7 HY4A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:message-id:mime-version:reply-to:reply-to:sender :subject:subject:to:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; t=1680553143; x=1680639543; bh=P tE34Mi5e7fcyqY/yn1ZOTjs4FeBAcshGnyuLTQZvAU=; b=hdQl9dH6VQ/26IqYX DLyWdDnhElnsE5R5dMTtqP9vEPsjctti3fMutSNYYpRDF6z4WAhpyOlLdqQR/y5Z xko0rDzCgzEgEh/VJwcwic9W9BvKECkYWUtgNXga7PhLmmQUFPmi0LC5kx6zvKlX 1q18Xnd7DIGG0EupwueU/TfD14QpewPnBuxdDStvScTEMTYwylClaaoqhqvvJ/o2 9rLR0o+Q1ksTidiE0O+b+/7jCIzNyYaI/CLOfG5Gt6AJaT+HqXYBkhxzxzPOSGrU gE+Kd3Bjs59c9LjTGyD/ArDHxMJ9XS4JJwvMONKrytkBORXYOG7b4UYyTpZGs09T c9qqA== X-ME-Sender: <xms:tjQrZMN2gja3Oe5fG7-mKFH26_rU4ABTH8Q8XFg3Ck9OnfER9W4oLQ> <xme:tjQrZC_f-UlcEhOO_rDCm_iS505hYekLK2Zf-fCS-sCnqzfQbnplx4ovSgHPkjwz5 LSwwIhAXiai0kghVw> X-ME-Received: <xmr:tjQrZDSZnHaRL67rW-lUftdyWfADOJRfA1FfRjBBBdyyuA5oafyJ4s_MGAFYyU_aiqE_iiWzJfyOpWzU1pRTsEiuQLOf_pc8DYLYOombcgwPZEoP1sZydDOAOh8N5rA> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrvdeijedgudegkecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefhvfevufffkfforhgggfestdhqredtredttdenucfhrhhomhepkghiucgj rghnuceoiihirdihrghnsehsvghnthdrtghomheqnecuggftrfgrthhtvghrnhepvdeiue dthedttdfhgeevkeeuveefvdeuheejledtvefgjeetkedugfdvleevkeffnecuffhomhgr ihhnpehkvghrnhgvlhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmh epmhgrihhlfhhrohhmpeiiihdrhigrnhesshgvnhhtrdgtohhm X-ME-Proxy: <xmx:tjQrZEtfJcvkWMD1pazyxNcS_IWGnXUBPXziAvubh5OtKHfW1FDfzw> <xmx:tjQrZEe57jG9TosSu5qJGEMlrRhJ_YJ34dLFONQ3XnLt7WdtamoInw> <xmx:tjQrZI1JdZ2HM4jBSSaFS1pAii6POwCAZdUJHbdghkb-6LtWKPJbxA> <xmx:tzQrZD-dvR3Mok-Pdf0cwl473T7rMI5nUHfW4RMNGwangipgprf2hg> Feedback-ID: iccd040f4:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 3 Apr 2023 16:19:02 -0400 (EDT) From: Zi Yan <zi.yan@sent.com> To: "Matthew Wilcox (Oracle)" <willy@infradead.org>, Yang Shi <shy828301@gmail.com>, Yu Zhao <yuzhao@google.com>, linux-mm@kvack.org Cc: Zi Yan <ziy@nvidia.com>, "Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>, Ryan Roberts <ryan.roberts@arm.com>, =?utf-8?q?Michal_Koutn=C3=BD?= <mkoutny@suse.com>, Roman Gushchin <roman.gushchin@linux.dev>, "Zach O'Keefe" <zokeefe@google.com>, Andrew Morton <akpm@linux-foundation.org>, linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-kselftest@vger.kernel.org Subject: [PATCH v3 0/7] Split a folio to any lower order folios Date: Mon, 3 Apr 2023 16:18:32 -0400 Message-Id: <20230403201839.4097845-1-zi.yan@sent.com> X-Mailer: git-send-email 2.39.2 Reply-To: Zi Yan <ziy@nvidia.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1762188000288772046?= X-GMAIL-MSGID: =?utf-8?q?1762188000288772046?= |
Series |
Split a folio to any lower order folios
|
|
Message
Zi Yan
April 3, 2023, 8:18 p.m. UTC
From: Zi Yan <ziy@nvidia.com>
Hi all,
File folio supports any order and people would like to support flexible orders
for anonymous folio[1] too. Currently, split_huge_page() only splits a huge
page to order-0 pages, but splitting to orders higher than 0 is also useful.
This patchset adds support for splitting a huge page to any lower order pages
and uses it during file folio truncate operations.
The patchset is on top of mm-everything-2023-03-27-21-20.
Changelog
===
Since v2
---
1. Fixed an issue in __split_page_owner() introduced during my rebase
Since v1
---
1. Changed split_page_memcg() and split_page_owner() parameter to use order
2. Used folio_test_pmd_mappable() in place of the equivalent code
Details
===
* Patch 1 changes split_page_memcg() to use order instead of nr_pages
* Patch 2 changes split_page_owner() to use order instead of nr_pages
* Patch 3 and 4 add new_order parameter split_page_memcg() and
split_page_owner() and prepare for upcoming changes.
* Patch 5 adds split_huge_page_to_list_to_order() to split a huge page
to any lower order. The original split_huge_page_to_list() calls
split_huge_page_to_list_to_order() with new_order = 0.
* Patch 6 uses split_huge_page_to_list_to_order() in large pagecache folio
truncation instead of split the large folio all the way down to order-0.
* Patch 7 adds a test API to debugfs and test cases in
split_huge_page_test selftests.
Comments and/or suggestions are welcome.
[1] https://lore.kernel.org/linux-mm/Y%2FblF0GIunm+pRIC@casper.infradead.org/
Zi Yan (7):
mm/memcg: use order instead of nr in split_page_memcg()
mm/page_owner: use order instead of nr in split_page_owner()
mm: memcg: make memcg huge page split support any order split.
mm: page_owner: add support for splitting to any order in split
page_owner.
mm: thp: split huge page to any lower order pages.
mm: truncate: split huge page cache page to a non-zero order if
possible.
mm: huge_memory: enable debugfs to split huge pages to any order.
include/linux/huge_mm.h | 10 +-
include/linux/memcontrol.h | 4 +-
include/linux/page_owner.h | 10 +-
mm/huge_memory.c | 137 ++++++++---
mm/memcontrol.c | 10 +-
mm/page_alloc.c | 8 +-
mm/page_owner.c | 8 +-
mm/truncate.c | 21 +-
.../selftests/mm/split_huge_page_test.c | 225 +++++++++++++++++-
9 files changed, 365 insertions(+), 68 deletions(-)
Comments
On Mon, 3 Apr 2023 16:18:32 -0400 Zi Yan <zi.yan@sent.com> wrote: > File folio supports any order and people would like to support flexible orders > for anonymous folio[1] too. Currently, split_huge_page() only splits a huge > page to order-0 pages, but splitting to orders higher than 0 is also useful. > This patchset adds support for splitting a huge page to any lower order pages > and uses it during file folio truncate operations. This series (and its v1 & v2) don't appear to have much in the way of detailed review. As it's at v3 and has been fairly stable I'll queue it up for some testing now, but I do ask that some reviewers go through it please.
On Tue, 4 Apr 2023, Andrew Morton wrote: > On Mon, 3 Apr 2023 16:18:32 -0400 Zi Yan <zi.yan@sent.com> wrote: > > > File folio supports any order and people would like to support flexible orders > > for anonymous folio[1] too. Currently, split_huge_page() only splits a huge > > page to order-0 pages, but splitting to orders higher than 0 is also useful. > > This patchset adds support for splitting a huge page to any lower order pages > > and uses it during file folio truncate operations. > > This series (and its v1 & v2) don't appear to have much in the way of > detailed review. As it's at v3 and has been fairly stable I'll queue > it up for some testing now, but I do ask that some reviewers go through > it please. Andrew, please don't let this series drift into 6.4-rc1. I've seen a bug or two (I'll point out in response to those patches), but overall I don't see what the justification for the series is: done because it could be done, it seems to me, but liable to add surprises. The cover letter says "splitting to orders higher than 0 is also useful", but it's not clear why; and the infrastructure provided seems unsuited to the one use provided - I'll say more on that truncation patch. Thanks, Hugh
On Sun, 16 Apr 2023 11:11:49 -0700 (PDT) Hugh Dickins <hughd@google.com> wrote: > On Tue, 4 Apr 2023, Andrew Morton wrote: > > On Mon, 3 Apr 2023 16:18:32 -0400 Zi Yan <zi.yan@sent.com> wrote: > > > > > File folio supports any order and people would like to support flexible orders > > > for anonymous folio[1] too. Currently, split_huge_page() only splits a huge > > > page to order-0 pages, but splitting to orders higher than 0 is also useful. > > > This patchset adds support for splitting a huge page to any lower order pages > > > and uses it during file folio truncate operations. > > > > This series (and its v1 & v2) don't appear to have much in the way of > > detailed review. As it's at v3 and has been fairly stable I'll queue > > it up for some testing now, but I do ask that some reviewers go through > > it please. > > Andrew, please don't let this series drift into 6.4-rc1. I have it still parked awaiting some reviewer input. > I've seen a bug or two (I'll point out in response to those patches), > but overall I don't see what the justification for the series is: done > because it could be done, it seems to me, but liable to add surprises. > > The cover letter says "splitting to orders higher than 0 is also useful", > but it's not clear why; and the infrastructure provided seems unsuited > to the one use provided - I'll say more on that truncation patch. OK, I'll drop the series for this cycle.
On 16.04.23 20:11, Hugh Dickins wrote: > On Tue, 4 Apr 2023, Andrew Morton wrote: >> On Mon, 3 Apr 2023 16:18:32 -0400 Zi Yan <zi.yan@sent.com> wrote: >> >>> File folio supports any order and people would like to support flexible orders >>> for anonymous folio[1] too. Currently, split_huge_page() only splits a huge >>> page to order-0 pages, but splitting to orders higher than 0 is also useful. >>> This patchset adds support for splitting a huge page to any lower order pages >>> and uses it during file folio truncate operations. >> >> This series (and its v1 & v2) don't appear to have much in the way of >> detailed review. As it's at v3 and has been fairly stable I'll queue >> it up for some testing now, but I do ask that some reviewers go through >> it please. > > Andrew, please don't let this series drift into 6.4-rc1. > > I've seen a bug or two (I'll point out in response to those patches), > but overall I don't see what the justification for the series is: done > because it could be done, it seems to me, but liable to add surprises. > > The cover letter says "splitting to orders higher than 0 is also useful", > but it's not clear why; and the infrastructure provided seems unsuited > to the one use provided - I'll say more on that truncation patch. I agree. Maybe this patch set is something we want to have in the future once actual consumers that can benefit are in place, such that we can show actual performance numbers with/without. Until then, "365 insertions(+), 68 deletions(-)" certainly needs some reasonable motivation.
On 17 Apr 2023, at 10:20, David Hildenbrand wrote: > On 16.04.23 20:11, Hugh Dickins wrote: >> On Tue, 4 Apr 2023, Andrew Morton wrote: >>> On Mon, 3 Apr 2023 16:18:32 -0400 Zi Yan <zi.yan@sent.com> wrote: >>> >>>> File folio supports any order and people would like to support flexible orders >>>> for anonymous folio[1] too. Currently, split_huge_page() only splits a huge >>>> page to order-0 pages, but splitting to orders higher than 0 is also useful. >>>> This patchset adds support for splitting a huge page to any lower order pages >>>> and uses it during file folio truncate operations. >>> >>> This series (and its v1 & v2) don't appear to have much in the way of >>> detailed review. As it's at v3 and has been fairly stable I'll queue >>> it up for some testing now, but I do ask that some reviewers go through >>> it please. >> >> Andrew, please don't let this series drift into 6.4-rc1. >> >> I've seen a bug or two (I'll point out in response to those patches), >> but overall I don't see what the justification for the series is: done >> because it could be done, it seems to me, but liable to add surprises. >> >> The cover letter says "splitting to orders higher than 0 is also useful", >> but it's not clear why; and the infrastructure provided seems unsuited >> to the one use provided - I'll say more on that truncation patch. > > I agree. Maybe this patch set is something we want to have in the future once actual consumers that can benefit are in place, such that we can show actual performance numbers with/without. Ryan is working on large folio for anonymous pages and has shown promising performance results[1]. This patchset would avoid getting base pages during split if possible. > > Until then, "365 insertions(+), 68 deletions(-)" certainly needs some reasonable motivation. Come on. 225 out of 365 insertions are self tests code. We need motivation to add testing code? [1] https://lore.kernel.org/linux-mm/20230414130303.2345383-1-ryan.roberts@arm.com/ -- Best Regards, Yan, Zi
On 17.04.23 21:26, Zi Yan wrote: > On 17 Apr 2023, at 10:20, David Hildenbrand wrote: > >> On 16.04.23 20:11, Hugh Dickins wrote: >>> On Tue, 4 Apr 2023, Andrew Morton wrote: >>>> On Mon, 3 Apr 2023 16:18:32 -0400 Zi Yan <zi.yan@sent.com> wrote: >>>> >>>>> File folio supports any order and people would like to support flexible orders >>>>> for anonymous folio[1] too. Currently, split_huge_page() only splits a huge >>>>> page to order-0 pages, but splitting to orders higher than 0 is also useful. >>>>> This patchset adds support for splitting a huge page to any lower order pages >>>>> and uses it during file folio truncate operations. >>>> >>>> This series (and its v1 & v2) don't appear to have much in the way of >>>> detailed review. As it's at v3 and has been fairly stable I'll queue >>>> it up for some testing now, but I do ask that some reviewers go through >>>> it please. >>> >>> Andrew, please don't let this series drift into 6.4-rc1. >>> >>> I've seen a bug or two (I'll point out in response to those patches), >>> but overall I don't see what the justification for the series is: done >>> because it could be done, it seems to me, but liable to add surprises. >>> >>> The cover letter says "splitting to orders higher than 0 is also useful", >>> but it's not clear why; and the infrastructure provided seems unsuited >>> to the one use provided - I'll say more on that truncation patch. >> >> I agree. Maybe this patch set is something we want to have in the future once actual consumers that can benefit are in place, such that we can show actual performance numbers with/without. > > Ryan is working on large folio for anonymous pages and has shown promising performance > results[1]. This patchset would avoid getting base pages during split if possible. > Yes, I know. And it would be great to get some actual numbers with/without your patches to show that this optimization actually matters in practice. Unrelated, your cover letter mentions "file folio truncate operations.". Would it also apply to FALLOC_FL_PUNCH_HOLE, when partially zapping a THP? >> >> Until then, "365 insertions(+), 68 deletions(-)" certainly needs some reasonable motivation. > > Come on. 225 out of 365 insertions are self tests code. We need motivation to add > testing code? Well, if you add feature X and the tests target feature X, then certainly having the tests require the same motivation as feature X. But yeah, the actual kernel code change is smaller than it looks at first sight.
On 18 Apr 2023, at 6:29, David Hildenbrand wrote: > On 17.04.23 21:26, Zi Yan wrote: >> On 17 Apr 2023, at 10:20, David Hildenbrand wrote: >> >>> On 16.04.23 20:11, Hugh Dickins wrote: >>>> On Tue, 4 Apr 2023, Andrew Morton wrote: >>>>> On Mon, 3 Apr 2023 16:18:32 -0400 Zi Yan <zi.yan@sent.com> wrote: >>>>> >>>>>> File folio supports any order and people would like to support flexible orders >>>>>> for anonymous folio[1] too. Currently, split_huge_page() only splits a huge >>>>>> page to order-0 pages, but splitting to orders higher than 0 is also useful. >>>>>> This patchset adds support for splitting a huge page to any lower order pages >>>>>> and uses it during file folio truncate operations. >>>>> >>>>> This series (and its v1 & v2) don't appear to have much in the way of >>>>> detailed review. As it's at v3 and has been fairly stable I'll queue >>>>> it up for some testing now, but I do ask that some reviewers go through >>>>> it please. >>>> >>>> Andrew, please don't let this series drift into 6.4-rc1. >>>> >>>> I've seen a bug or two (I'll point out in response to those patches), >>>> but overall I don't see what the justification for the series is: done >>>> because it could be done, it seems to me, but liable to add surprises. >>>> >>>> The cover letter says "splitting to orders higher than 0 is also useful", >>>> but it's not clear why; and the infrastructure provided seems unsuited >>>> to the one use provided - I'll say more on that truncation patch. >>> >>> I agree. Maybe this patch set is something we want to have in the future once actual consumers that can benefit are in place, such that we can show actual performance numbers with/without. >> >> Ryan is working on large folio for anonymous pages and has shown promising performance >> results[1]. This patchset would avoid getting base pages during split if possible. >> > Yes, I know. And it would be great to get some actual numbers with/without your patches to show that this optimization actually matters in practice. Sure. Will try to add perf numbers in the next version. > > Unrelated, your cover letter mentions "file folio truncate operations.". Would it also apply to FALLOC_FL_PUNCH_HOLE, when partially zapping a THP? Yes. In the self tests, I have fallocate(fd, FALLOC_FL_PUNCH_HOLE|FALLOC_FL_KEEP_SIZE, offset[j], len[j]); and it uses the truncate operation I updated in patch 6. > >>> >>> Until then, "365 insertions(+), 68 deletions(-)" certainly needs some reasonable motivation. >> >> Come on. 225 out of 365 insertions are self tests code. We need motivation to add >> testing code? > > Well, if you add feature X and the tests target feature X, then certainly having the tests require the same motivation as feature X. But yeah, the actual kernel code change is smaller than it looks at first sight. > > -- > Thanks, > > David / dhildenb -- Best Regards, Yan, Zi
On 13 Feb 2024, at 7:30, Pankaj Raghav (Samsung) wrote: > Hi Zi yan, > >> From: Zi Yan <ziy@nvidia.com> >> >> Hi all, >> >> File folio supports any order and people would like to support flexible orders >> for anonymous folio[1] too. Currently, split_huge_page() only splits a huge >> page to order-0 pages, but splitting to orders higher than 0 is also useful. >> This patchset adds support for splitting a huge page to any lower order pages >> and uses it during file folio truncate operations. >> > > I recently posted patches to enable block size > page size(Large Block > Sizes) in XFS[1]. > The main idea of LBS is to have a notion of minimum order in the > page cache that corresponds to the filesystem block size. > > Ability to split a folio based on a given order is something that would > definitely optimize the LBS implementation. > > The current implementation refuses to split a large folio if it has a > minimum order set in the page cache [2]. What we would like to have instead > is to split it based on the minimum order. The main use is of course being > able to free some folios during partial truncate operation. > > Your patch was also suggested by willy during our LPC talk[3]. > > I tried rebasing your patch and there were a lot of non-trivial conflicts. > Is there any plans on sending a new version? Sure. I am going to rebase and send a new version out. > > > [1] https://lore.kernel.org/linux-xfs/20240213093713.1753368-1-kernel@pankajraghav.com/ > [2] https://lore.kernel.org/linux-xfs/20240213093713.1753368-9-kernel@pankajraghav.com/ > [3] https://youtu.be/ar72r5Xf7x4?si=XDb-g7SSIgS-5TkP&t=1457 > > -- > Pankaj -- Best Regards, Yan, Zi