Messages in this thread |  | | Date | Sun, 29 Mar 2020 02:31:04 +0000 | From | Wei Yang <> | Subject | Re: [Patch v2 2/2] mm/page_alloc.c: define node_order with all zero |
| |
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
|  |