On 10 Dec 2024, at 15:41, Zi Yan wrote: > 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. I am going to add two functions: split_huge_page_supported(folio, new_order) and folio_split_support(folio, new_order) to perform the order and folio->mapping checks at the beginning of __folio_split(). So truncate and other potential callers can make the right function call. Best Regards, Yan, Zi
