On 26 Feb 2025, at 16:00, Zi Yan wrote: > Instead of splitting the large folio uniformly during truncation, try to > use buddy allocator like split at the start of truncation range to > minimize the number of resulting folios if it is supported. > try_folio_split() is introduced to use folio_split() if supported and fall > back to uniform split otherwise. > > For example, to truncate a order-4 folio > [0, 1, 2, 3, 4, 5, ..., 15] > between [3, 10] (inclusive), folio_split() splits the folio to > [0,1], [2], [3], [4..7], [8..15] and [3], [4..7] can be dropped and > [8..15] is kept with zeros in [8..10], then another folio_split() is > done at 10, so [8..10] can be dropped. > > One possible optimization is to make folio_split() to split a folio based > on a given range, like [3..10] above. But that complicates folio_split(), > so it will be investigated when necessary. > > Signed-off-by: Zi Yan <ziy@xxxxxxxxxx> > Cc: Baolin Wang <baolin.wang@xxxxxxxxxxxxxxxxx> > Cc: David Hildenbrand <david@xxxxxxxxxx> > Cc: Hugh Dickins <hughd@xxxxxxxxxx> > Cc: John Hubbard <jhubbard@xxxxxxxxxx> > Cc: Kefeng Wang <wangkefeng.wang@xxxxxxxxxx> > Cc: Kirill A. Shuemov <kirill.shutemov@xxxxxxxxxxxxxxx> > Cc: Matthew Wilcox <willy@xxxxxxxxxxxxx> > Cc: Miaohe Lin <linmiaohe@xxxxxxxxxx> > Cc: Ryan Roberts <ryan.roberts@xxxxxxx> > Cc: Yang Shi <yang@xxxxxxxxxxxxxxxxxxxxxx> > Cc: Yu Zhao <yuzhao@xxxxxxxxxx> > Cc: Kairui Song <kasong@xxxxxxxxxxx> > --- > include/linux/huge_mm.h | 36 ++++++++++++++++++++++++++++++++++++ > mm/huge_memory.c | 6 +++--- > mm/truncate.c | 31 ++++++++++++++++++++++++++++++- > 3 files changed, 69 insertions(+), 4 deletions(-) > Hi Andrew, Can you fold the patch below to this one? I find the issue based on the syzbot report[1]. Thanks. [1] https://lore.kernel.org/linux-mm/67c38d10.050a0220.dc10f.016d.GAE@xxxxxxxxxx/
