linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Gerald Schaefer <gerald.schaefer@de.ibm.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Andy Whitcroft <apw@shadowen.org>,
	Yasunori Goto <y-goto@jp.fujitsu.com>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	schwidefsky@de.ibm.com, heiko.carstens@de.ibm.com,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	Dave Hansen <haveblue@us.ibm.com>
Subject: [PATCH] Make CONFIG_MIGRATION available for s390
Date: Mon, 07 Jul 2008 18:41:46 +0200	[thread overview]
Message-ID: <1215448906.8431.52.camel@localhost.localdomain> (raw)
In-Reply-To: <20080707185433.5A5D.E1E9C6FF@jp.fujitsu.com>

On Mon, 2008-07-07 at 19:24 +0900, Yasunori Goto wrote:
> > include/linux/mempolicy.h already has a !NUMA section could we not just
> > define policy_zone as 0 in that and leave this code unconditionally
> > compiled?  Perhaps also adding a NUMA_BUILD && to this 'if' should that
> > be clearer.
> > 
> Ah, yes. It's better. :-)

ok, the new patch below defines policy_zone as 0 in the !NUMA section. The
compiler will automatically omit the if statement w/o NUMA in this case.

> > But this does make me feel uneasy.  Are we really saying all memory on
> > an s390 is migratable.  That seems unlikely. As I understand the NUMA
> > case, we only allow migration of memory in the last zone (last two if we
> > have a MOVABLE zone) why are things different just because we have a
> > single 'node'.  Hmmm.  I suspect strongly that something is missnamed
> > more than there is a problem.
> 
> If my understanding is correct, even if this policy_zone check is removed,
> page isolation will just fail due to some busy pages.
> In hotplug case, it means giving up of hotremoving,
> and kernel must be rollback to make same condition of previous
> starting offline_pages().
> This check means just "early" check, but not so effective for hotremoving,
> I think....

It seems to me that this policy_zone check in vma_migratable() is not
called at all for the offline_pages() case, only for some NUMA system calls
that we don't support on s390. As Yasunori Goto said, page isolation checks
should do the job for memory hotremove via offline_pages(), independent from
any policy_zone setting. Any more thoughts on this?

Thanks,
Gerald
---

Subject: [PATCH] Make CONFIG_MIGRATION available for s390

From: Gerald Schaefer <gerald.schaefer@de.ibm.com>

We'd like to support CONFIG_MEMORY_HOTREMOVE on s390, which depends on
CONFIG_MIGRATION. So far, CONFIG_MIGRATION is only available with NUMA
support.

This patch makes CONFIG_MIGRATION selectable for architectures that define
ARCH_ENABLE_MEMORY_HOTREMOVE. When MIGRATION is enabled w/o NUMA, the kernel
won't compile because of a missing migrate() function in vm_operations_struct
and a missing policy_zone reference in vma_migratable(). To avoid this,
policy_zone is defined as 0 for !NUMA, and the vm_ops migrate() definition
is moved from '#ifdef CONFIG_NUMA' to '#ifdef CONFIG_MIGRATION'.

Signed-off-by: Gerald Schaefer <gerald.schaefer@de.ibm.com>
---

 include/linux/mempolicy.h |    1 +
 include/linux/mm.h        |    2 ++
 mm/Kconfig                |    2 +-
 3 files changed, 4 insertions(+), 1 deletion(-)

Index: linux-2.6/include/linux/mm.h
===================================================================
--- linux-2.6.orig/include/linux/mm.h
+++ linux-2.6/include/linux/mm.h
@@ -193,6 +193,8 @@ struct vm_operations_struct {
 	 */
 	struct mempolicy *(*get_policy)(struct vm_area_struct *vma,
 					unsigned long addr);
+#endif
+#ifdef CONFIG_MIGRATION
 	int (*migrate)(struct vm_area_struct *vma, const nodemask_t *from,
 		const nodemask_t *to, unsigned long flags);
 #endif
Index: linux-2.6/mm/Kconfig
===================================================================
--- linux-2.6.orig/mm/Kconfig
+++ linux-2.6/mm/Kconfig
@@ -174,7 +174,7 @@ config SPLIT_PTLOCK_CPUS
 config MIGRATION
 	bool "Page migration"
 	def_bool y
-	depends on NUMA
+	depends on NUMA || ARCH_ENABLE_MEMORY_HOTREMOVE
 	help
 	  Allows the migration of the physical location of pages of processes
 	  while the virtual addresses are not changed. This is useful for
Index: linux-2.6/include/linux/mempolicy.h
===================================================================
--- linux-2.6.orig/include/linux/mempolicy.h
+++ linux-2.6/include/linux/mempolicy.h
@@ -222,6 +222,7 @@ extern int mpol_to_str(char *buffer, int
 #endif
 #else
 
+#define policy_zone	0
 struct mempolicy {};
 
 static inline int mpol_equal(struct mempolicy *a, struct mempolicy *b)


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

  reply	other threads:[~2008-07-07 16:41 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-06 14:35 [PATCH] Make CONFIG_MIGRATION available for s390, " Gerald Schaefer
2008-07-07  6:22 ` Yasunori Goto
2008-07-07  9:16 ` Andy Whitcroft
2008-07-07 10:24   ` Yasunori Goto
2008-07-07 16:41     ` Gerald Schaefer [this message]
2008-07-07 16:53       ` Christoph Lameter
2008-07-07 15:09 ` Christoph Lameter
2008-07-07 17:28   ` Gerald Schaefer
2008-07-07 17:38     ` Christoph Lameter
2008-07-07 18:25       ` Gerald Schaefer
2008-07-07 18:32         ` Christoph Lameter
2008-07-08 10:50           ` [PATCH] Make CONFIG_MIGRATION available w/o NUMA Gerald Schaefer
2008-07-08 13:35             ` Christoph Lameter
2008-07-08 13:47               ` Christoph Lameter
2008-07-11 13:05               ` Gerald Schaefer
  -- strict thread matches above, loose matches on Subject: below --
2008-07-04 14:58 [PATCH] Make CONFIG_MIGRATION available for s390, [PATCH] Make CONFIG_MIGRATION available for s390 Gerald Schaefer
2008-07-05  4:02 ` KAMEZAWA Hiroyuki
2008-07-05  6:14   ` Yasunori Goto
2008-07-06 14:30     ` Gerald Schaefer

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=1215448906.8431.52.camel@localhost.localdomain \
    --to=gerald.schaefer@de.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=apw@shadowen.org \
    --cc=haveblue@us.ibm.com \
    --cc=heiko.carstens@de.ibm.com \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=schwidefsky@de.ibm.com \
    --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