On Sun, Dec 03, 2023 at 11:11:14PM +0300, Viacheslav Dubeyko wrote: > So, why do we correct the order to zero always if order is equal to one? > It sounds for me like incorrect logic. Even if we consider the troubles > with memory allocation, then we will try allocate, for example, 16K, exclude 8K, > and, finally, will try to allocate 4K. This logic puzzles me anyway. > Do I miss something here? The problem I'm trying to avoid is that when we allocate an order-1 folio, we only have two struct pages for the folio. At the moment, we have the deferred_list stored in the third struct page of the folio. There isn't quite space to squeeze it into the second struct page on 32-bit systems -- we have _flags_1 flags _head_1 lru.head _folio_avail lru.tail _entire_mapcount mapping _nr_pages_mapped index _pincount private after that we'd start to collide with _mapcount (which is still used per-page) and _refcount (which must be 0 on tail pages). We have one word available (_folio_avail), but we'd need two to fit in a list_head. We might be able to reengineer things so that we don't need a list_head for deferred_list. eg we could store deferred-split folios in an xarray and only store the index in the folio. Or we could decline to deferred-split folios that are order-1. I haven't looked into it in detail, but I feel like this might be an acceptable approach. I was talking with Darrick on Friday and he convinced me that this is something we're going to need to fix sooner rather than later for the benefit of devices with block size 8kB. So it's definitely on my todo list, but I haven't investigated in any detail yet. Thanks for raising the issue; it gave me a good opportunity to explain my current thinking on the problem. Adding linux-mm for insights from the MM audience.
