linux-kernel - Re: [Part1 PATCH v5 00/22] x86, ACPI, numa: Parse numa info earlier

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 18 Jun 2013 13:47:16 +0800
From:	Tang Chen <tangchen@...fujitsu.com>
To:	Tejun Heo <tj@...nel.org>
CC:	tglx@...utronix.de, mingo@...e.hu, hpa@...or.com,
	akpm@...ux-foundation.org, trenn@...e.de, yinghai@...nel.org,
	jiang.liu@...wei.com, wency@...fujitsu.com, laijs@...fujitsu.com,
	isimatu.yasuaki@...fujitsu.com, mgorman@...e.de,
	minchan@...nel.org, mina86@...a86.com, gong.chen@...ux.intel.com,
	vasilis.liaskovitis@...fitbricks.com, lwoodman@...hat.com,
	riel@...hat.com, jweiner@...hat.com, prarit@...hat.com,
	x86@...nel.org, linux-doc@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [Part1 PATCH v5 00/22] x86, ACPI, numa: Parse numa info earlier

Hi tj,

On 06/18/2013 10:03 AM, Tejun Heo wrote:
......
>
> So, can you please explain why you're doing the above?  What are you
> trying to achieve in the end and why is this the best approach?  This
> is all for memory hotplug, right?

Yes, this is all for memory hotplug.

[why]
At early boot time (before parsing SRAT), memblock will allocate memory
for kernel to use. But the memory could be hotpluggable memory because
at such an early time, we don't know which memory is hotpluggable. This
will cause hotpluggable memory un-hotpluggable. What we are trying to
do is to prevent memblock from allocating hotpluggable memory.

[approach]
Parse SRAT earlier before memblock starts to work, because there is a
bit in SRAT specifying which memory is hotpluggable.

I'm not saying this is the best approach. I can also see that this
patch-set touches a lot of boot code. But i think parsing SRAT earlier
is reasonable because this is the only way for now to know which memory
is hotpluggable from firmware.

>
> I can understand the part where you're move NUMA discovery before
> initializations which will get allocated permanent addresses in the
> wrong nodes, but trying to do the same with memblock itself is making
> the code extremely fragile.  It's nasty because there's nothing
> apparent which seems to necessitate such ordering.  The ordering looks
> rather arbitrary but changing the orders will subtly break memory
> hotplug support, which is a really bad way to structure the code.
>
> Can't you just move memblock arrays after NUMA init is complete?
> That'd be a lot simpler and way more robust than the proposed changes,
> no?

Sorry, I don't quite understand the approach you are suggesting. If we
move memblock arrays, we need to update all the pointers pointing to
the moved memory. How can we do this ?

Thanks. :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/