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
