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] [day] [month] [year] [list]
Message-ID: <51C14C5E.6090501@cn.fujitsu.com>
Date:	Wed, 19 Jun 2013 14:14:54 +0800
From:	Tang Chen <tangchen@...fujitsu.com>
To:	Vasilis Liaskovitis <vasilis.liaskovitis@...fitbricks.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 Vasilis,

Thanks for reviewing. :)

On 06/19/2013 12:57 AM, Vasilis Liaskovitis wrote:
......
>
> 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

No, they are not. What I wanted to acheve was that the local pagetable pages
are transparent to users. For a movable node (all memory is hotpluggable),
seeing from users level, they think all the node's memory is not used by 
the
kernel. Actually pagetable pages are used by the kernel, but users don't 
know
it, and they don't care about it.

And also, memblock_kernel_nodemask is only used at very early time. When 
the
system is up, it is useless.

This is just my approach for this problem. It is not good enough, and we can
improve it.

> 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).
>

I think allocating pagetable to local node really makes thing a little more
difficult than before. But I also think Yinghai's work is reasonable 
because
it helps to improve the performance.

What I am thinking now is to allocate things like pagetable pages to local
device. (Seems I mentioned this before.)

If a node has more than one memory device, and all the pagetable pages are
allocated in one device. Then this device cannot be hot-removed unless all
the other memory devices are hot-removed.

So I think allocating pagetable pages to local device is more reasonable.
But as you said, this could be more complex.

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