From: Oscar Salvador <osalvador@techadventures.net>
To: Michal Hocko <mhocko@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
tglx@linutronix.de, joe@perches.com, arnd@arndb.de,
gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, Oscar Salvador <osalvador@suse.de>
Subject: Re: [PATCH] mm: Fix comment for NODEMASK_ALLOC
Date: Tue, 21 Aug 2018 14:30:24 +0200 [thread overview]
Message-ID: <20180821123024.GA9489@techadventures.net> (raw)
In-Reply-To: <20180821121734.GA29735@dhcp22.suse.cz>
On Tue, Aug 21, 2018 at 02:17:34PM +0200, Michal Hocko wrote:
> We do have CONFIG_NODES_SHIFT=10 in our SLES kernels for quite some
> time (around SLE11-SP3 AFAICS).
>
> Anyway, isn't NODES_ALLOC over engineered a bit? Does actually even do
> larger than 1024 NUMA nodes? This would be 128B and from a quick glance
> it seems that none of those functions are called in deep stacks. I
> haven't gone through all of them but a patch which checks them all and
> removes NODES_ALLOC would be quite nice IMHO.
No, maximum we can get is 1024 NUMA nodes.
I checked this when writing another patch [1], and since having gone
through all archs Kconfigs, CONFIG_NODES_SHIFT=10 is the limit.
NODEMASK_ALLOC gets only called from:
- unregister_mem_sect_under_nodes() (not anymore after [1])
- __nr_hugepages_store_common (This does not seem to have a deep stack, we could use a normal nodemask_t)
But is also used for NODEMASK_SCRATCH (mainly used for mempolicy):
struct nodemask_scratch {
nodemask_t mask1;
nodemask_t mask2;
};
that would make 256 bytes in case CONFIG_NODES_SHIFT=10.
I am not familiar with mempolicy code, I am not sure if we can do without that and
figure out another way to achieve the same.
[1] https://patchwork.kernel.org/patch/10566673/#22179663
--
Oscar Salvador
SUSE L3
next prev parent reply other threads:[~2018-08-21 12:30 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-20 8:55 [PATCH] mm: Fix comment for NODEMASK_ALLOC Oscar Salvador
2018-08-20 21:24 ` Andrew Morton
2018-08-21 12:17 ` Michal Hocko
2018-08-21 12:30 ` Oscar Salvador [this message]
2018-08-21 12:51 ` Michal Hocko
2018-08-21 12:58 ` Oscar Salvador
2018-08-21 20:51 ` Andrew Morton
2018-08-23 10:51 ` Oscar Salvador
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=20180821123024.GA9489@techadventures.net \
--to=osalvador@techadventures.net \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=gregkh@linuxfoundation.org \
--cc=joe@perches.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=osalvador@suse.de \
--cc=tglx@linutronix.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.