[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ee92b309-db6d-416c-97ab-25abf8b12957@redhat.com>
Date: Tue, 10 Dec 2024 21:12:07 +0100
From: David Hildenbrand <david@...hat.com>
To: Zi Yan <ziy@...dia.com>, linux-mm@...ck.org,
"Kirill A . Shutemov" <kirill.shutemov@...ux.intel.com>,
"Matthew Wilcox (Oracle)" <willy@...radead.org>
Cc: Ryan Roberts <ryan.roberts@....com>, Hugh Dickins <hughd@...gle.com>,
Yang Shi <yang@...amperecomputing.com>, Miaohe Lin <linmiaohe@...wei.com>,
Kefeng Wang <wangkefeng.wang@...wei.com>, Yu Zhao <yuzhao@...gle.com>,
John Hubbard <jhubbard@...dia.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH RESEND v3 6/9] mm/truncate: use folio_split() for truncate
operation.
On 05.12.24 01:18, Zi Yan wrote:
> Instead of splitting the large folio uniformly during truncation, use
> buddy allocator like split at the start of truncation range to minimize
> the number of resulting folios.
>
> 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].
But isn't that making things worse that they are today? Imagine
fallocate() on a shmem file where we won't be freeing memory?
--
Cheers,
David / dhildenb
Powered by blists - more mailing lists