[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [PATCH v35 1/5] mm: support to get hints of free page blocks
On 07/11/2018 01:33 AM, Linus Torvalds wrote:
NAK. On Tue, Jul 10, 2018 at 2:56 AM Wei Wang <email@example.com> wrote:+ + buf_page = list_first_entry_or_null(pages, struct page, lru); + if (!buf_page) + return -EINVAL; + buf = (__le64 *)page_address(buf_page);Stop this garbage. Why the hell would you pass in some crazy "liost of pages" that uses that lru list? That's just insane shit. Just pass in a an array to fill in. No idiotic games like this with odd list entries (what's the locking?) and crazy casting to So if you want an array of page addresses, pass that in as such. If you want to do it in a page, do it with u64 *array = page_address(page); int nr = PAGE_SIZE / sizeof(u64); and now you pass that array in to the thing. None of this completely insane crazy crap interfaces. Plus, I still haven't heard an explanation for why you want so many pages in the first place, and why you want anything but MAX_ORDER-1.
Sorry for missing that explanation.We only get addresses of the "MAX_ORDER-1" blocks into the array. The max size of the array that could be allocated by kmalloc is KMALLOC_MAX_SIZE (i.e. 4MB on x86). With that max array, we could load "4MB / sizeof(u64)" addresses of "MAX_ORDER-1" blocks, that is, 2TB free memory at most. We thought about removing that 2TB limitation by passing in multiple such max arrays (a list of them).
But 2TB has been enough for our use cases so far, and agree it would be better to have a simpler API in the first place. So I plan to go back to the previous version of just passing in one simple array (https://lkml.org/lkml/2018/6/15/21) if no objections.