Re: [Patch v2 2/2] mm/page_alloc.c: define node_order with all zero

[Wei Yang <richard.weiyang@gmail.com>]

On Sat, Mar 28, 2020 at 06:30:00PM -0700, John Hubbard wrote:
>On 3/27/20 7:56 PM, Wei Yang wrote:
>...
>> > Further note: On my current testing .config, I've got MAX_NUMNODES set to 64, which makes
>> > 256 bytes required for node_order array. 256 bytes on a 16KB stack is a little bit above
>> > my mental watermark for "that's too much in today's kernels".
>> > 
>> 
>> Thanks for your explanation. I would keep this in mind.
>> 
>> Now I have one more question, hope it won't sound silly. (16KB / 256) = 64,
>> this means if each function call takes 256 space on stack, the max call depth
>> is 64. So how deep a kernel function call would be? or expected to be?
>> 
>
>64 is quite a bit deeper call depth than we expect to see. So 256 bytes on the stack
>is not completely indefensible, but it's getting close. But worse, that's just an
>example based on my .config choices. And (as Baoquan just pointed out) it can be much
>bigger. (And the .config variable is an exponent, not linear, so it gets exciting fast.)
>In fact, you could overrun the stack directly, with say CONFIG_NODES_SHIFT = 14.
>

Thanks :-)

This is better not to use "big" structure on stack.

>> Also because of the limit space on stack, recursive function is not welcome in
>> kernel neither. Am I right?
>> 
>Yes, that is correct.
>
>thanks,
>-- 
>John Hubbard
>NVIDIA

-- 
Wei Yang
Help you, Help me