From: Lai Jiangshan <laijs@cn.fujitsu.com>
To: KOSAKI Motohiro <kosaki.motohiro@gmail.com>
Cc: Christoph <cl@linux.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Christoph Lameter <cl@linux-foundation.org>,
Pekka Enberg <penberg@kernel.org>, Matt Mackall <mpm@selenic.com>,
"linux-mm@kvack.org" <linux-mm@kvack.org>
Subject: Re: [PATCH 2/3] slub, hotplug: ignore unrelated node's hot-adding and hot-removing
Date: Wed, 24 Oct 2012 15:06:40 +0800 [thread overview]
Message-ID: <50879380.2080703@cn.fujitsu.com> (raw)
In-Reply-To: <CAHGf_=pUMDm2M2wGvnsqrDgnhj0oHUO4JVuG=u3Qcn3TLvGRgg@mail.gmail.com>
On 09/29/2012 06:26 AM, KOSAKI Motohiro wrote:
> On Fri, Sep 28, 2012 at 3:19 AM, Lai Jiangshan <laijs@cn.fujitsu.com> wrote:
>> HI, Christoph, KOSAKI
>>
>> SLAB always allocates kmem_list3 for all nodes(N_HIGH_MEMORY), also node bug/bad things happens.
>> SLUB always requires kmem_cache_node on the correct node, so these fix is needed.
>>
>> SLAB uses for_each_online_node() to travel nodes and do maintain,
>> and it tolerates kmem_list3 on alien nodes.
>> SLUB uses for_each_node_state(node, N_NORMAL_MEMORY) to travel nodes and do maintain,
>> and it does not tolerate kmem_cache_node on alien nodes.
>>
>> Maybe we need to change SLAB future and let it use
>> for_each_node_state(node, N_NORMAL_MEMORY), But I don't want to change SLAB
>> until I find something bad in SLAB.
>
> SLAB can't use highmem. then traverse zones which don't have normal
> memory is silly IMHO.
SLAB tolerates dummy kmem_list3 on alien nodes.
> If this is not bug, current slub behavior is also not bug. Is there
> any difference?
SLUB can't tolerates dummy kmem_cache_node on alien nodes, otherwise
n->nr_slabs will be corrupted when we online a node which don't have normal memory,
and trigger a WARN_ON(). And it will trigger BUG_ON() when we remove the node.
Since SLUB always use for_each_node_state(node, N_NORMAL_MEMORY), we should make
all the other code in slub.c be compatible with it. otherwise we will break the
design of SLUB.
Since SLAB always use for_each_online_node(), it means it accept some silly behavior
in the design, we don't need to change it before we decide to remove the whole
silly things at together. there is not waring and buggy in SLAB in this view.
>
> If I understand correctly, current code may waste some additional
> memory on corner case. but it doesn't make memory leak both when slab
> and slub.
>
--
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:[~2012-10-24 7:04 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-27 6:47 [PATCH 0/3] memory_hotplug: fix memory hotplug bug Lai Jiangshan
2012-09-27 6:47 ` [PATCH 1/3] memory_hotplug: fix stale node_states[N_NORMAL_MEMORY] Lai Jiangshan
2012-09-27 14:32 ` Ni zhan Chen
2012-09-28 7:32 ` Lai Jiangshan
2012-09-27 22:03 ` KOSAKI Motohiro
2012-10-26 1:39 ` Lai Jiangshan
2012-09-27 6:47 ` [PATCH 2/3] slub, hotplug: ignore unrelated node's hot-adding and hot-removing Lai Jiangshan
2012-09-27 22:04 ` KOSAKI Motohiro
2012-09-27 22:35 ` Christoph
2012-09-28 7:19 ` Lai Jiangshan
2012-09-28 22:26 ` KOSAKI Motohiro
2012-10-24 7:06 ` Lai Jiangshan [this message]
2012-09-27 6:47 ` [PATCH 3/3] memory_hotplug: Don't modify the zone_start_pfn outside of zone_span_writelock() Lai Jiangshan
2012-09-27 13:19 ` Ni zhan Chen
2012-09-28 7:29 ` Lai Jiangshan
2012-09-28 8:04 ` Ni zhan Chen
2012-09-27 22:30 ` KOSAKI Motohiro
2012-09-28 7:39 ` Lai Jiangshan
2012-09-28 0:39 ` [PATCH 0/3] memory_hotplug: fix memory hotplug bug Ni zhan 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=50879380.2080703@cn.fujitsu.com \
--to=laijs@cn.fujitsu.com \
--cc=cl@linux-foundation.org \
--cc=cl@linux.com \
--cc=kosaki.motohiro@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mpm@selenic.com \
--cc=penberg@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;
as well as URLs for NNTP newsgroup(s).