From: Tang Chen <tangchen@cn.fujitsu.com>
To: Vasilis Liaskovitis <vasilis.liaskovitis@profitbricks.com>
Cc: tglx@linutronix.de, mingo@elte.hu, hpa@zytor.com,
akpm@linux-foundation.org, tj@kernel.org, trenn@suse.de,
yinghai@kernel.org, jiang.liu@huawei.com, wency@cn.fujitsu.com,
laijs@cn.fujitsu.com, isimatu.yasuaki@jp.fujitsu.com,
mgorman@suse.de, minchan@kernel.org, mina86@mina86.com,
gong.chen@linux.intel.com, lwoodman@redhat.com, riel@redhat.com,
jweiner@redhat.com, prarit@redhat.com, x86@kernel.org,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org
Subject: Re: [Part2 PATCH v4 08/15] x86, numa: Save nid when reserve memory into memblock.reserved[].
Date: Wed, 19 Jun 2013 14:14:54 +0800 [thread overview]
Message-ID: <51C14C5E.6090501@cn.fujitsu.com> (raw)
In-Reply-To: <20130618165753.GB4553@dhcp-192-168-178-175.profitbricks.localdomain>
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, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2013-06-19 6:12 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-13 13:03 [Part2 PATCH v4 00/15] Arrange hotpluggable memory in SRAT as ZONE_MOVABLE Tang Chen
2013-06-13 13:03 ` [Part2 PATCH v4 01/15] x86: get pg_data_t's memory from other node Tang Chen
2013-06-13 13:03 ` [Part2 PATCH v4 02/15] acpi: Print Hot-Pluggable Field in SRAT Tang Chen
2013-06-13 13:03 ` [Part2 PATCH v4 03/15] page_alloc, mem-hotplug: Improve movablecore to {en|dis}able using SRAT Tang Chen
2013-06-13 13:03 ` [Part2 PATCH v4 04/15] x86, numa, acpi, memory-hotplug: Introduce hotplug info into struct numa_meminfo Tang Chen
2013-06-13 13:03 ` [Part2 PATCH v4 05/15] x86, numa, acpi, memory-hotplug: Consider hotplug info when cleanup numa_meminfo Tang Chen
2013-06-13 13:03 ` [Part2 PATCH v4 06/15] memblock, numa: Introduce flag into memblock Tang Chen
2013-06-13 13:03 ` [Part2 PATCH v4 07/15] x86, numa: Synchronize nid info in memblock.reserve with numa_meminfo Tang Chen
2013-06-13 13:03 ` [Part2 PATCH v4 08/15] x86, numa: Save nid when reserve memory into memblock.reserved[] Tang Chen
2013-06-18 16:57 ` Vasilis Liaskovitis
2013-06-19 6:14 ` Tang Chen [this message]
2013-06-13 13:03 ` [Part2 PATCH v4 09/15] x86, numa, mem-hotplug: Mark nodes which the kernel resides in Tang Chen
2013-06-13 13:03 ` [Part2 PATCH v4 10/15] x86, numa: Move memory_add_physaddr_to_nid() to CONFIG_NUMA Tang Chen
2013-06-13 13:03 ` [Part2 PATCH v4 11/15] x86, numa, memblock: Introduce MEMBLK_LOCAL_NODE to mark and reserve node-life-cycle data Tang Chen
2013-06-13 13:03 ` [Part2 PATCH v4 12/15] x86, acpi, numa, mem-hotplug: Introduce MEMBLK_HOTPLUGGABLE to mark and reserve hotpluggable memory Tang Chen
2013-06-13 13:03 ` [Part2 PATCH v4 13/15] x86, memblock, mem-hotplug: Free hotpluggable memory reserved by memblock Tang Chen
2013-06-13 13:03 ` [Part2 PATCH v4 14/15] x86, numa, acpi, memory-hotplug: Make movablecore=acpi have higher priority Tang Chen
2013-06-13 13:03 ` [Part2 PATCH v4 15/15] doc, page_alloc, acpi, mem-hotplug: Add doc for movablecore=acpi boot option Tang Chen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51C14C5E.6090501@cn.fujitsu.com \
--to=tangchen@cn.fujitsu.com \
--cc=akpm@linux-foundation.org \
--cc=gong.chen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=isimatu.yasuaki@jp.fujitsu.com \
--cc=jiang.liu@huawei.com \
--cc=jweiner@redhat.com \
--cc=laijs@cn.fujitsu.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lwoodman@redhat.com \
--cc=mgorman@suse.de \
--cc=mina86@mina86.com \
--cc=minchan@kernel.org \
--cc=mingo@elte.hu \
--cc=prarit@redhat.com \
--cc=riel@redhat.com \
--cc=tglx@linutronix.de \
--cc=tj@kernel.org \
--cc=trenn@suse.de \
--cc=vasilis.liaskovitis@profitbricks.com \
--cc=wency@cn.fujitsu.com \
--cc=x86@kernel.org \
--cc=yinghai@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox