[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180816182220.dmlun5edcbf4lspj@xakep.localdomain>
Date: Thu, 16 Aug 2018 18:22:21 +0000
From: Pasha Tatashin <Pavel.Tatashin@...rosoft.com>
To: Oscar Salvador <osalvador@...hadventures.net>
CC: Andrew Morton <akpm@...ux-foundation.org>,
"mhocko@...e.com" <mhocko@...e.com>,
"vbabka@...e.cz" <vbabka@...e.cz>,
"dan.j.williams@...el.com" <dan.j.williams@...el.com>,
"yasu.isimatu@...il.com" <yasu.isimatu@...il.com>,
"jonathan.cameron@...wei.com" <jonathan.cameron@...wei.com>,
"david@...hat.com" <david@...hat.com>,
"linux-mm@...ck.org" <linux-mm@...ck.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Oscar Salvador <osalvador@...e.de>
Subject: Re: [PATCH v3 3/4] mm/memory_hotplug: Refactor
unregister_mem_sect_under_nodes
> > d) What's the maximum number of nodes, ever? Perhaps we can always
> > fit a nodemask_t onto the stack, dunno.
>
> Right now, we define the maximum as NODES_SHIFT = 10, so:
>
> 1 << 10 = 1024 Maximum nodes.
>
> Since this makes only 128 bytes, I wonder if we can just go ahead and define a nodemask_t
> whithin the stack.
> 128 bytes is not that much, is it?
Yeah, sue stack here, 128b is tiny. This also will solve Andrew's point of having an untested path when alloc fails, and simplify the patch overall.
Thank you,
Pavel
Powered by blists - more mailing lists