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]
Message-ID: <20130618165753.GB4553@dhcp-192-168-178-175.profitbricks.localdomain>
Date:	Tue, 18 Jun 2013 18:57:54 +0200
From:	Vasilis Liaskovitis <vasilis.liaskovitis@...fitbricks.com>
To:	Tang Chen <tangchen@...fujitsu.com>
Cc:	tglx@...utronix.de, mingo@...e.hu, hpa@...or.com,
	akpm@...ux-foundation.org, tj@...nel.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, 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: [Part2 PATCH v4 08/15] x86, numa: Save nid when reserve memory
 into memblock.reserved[].

Hi Tang,

On Thu, Jun 13, 2013 at 09:03:32PM +0800, Tang Chen wrote:
> Since we introduced numa_sync_memblock_nid synchronize nid info in
> memblock.reserved[] and numa_meminfo, when numa_meminfo has been
> initialized, we need to save the nid into memblock.reserved[] when
> we reserve memory.

thanks for the updated patches.
I tested linux-next next-20130706 +part1+part2+part3 in a VM, hot-plugging
memory and rebooting with movablecore=acpi. I think with this patch and 9/15
we get the correct nids and the expected behaviour for the "movablecore=acpi"
option.

However, patches 21,22 of part1 and all part3 patches increase kernel usage
of local node memory by putting pagetables local to those nodes. Are these
pagetable pages accounted in part2's memblock_kernel_nodemask? It looks like
part1 and part3 of these patchsets contradict or make the goal of part2 more
difficult to achieve. (I will send more comments for part3 separately).

thanks,

- Vasilis
--
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