On 5 Aug 2021, at 15:16, Christian König wrote: > Am 05.08.21 um 21:02 schrieb Zi Yan: >> From: Zi Yan <ziy@xxxxxxxxxx> >> >> This prepares for the upcoming changes to make MAX_ORDER a boot time >> parameter instead of compilation time constant. All static arrays with >> MAX_ORDER size are converted to pointers and their memory is allocated >> at runtime. > > Well in general I strongly suggest to not use the patter kmalloc(sizeof(some struct) * MAX_ORDER,...) instead use kmalloc_array, kcalloc etc.. > > Then when a array is embedded at the end of a structure you can use a trailing array and the struct_size() macro to determine the allocation size. Sure. Will fix it. > > Additional to that separating the patch into changes for TTM to make the maximum allocation order independent from MAX_ORDER would be rather good to have I think. Can you elaborate a little bit more on “make the maximum allocation order independent from MAX_ORDER”? From what I understand of ttm_pool_alloc(), it tries to get num_pages pages by allocating as large pages as possible, starting from MAX_ORDER. What is the rationale behind this algorithm? Why not just call alloc_page(order=0) num_pages times? Is it mean to reduce the number of calls to alloc_page? The allocated pages do not need to get as high as MAX_ORDER, is that the case? If yes, I probably can keep ttm pool as static arrays with length of MIN_MAX_ORDER, which I introduce in Patch 14 as the lower bound of boot time parameter MAX_ORDER. Let me know your thoughts. Thanks. — Best Regards, Yan, Zi
Attachment:
signature.asc
Description: OpenPGP digital signature
