On Thu, Oct 29, 2020 at 12:02 AM Hillf Danton hdanton@sina.com wrote:
On Thu, 29 Oct 2020 00:16:22 +0000 John Stultz wrote:
+#define HIGH_ORDER_GFP (((GFP_HIGHUSER | __GFP_ZERO | __GFP_NOWARN \
| __GFP_NORETRY) & ~__GFP_RECLAIM) \| __GFP_COMP)+#define LOW_ORDER_GFP (GFP_HIGHUSER | __GFP_ZERO | __GFP_COMP) +static gfp_t order_flags[] = {HIGH_ORDER_GFP, LOW_ORDER_GFP, LOW_ORDER_GFP}; +static const unsigned int orders[] = {8, 4, 0}; +#define NUM_ORDERS ARRAY_SIZE(orders)
A two-line comment helps much understand the ORDERs above if it specifies the reasons behind the detour to HPAGE_PMD_ORDER and PAGE_ALLOC_COSTLY_ORDER.
Thanks so much for the review and feedback!
So yes, this was pulled from ION's system heap: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/driv...
But adding __GFP_COMP as that's added by ION in the pagepool code I didn't include: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/driv...
I unfortunately don't have a lot of detail on the exact rationale (other than what I can pull from the commit log), I suspect it has to do experiential knowledge of the majority of graphics buffers being small multiples of 1M or 64K.
But I do agree some rationale in a comment would be helpful, and will try to add that.
As for your comment on HPAGE_PMD_ORDER (9 on arm64/arm) and PAGE_ALLOC_COSTLY_ORDER(3), I'm not totally sure I understand your question? Are you suggesting those values would be more natural orders to choose from?
Thanks again! -john