From: sashiko-bot@kernel.org
To: "Fang Xieyan" <fangxy@xiaopeng.com>,
"Andrew Morton" <akpm@linux-foundation.org>,
"David Hildenbrand" <david@kernel.org>, "Zi Yan" <ziy@nvidia.com>,
"Matthew Wilcox" <willy@infradead.org>, "Jan Kara" <jack@suse.cz>,
"Hugh Dickins" <hughd@google.com>,
"Carlos Maiolino" <cem@kernel.org>
Cc: "Baolin Wang" <baolin.wang@linux.alibaba.com>,
"Liam R . Howlett" <liam@infradead.org>,
"Nico Pache" <nico.pache@linux.dev>,
"Ryan Roberts" <ryan.roberts@arm.com>,
"Dev Jain" <dev.jain@arm.com>, "Barry Song" <baohua@kernel.org>,
"Lance Yang" <lance.yang@linux.dev>,
"Usama Arif" <usama.arif@linux.dev>,
"Kiryl Shutsemau" <kas@kernel.org>,
"Lorenzo Stoakes" <ljs@kernel.org>,
"Vlastimil Babka" <vbabka@kernel.org>,
"Mike Rapoport" <rppt@kernel.org>,
"Suren Baghdasaryan" <surenb@google.com>,
"Michal Hocko" <mhocko@suse.com>,
"Muchun Song" <muchun.song@linux.dev>,
"Kairui Song" <kasong@tencent.com>,
linux-mm@kvack.org, "Liu Chao" <liuc63@xiaopeng.com>
Subject: Re: [RFC PATCH 1/3] mm: move folio split code into mm/folio_split.c
Date: Wed, 11 Nov 2026 03:52:27 +0000 [thread overview]
Message-ID: <sashiko-outbox-208240@kernel.org> (raw)
In-Reply-To: <20261110035205.3036-2-fangxy@xiaopeng.com>
Thank you for your contribution! Sashiko AI review found 3 potential
issues to consider:
- [Medium] mm: missing linux/page_idle.h include in mm/folio_split.c
breaks 32-bit build
- [Low] mm: missing mm/folio_split.c kernel-doc in
Documentation/core-api/mm-api.rst
- [Low] mm: commit message misidentifies caller of
folio_reset_partially_mapped()
--
commit 6a62de8a2d72809396114752978350fdd94905
Author: Fang Xieyan <fangxy@xiaopeng.com>
mm: move folio split code into mm/folio_split.c
This commit moves the folio split implementation out of mm/huge_memory.c into
mm/folio_split.c and exposes folio_reset_partially_mapped() in mm/internal.h.
> - folio_reset_partially_mapped() is no longer static and gains a
> declaration in mm/internal.h, because deferred_split_scan() in
> huge_memory.c keeps calling it,
[Severity: Low]
In mm/huge_memory.c, __folio_unqueue_deferred_split() is the caller of
folio_reset_partially_mapped(), not deferred_split_scan().
> diff --git a/mm/folio_split.c b/mm/folio_split.c
> new file mode 100644
> index 0000000000000..7770d8215a076
> --- /dev/null
> +++ b/mm/folio_split.c
> @@ -0,0 +1,947 @@
[ ... ]
> +#include <linux/page_owner.h>
> +#include <linux/pgalloc_tag.h>
> +#include <linux/vmstat.h>
> +
> +#include "internal.h"
> +#include "swap.h"
[ ... ]
> +static void __split_folio_to_order(struct folio *folio, int old_order,
> + int new_order)
> +{
[ ... ]
> + if (folio_test_young(folio))
> + folio_set_young(new_folio);
> + if (folio_test_idle(folio))
> + folio_set_idle(new_folio);
[Severity: Medium]
Does mm/folio_split.c need to include <linux/page_idle.h> (and drop it from
mm/huge_memory.c)?
When CONFIG_PAGE_IDLE_FLAG=y and !CONFIG_64BIT, include/linux/page-flags.h
omits folio_test_young(), folio_set_young(), folio_test_idle() and
folio_set_idle(), and defines them in include/linux/page_idle.h instead, so
32-bit builds with CONFIG_PAGE_IDLE_FLAG=y fail with implicit declaration
errors here.
[ ... ]
> +/**
> + * folio_split() - split a folio at @split_at to a @new_order folio
> + * @folio: folio to split
> + * @new_order: the order of the new folio
> + * @split_at: a page within the new folio
> + * @list: after-split folios are added to @list if not null, otherwise to LRU
> + * list
[Severity: Low]
Documentation/core-api/mm-api.rst includes .. kernel-doc:: mm/huge_memory.c
without function filters. Should .. kernel-doc:: mm/folio_split.c be added
there as well so the six moved kernel-doc comments (__split_frozen_folio(),
folio_check_splittable(), __folio_split(), folio_split_unmapped(),
folio_split() and min_order_for_split()) are not dropped from the generated
documentation?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261110035205.3036-1-fangxy@xiaopeng.com?part=1
next prev parent reply other threads:[~2026-11-11 3:52 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-10 3:52 [RFC PATCH 0/3] mm: enable filesystem page-cache large folios without THP Fang Xieyan
2026-11-10 3:52 ` [RFC PATCH 1/3] mm: move folio split code into mm/folio_split.c Fang Xieyan
2026-11-11 3:52 ` sashiko-bot [this message]
2026-11-10 3:52 ` [RFC PATCH 2/3] mm: build file-backed folio splitting with CONFIG_LARGE_FOLIO Fang Xieyan
2026-11-10 3:52 ` [RFC PATCH 3/3] mm: enable filesystem page-cache large folios without THP Fang Xieyan
2026-11-10 21:09 ` Michal Hocko
2026-11-11 3:52 ` sashiko-bot
2026-11-10 4:01 ` [RFC PATCH 0/3] " Zi Yan
2026-11-10 4:10 ` Zi Yan
2026-11-10 4:11 ` Zi Yan
2026-11-11 7:22 ` David Hildenbrand (Arm)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=sashiko-outbox-208240@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=baohua@kernel.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=cem@kernel.org \
--cc=david@kernel.org \
--cc=dev.jain@arm.com \
--cc=fangxy@xiaopeng.com \
--cc=hughd@google.com \
--cc=jack@suse.cz \
--cc=kas@kernel.org \
--cc=kasong@tencent.com \
--cc=lance.yang@linux.dev \
--cc=liam@infradead.org \
--cc=linux-mm@kvack.org \
--cc=liuc63@xiaopeng.com \
--cc=ljs@kernel.org \
--cc=mhocko@suse.com \
--cc=muchun.song@linux.dev \
--cc=nico.pache@linux.dev \
--cc=rppt@kernel.org \
--cc=ryan.roberts@arm.com \
--cc=sashiko-reviews@lists.linux.dev \
--cc=surenb@google.com \
--cc=usama.arif@linux.dev \
--cc=vbabka@kernel.org \
--cc=willy@infradead.org \
--cc=ziy@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox