Re: [PATCH RESEND v3 6/9] mm/truncate: use folio_split() for truncate operation.

[Zi Yan <ziy@nvidia.com>]

On 10 Dec 2024, at 15:12, David Hildenbrand wrote:

> 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?

You mean [8..10] are kept? Yes, it is worse. And the solution would be
split at both 3 and 10. For now folio_split() returns -EINVAL for
shmem mappings, but that means I have a bug in this patch. The newly added
split_folio_at() needs to retry uniform split if buddy allocator like
split returns with -EINVAL, otherwise, shmem truncate will no longer
split folios after this patch.

Thank you for checking the patch. I will fix it in the next version.

In terms of [8..10] not being freed, I need to think about a proper interface
to pass more than one split points as a future improvement.

Best Regards,
Yan, Zi