linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: John Hubbard <jhubbard@nvidia.com>
To: Wei Yang <richard.weiyang@gmail.com>
Cc: <akpm@linux-foundation.org>, <linux-mm@kvack.org>,
	<linux-kernel@vger.kernel.org>, <jgg@ziepe.ca>,
	<david@redhat.com>
Subject: Re: [Patch v2 2/2] mm/page_alloc.c: define node_order with all zero
Date: Sat, 28 Mar 2020 18:30:00 -0700	[thread overview]
Message-ID: <b1b41da1-2ced-8bb8-7162-e5c820543244@nvidia.com> (raw)
In-Reply-To: <20200328025605.cpnbnavl27pphr7g@master>

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.

  
> 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


  reply	other threads:[~2020-03-29  1:30 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-27 22:01 [Patch v2 1/2] mm/page_alloc.c: use NODE_MASK_NONE define used_mask Wei Yang
2020-03-27 22:01 ` [Patch v2 2/2] mm/page_alloc.c: define node_order with all zero Wei Yang
2020-03-27 22:37   ` John Hubbard
2020-03-27 23:18     ` Jason Gunthorpe
2020-03-28  0:27       ` Wei Yang
2020-03-28  0:26     ` Wei Yang
2020-03-28  0:51       ` Baoquan He
2020-03-28  0:59       ` John Hubbard
2020-03-28  1:10         ` Wei Yang
2020-03-28  1:28           ` John Hubbard
2020-03-28  2:56             ` Wei Yang
2020-03-29  1:30               ` John Hubbard [this message]
2020-03-29  2:31                 ` Wei Yang
2020-03-28 11:25             ` Baoquan He

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b1b41da1-2ced-8bb8-7162-e5c820543244@nvidia.com \
    --to=jhubbard@nvidia.com \
    --cc=akpm@linux-foundation.org \
    --cc=david@redhat.com \
    --cc=jgg@ziepe.ca \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=richard.weiyang@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox