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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 21 Jun 2013 17:19:48 +0800
From:	Tang Chen <tangchen@...fujitsu.com>
To:	Tejun Heo <tj@...nel.org>
CC:	yinghai@...nel.org, tglx@...utronix.de, mingo@...e.hu,
	hpa@...or.com, akpm@...ux-foundation.org, trenn@...e.de,
	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/20/2013 02:17 PM, Tejun Heo wrote:
......
>
> I was suggesting two separate things.
>
> * As memblock allocator can relocate itself.  There's no point in
>    avoiding setting NUMA node while parsing and registering NUMA
>    topology.  Just parse and register NUMA info and later tell it to
>    relocate itself out of hot-pluggable node.  A number of patches in
>    the series is doing this dancing - carefully reordering NUMA
>    probing.  No need to do that.  It's really fragile thing to do.
>
> * Once you get the above out of the way, I don't think there are a lot
>    of permanent allocations in the way before NUMA is initialized.
>    Re-order the remaining ones if that's cleaner to do.  If that gets
>    overly messy / fragile, copying them around or freeing and reloading
>    afterwards could be an option too.

memblock allocator can relocate itself, but it cannot relocate the memory
it allocated for users. There could be some pointers pointing to these
memory ranges. If we do the relocation, how to update these pointers ?

Or, do you mean modify the pagetable ?  I don't think so.

So would you please tell me more about how to do the relocation ?

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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ