From: Christoph Lameter <clameter@sgi.com>
To: Yasunori Goto <y-goto@jp.fujitsu.com>
Cc: Andrew Morton <akpm@osdl.org>,
Linux Kernel ML <linux-kernel@vger.kernel.org>,
linux-mm <linux-mm@kvack.org>
Subject: Re: [Patch / 002](memory hotplug) Callback function to create kmem_cache_node.
Date: Wed, 3 Oct 2007 11:00:25 -0700 (PDT) [thread overview]
Message-ID: <Pine.LNX.4.64.0710031057150.3570@schroedinger.engr.sgi.com> (raw)
In-Reply-To: <20071003234201.B5F9.Y-GOTO@jp.fujitsu.com>
On Wed, 3 Oct 2007, Yasunori Goto wrote:
> >
> > That would work. But it would be better to shrink the cache first. The
> > first 2 slabs on a node may be empty and the shrinking will remove those.
> > If you do not shrink then the code may falsely assume that there are
> > objects on the node.
>
> I'm sorry, but I don't think I understand what you mean... :-(
> Could you explain more?
>
> Which slabs should be shrinked? kmem_cache_node and kmem_cache_cpu?
The slab for which you are trying to set the kmem_cache_node pointer to
NULL needs to be shrunk.
> I think kmem_cache_cpu should be disabled by cpu hotplug,
> not memory/node hotplug. Basically, cpu should be offlined before
> memory offline on the node.
Hmmm.. Ok for cpu hotplug you could simply disregard the per cpu
structure if the per cpu slab was flushed first.
However, the per node structure may hold slabs with no objects even after
all objects were removed on a node. These need to be flushed by calling
kmem_cache_shrink() on the slab cache.
On the other hand: If you can guarantee that they will not be used and
that no objects are in them and that you can recover the pages used in
different ways then zapping the per node pointer like that is okay.
--
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:[~2007-10-03 18:00 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-01 9:30 [Patch / 000](memory hotplug) Fix NULL pointer access of kmem_cache_node when hot-add Yasunori Goto
2007-10-01 9:33 ` [Patch / 001](memory hotplug) fix some defects of memory notifer callback interface Yasunori Goto
2007-10-01 9:34 ` [Patch / 002](memory hotplug) Callback function to create kmem_cache_node Yasunori Goto
2007-10-01 20:34 ` Christoph Lameter
2007-10-02 2:20 ` Yasunori Goto
2007-10-02 18:29 ` Christoph Lameter
2007-10-03 14:59 ` Yasunori Goto
2007-10-03 18:00 ` Christoph Lameter [this message]
2007-10-04 2:00 ` Yasunori Goto
2007-10-01 9:38 ` [Patch 000/002](memory hotplug) Fix NULL pointer access of kmem_cache_node when hot-add Yasunori Goto
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=Pine.LNX.4.64.0710031057150.3570@schroedinger.engr.sgi.com \
--to=clameter@sgi.com \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=y-goto@jp.fujitsu.com \
/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