Subject: [PATCH] Make CONFIG_MIGRATION available for s390
From: Gerald Schaefer <[email protected]>
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,
"#ifdef CONFIG_NUMA" is added to vma_migratable() and the vm_ops migrate()
definition is moved from "#ifdef CONFIG_NUMA" to "#ifdef CONFIG_MIGRATION".
Signed-off-by: Gerald Schaefer <[email protected]>
---
include/linux/migrate.h | 2 ++
include/linux/mm.h | 2 ++
mm/Kconfig | 2 +-
3 files changed, 5 insertions(+), 1 deletion(-)
Index: linux-2.6/include/linux/migrate.h
===================================================================
--- linux-2.6.orig/include/linux/migrate.h
+++ linux-2.6/include/linux/migrate.h
@@ -13,6 +13,7 @@ static inline int vma_migratable(struct
{
if (vma->vm_flags & (VM_IO|VM_HUGETLB|VM_PFNMAP|VM_RESERVED))
return 0;
+#ifdef CONFIG_NUMA
/*
* Migration allocates pages in the highest zone. If we cannot
* do so then migration (at least from node to node) is not
@@ -22,6 +23,7 @@ static inline int vma_migratable(struct
gfp_zone(mapping_gfp_mask(vma->vm_file->f_mapping))
< policy_zone)
return 0;
+#endif
return 1;
}
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
Looks good to me.
Acked-by: Yasunori Goto <[email protected]>
Bye.
> Subject: [PATCH] Make CONFIG_MIGRATION available for s390
>
> From: Gerald Schaefer <[email protected]>
>
> 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,
> "#ifdef CONFIG_NUMA" is added to vma_migratable() and the vm_ops migrate()
> definition is moved from "#ifdef CONFIG_NUMA" to "#ifdef CONFIG_MIGRATION".
>
> Signed-off-by: Gerald Schaefer <[email protected]>
> ---
>
> include/linux/migrate.h | 2 ++
> include/linux/mm.h | 2 ++
> mm/Kconfig | 2 +-
> 3 files changed, 5 insertions(+), 1 deletion(-)
>
> Index: linux-2.6/include/linux/migrate.h
> ===================================================================
> --- linux-2.6.orig/include/linux/migrate.h
> +++ linux-2.6/include/linux/migrate.h
> @@ -13,6 +13,7 @@ static inline int vma_migratable(struct
> {
> if (vma->vm_flags & (VM_IO|VM_HUGETLB|VM_PFNMAP|VM_RESERVED))
> return 0;
> +#ifdef CONFIG_NUMA
> /*
> * Migration allocates pages in the highest zone. If we cannot
> * do so then migration (at least from node to node) is not
> @@ -22,6 +23,7 @@ static inline int vma_migratable(struct
> gfp_zone(mapping_gfp_mask(vma->vm_file->f_mapping))
> < policy_zone)
> return 0;
> +#endif
> return 1;
> }
>
> 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
>
--
Yasunori Goto
On Sun, Jul 06, 2008 at 04:35:57PM +0200, Gerald Schaefer wrote:
> From: Gerald Schaefer <[email protected]>
>
> 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,
> "#ifdef CONFIG_NUMA" is added to vma_migratable() and the vm_ops migrate()
> definition is moved from "#ifdef CONFIG_NUMA" to "#ifdef CONFIG_MIGRATION".
>
> Signed-off-by: Gerald Schaefer <[email protected]>
> ---
>
> include/linux/migrate.h | 2 ++
> include/linux/mm.h | 2 ++
> mm/Kconfig | 2 +-
> 3 files changed, 5 insertions(+), 1 deletion(-)
>
> Index: linux-2.6/include/linux/migrate.h
> ===================================================================
> --- linux-2.6.orig/include/linux/migrate.h
> +++ linux-2.6/include/linux/migrate.h
> @@ -13,6 +13,7 @@ static inline int vma_migratable(struct
> {
> if (vma->vm_flags & (VM_IO|VM_HUGETLB|VM_PFNMAP|VM_RESERVED))
> return 0;
> +#ifdef CONFIG_NUMA
> /*
> * Migration allocates pages in the highest zone. If we cannot
> * do so then migration (at least from node to node) is not
> @@ -22,6 +23,7 @@ static inline int vma_migratable(struct
> gfp_zone(mapping_gfp_mask(vma->vm_file->f_mapping))
> < policy_zone)
> return 0;
> +#endif
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.
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.
> return 1;
> }
>
> 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
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to [email protected]. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"[email protected]"> [email protected] </a>
-apw
> > Index: linux-2.6/include/linux/migrate.h
> > ===================================================================
> > --- linux-2.6.orig/include/linux/migrate.h
> > +++ linux-2.6/include/linux/migrate.h
> > @@ -13,6 +13,7 @@ static inline int vma_migratable(struct
> > {
> > if (vma->vm_flags & (VM_IO|VM_HUGETLB|VM_PFNMAP|VM_RESERVED))
> > return 0;
> > +#ifdef CONFIG_NUMA
> > /*
> > * Migration allocates pages in the highest zone. If we cannot
> > * do so then migration (at least from node to node) is not
> > @@ -22,6 +23,7 @@ static inline int vma_migratable(struct
> > gfp_zone(mapping_gfp_mask(vma->vm_file->f_mapping))
> > < policy_zone)
> > return 0;
> > +#endif
>
> 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. :-)
> 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....
Thanks.
--
Yasunori Goto
Gerald Schaefer wrote:
> Index: linux-2.6/include/linux/migrate.h
> ===================================================================
> --- linux-2.6.orig/include/linux/migrate.h
> +++ linux-2.6/include/linux/migrate.h
> @@ -13,6 +13,7 @@ static inline int vma_migratable(struct
> {
> if (vma->vm_flags & (VM_IO|VM_HUGETLB|VM_PFNMAP|VM_RESERVED))
> return 0;
> +#ifdef CONFIG_NUMA
> /*
> * Migration allocates pages in the highest zone. If we cannot
> * do so then migration (at least from node to node) is not
> @@ -22,6 +23,7 @@ static inline int vma_migratable(struct
> gfp_zone(mapping_gfp_mask(vma->vm_file->f_mapping))
> < policy_zone)
> return 0;
> +#endif
> return 1;
> }
This will extend the number of pages that are migratable and lead to strange
semantics in the NUMA case. There suddenly vma_is migratable will forbid hotplug
to migrate certain pages.
I think we need two functions:
vma_migratable() General migratability
vma_policy_migratable() Migratable under NUMA policies.
> 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
That wont work since the migrate function takes a nodemask! The point of
the function is to move memory from node to node which is something that you
*cannot* do in a non NUMA configuration. So leave this chunk out.
> 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
Hmmm... Okay. I tried to make MIGRATION as independent of CONFIG_NUMA as possible so hopefully this will work.
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 <[email protected]>
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 <[email protected]>
---
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)
Gerald Schaefer wrote:
> 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?
Please rename the function to vma_policy_migratable() and then create a new function
vma_migratable() that checks for migratability independent of memory policies.
On Mon, 2008-07-07 at 10:09 -0500, Christoph Lameter wrote:
> This will extend the number of pages that are migratable and lead to strange
> semantics in the NUMA case. There suddenly vma_is migratable will forbid hotplug
> to migrate certain pages.
>
> I think we need two functions:
>
> vma_migratable() General migratability
>
> vma_policy_migratable() Migratable under NUMA policies.
Nothing will change here for the NUMA case, this is all about making it
compile w/o NUMA and with MIGRATION. What new strange semantics do you mean?
BTW, the latest patch in this thread will not touch vma_migratable() anymore,
I haven't read your mail before, sorry.
> That wont work since the migrate function takes a nodemask! The point of
> the function is to move memory from node to node which is something that you
> *cannot* do in a non NUMA configuration. So leave this chunk out.
Right, but I noticed that this function definition was needed to make it
compile with MIGRATION and w/o NUMA, although it would never be called in
non-NUMA config.
A better solution would probably be to put migrate_vmas(), the only caller
of vm_ops->migrate(), inside '#ifdef CONFIG_NUMA', because it will only be
called from NUMA-only mm/mempolicy.c. Does that sound reasonable?
> Hmmm... Okay. I tried to make MIGRATION as independent of CONFIG_NUMA as possible so hopefully this will work.
Umm, it doesn't compile with MIGRATION and w/o NUMA, which was the reason
for this patch, because of the policy_zone reference in vma_migratable()
and the missing vm_ops->migrate() function.
Thanks,
Gerald
Gerald Schaefer wrote:
> On Mon, 2008-07-07 at 10:09 -0500, Christoph Lameter wrote:
>> This will extend the number of pages that are migratable and lead to strange
>> semantics in the NUMA case. There suddenly vma_is migratable will forbid hotplug
>> to migrate certain pages.
>>
>> I think we need two functions:
>>
>> vma_migratable() General migratability
>>
>> vma_policy_migratable() Migratable under NUMA policies.
>
> Nothing will change here for the NUMA case, this is all about making it
> compile w/o NUMA and with MIGRATION. What new strange semantics do you mean?
> BTW, the latest patch in this thread will not touch vma_migratable() anymore,
> I haven't read your mail before, sorry.
Ahh. Okay. However, we may still want a function that tells us if the pages in a vma
are migratable in general (independent of policies). The current vma_migratable function
tell you if the pages in a vma were placed according to a NUMA memory policy and should be migrated for NUMA locality optimizations.
>> That wont work since the migrate function takes a nodemask! The point of
>> the function is to move memory from node to node which is something that you
>> *cannot* do in a non NUMA configuration. So leave this chunk out.
>
> Right, but I noticed that this function definition was needed to make it
> compile with MIGRATION and w/o NUMA, although it would never be called in
> non-NUMA config.
How does the compile break? It may be better to fix this where the function
is used.
> A better solution would probably be to put migrate_vmas(), the only caller
> of vm_ops->migrate(), inside '#ifdef CONFIG_NUMA', because it will only be
> called from NUMA-only mm/mempolicy.c. Does that sound reasonable?
That sounds right.
>> Hmmm... Okay. I tried to make MIGRATION as independent of CONFIG_NUMA as possible so hopefully this will work.
>
> Umm, it doesn't compile with MIGRATION and w/o NUMA, which was the reason
> for this patch, because of the policy_zone reference in vma_migratable()
> and the missing vm_ops->migrate() function.
Right. I did not have a use case for !NUMA when I wrote the code. So you now need to
fix the minor bits that break.
On Mon, 2008-07-07 at 12:38 -0500, Christoph Lameter wrote:
> How does the compile break? It may be better to fix this where the function
> is used.
Good point, I did not look into this deep enough and tried to fix the
symptoms instead of the cause. There are two locations where the compile
breaks:
- mm/migrate.c: migrate_vmas() does not know vm_ops->migrate()
- inlcude/linux/migrate.h: vma_migratable() does not know policy_zone
Both functions are called from mm/mempolicy.c, which is NUMA-only.
vma_migratable() is also called from mm/migrate.c, but just inside a
'#ifdef CONFIG_NUMA' section. So I think it should be safe to just put
the definition of those two functions within '#ifdef CONFIG_NUMA',
and the compile error will be gone, see new patch below.
Thanks,
Gerald
---
Subject: [PATCH] Make CONFIG_MIGRATION available for s390
From: Gerald Schaefer <[email protected]>
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 migrate_vmas() does not know about vm_ops->migrate()
and vma_migratable() does not know about policy_zone. To avoid this, those
two functions can be restricted to "#ifdef CONFIG_NUMA" because they are
not being used w/o NUMA.
Signed-off-by: Gerald Schaefer <[email protected]>
---
include/linux/migrate.h | 2 ++
mm/Kconfig | 2 +-
mm/migrate.c | 2 +-
3 files changed, 4 insertions(+), 2 deletions(-)
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/migrate.h
===================================================================
--- linux-2.6.orig/include/linux/migrate.h
+++ linux-2.6/include/linux/migrate.h
@@ -8,6 +8,7 @@
typedef struct page *new_page_t(struct page *, unsigned long private, int **);
#ifdef CONFIG_MIGRATION
+#ifdef CONFIG_NUMA
/* Check if a vma is migratable */
static inline int vma_migratable(struct vm_area_struct *vma)
{
@@ -24,6 +25,7 @@ static inline int vma_migratable(struct
return 0;
return 1;
}
+#endif /* CONFIG_NUMA */
extern int isolate_lru_page(struct page *p, struct list_head *pagelist);
extern int putback_lru_pages(struct list_head *l);
Index: linux-2.6/mm/migrate.c
===================================================================
--- linux-2.6.orig/mm/migrate.c
+++ linux-2.6/mm/migrate.c
@@ -1070,7 +1070,6 @@ out2:
mmput(mm);
return err;
}
-#endif
/*
* Call migration functions in the vma_ops that may prepare
@@ -1092,3 +1091,4 @@ int migrate_vmas(struct mm_struct *mm, c
}
return err;
}
+#endif
Gerald Schaefer wrote:
> On Mon, 2008-07-07 at 12:38 -0500, Christoph Lameter wrote:
>> How does the compile break? It may be better to fix this where the function
>> is used.
>
> Good point, I did not look into this deep enough and tried to fix the
> symptoms instead of the cause. There are two locations where the compile
> breaks:
> - mm/migrate.c: migrate_vmas() does not know vm_ops->migrate()
I think you just need to move the #endif from before migrate_vmas to the end (as you already suggested). Then migrate_vmas will no longer be compiled for the NUMA case. migrate_vmas() was added later and was not placed correctly it seems.
> - inlcude/linux/migrate.h: vma_migratable() does not know policy_zone
Again here you would have to add a new function.
vma_policy_migratable() should only be available for CONFIG_NUMA.
vma_migratable (without policy_zone check!) should be available if CONFIG_MIGRATION is on.
Not sure if we need such a test. If not then just make sure that vma_migratable() is
not included for the !NUMA case.
On Mon, 2008-07-07 at 13:32 -0500, Christoph Lameter wrote:
> I think you just need to move the #endif from before migrate_vmas to the
> end (as you already suggested). Then migrate_vmas will no longer be compiled
> for the NUMA case. migrate_vmas() was added later and was not placed correctly
> it seems.
done
> vma_migratable (without policy_zone check!) should be available if
> CONFIG_MIGRATION is on. Not sure if we need such a test. If not then just
> make sure that vma_migratable() is not included for the !NUMA case.
vma_migratable is not needed w/o NUMA, so I just put an '#ifdef CONFIG_NUMA'
around it.
Subject: [PATCH] Make CONFIG_MIGRATION available w/o CONFIG_NUMA
From: Gerald Schaefer <[email protected]>
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 migrate_vmas() does not know about vm_ops->migrate()
and vma_migratable() does not know about policy_zone. To fix this, those
two functions can be restricted to "#ifdef CONFIG_NUMA" because they are
not being used w/o NUMA.
Signed-off-by: Gerald Schaefer <[email protected]>
---
include/linux/migrate.h | 2 ++
mm/Kconfig | 2 +-
mm/migrate.c | 2 +-
3 files changed, 4 insertions(+), 2 deletions(-)
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/migrate.h
===================================================================
--- linux-2.6.orig/include/linux/migrate.h
+++ linux-2.6/include/linux/migrate.h
@@ -8,6 +8,7 @@
typedef struct page *new_page_t(struct page *, unsigned long private, int **);
#ifdef CONFIG_MIGRATION
+#ifdef CONFIG_NUMA
/* Check if a vma is migratable */
static inline int vma_migratable(struct vm_area_struct *vma)
{
@@ -24,6 +25,7 @@ static inline int vma_migratable(struct
return 0;
return 1;
}
+#endif /* CONFIG_NUMA */
extern int isolate_lru_page(struct page *p, struct list_head *pagelist);
extern int putback_lru_pages(struct list_head *l);
Index: linux-2.6/mm/migrate.c
===================================================================
--- linux-2.6.orig/mm/migrate.c
+++ linux-2.6/mm/migrate.c
@@ -1070,7 +1070,6 @@ out2:
mmput(mm);
return err;
}
-#endif
/*
* Call migration functions in the vma_ops that may prepare
@@ -1092,3 +1091,4 @@ int migrate_vmas(struct mm_struct *mm, c
}
return err;
}
+#endif
Acked-by: Christoph Lameter <[email protected]>
Small nit: It now looks as if the vma_migratable() function belongs into mempolicy.h and not migrate.h
And something ate my ack!
Acked-by: Christoph Lameter <[email protected]>
On Tue, 2008-07-08 at 08:35 -0500, Christoph Lameter wrote:
> Acked-by: Christoph Lameter <[email protected]>
>
> Small nit: It now looks as if the vma_migratable() function belongs into mempolicy.h and not migrate.h
Right, I'll send a new patch that moves vma_migratable() to mempolicy.h
Thanks,
Gerald