From: Balbir Singh <bsingharora@gmail.com> To: John Hubbard <jhubbard@nvidia.com> Cc: "Andrew Morton" <akpm@linux-foundation.org>, "Jérôme Glisse" <jglisse@redhat.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, linux-mm <linux-mm@kvack.org>, "Naoya Horiguchi" <n-horiguchi@ah.jp.nec.com>, "David Nellans" <dnellans@nvidia.com>, "Evgeny Baskakov" <ebaskakov@nvidia.com>, "Mark Hairgrove" <mhairgrove@nvidia.com>, "Sherry Cheung" <SCheung@nvidia.com>, "Subhash Gutti" <sgutti@nvidia.com> Subject: Re: [HMM 07/16] mm/migrate: new memory migration helper for use with device memory v4 Date: Fri, 17 Mar 2017 15:51:33 +1100 [thread overview] Message-ID: <a8b67ed5-118c-6da5-1db6-6edf836f9230@gmail.com> (raw) In-Reply-To: <CAKTCnznV1D4iZcn-PWvfu92_NB-Ree=cOT3bKfuJSPSXVB_QAg@mail.gmail.com> On 17/03/17 14:42, Balbir Singh wrote: >>> Or make the HMM Kconfig feature 64BIT only by making it depend on 64BIT? >>> >> >> Yes, that was my first reaction too, but these particular routines are >> aspiring to be generic routines--in fact, you have had an influence there, >> because these might possibly help with NUMA migrations. :) >> > > Yes, I still stick to them being generic, but I'd be OK if they worked > just for 64 bit systems. > Having said that even the 64 bit works version work for upto physical > sizes of 64 - PAGE_SHIFT > which is a little limiting I think. > > One option is to make pfn's unsigned long long and do 32 and 64 bit computations > separately > > Option 2, could be something like you said > > a. Define a __weak migrate_vma to return -EINVAL > b. In a 64BIT only file define migrate_vma > > Option 3 > > Something totally different > > If we care to support 32 bit we go with 1, else option 2 is a good > starting point. There might > be other ways of doing option 2, like you've suggested So this is what I ended up with, a quick fix for the 32 bit build failures Date: Fri, 17 Mar 2017 15:42:52 +1100 Subject: [PATCH] mm/hmm: Fix build on 32 bit systems Fix build breakage of hmm-v18 in the current mmotm by making the migrate_vma() and related functions 64 bit only. The 32 bit variant will return -EINVAL. There are other approaches to solving this problem, but we can enable 32 bit systems as we need them. This patch tries to limit the impact on 32 bit systems by turning HMM off on them and not enabling the migrate functions. I've built this on ppc64/i386 and x86_64 Signed-off-by: Balbir Singh <bsingharora@gmail.com> --- include/linux/migrate.h | 18 +++++++++++++++++- mm/Kconfig | 4 +++- mm/migrate.c | 3 ++- 3 files changed, 22 insertions(+), 3 deletions(-) diff --git a/include/linux/migrate.h b/include/linux/migrate.h index 01f4945..1888a70 100644 --- a/include/linux/migrate.h +++ b/include/linux/migrate.h @@ -124,7 +124,7 @@ static inline int migrate_misplaced_transhuge_page(struct mm_struct *mm, } #endif /* CONFIG_NUMA_BALANCING && CONFIG_TRANSPARENT_HUGEPAGE*/ - +#ifdef CONFIG_64BIT #define MIGRATE_PFN_VALID (1UL << (BITS_PER_LONG_LONG - 1)) #define MIGRATE_PFN_MIGRATE (1UL << (BITS_PER_LONG_LONG - 2)) #define MIGRATE_PFN_HUGE (1UL << (BITS_PER_LONG_LONG - 3)) @@ -145,6 +145,7 @@ static inline unsigned long migrate_pfn_size(unsigned long mpfn) { return mpfn & MIGRATE_PFN_HUGE ? PMD_SIZE : PAGE_SIZE; } +#endif /* * struct migrate_vma_ops - migrate operation callback @@ -194,6 +195,7 @@ struct migrate_vma_ops { void *private); }; +#ifdef CONFIG_64BIT int migrate_vma(const struct migrate_vma_ops *ops, struct vm_area_struct *vma, unsigned long mentries, @@ -202,5 +204,19 @@ int migrate_vma(const struct migrate_vma_ops *ops, unsigned long *src, unsigned long *dst, void *private); +#else +static inline int migrate_vma(const struct migrate_vma_ops *ops, + struct vm_area_struct *vma, + unsigned long mentries, + unsigned long start, + unsigned long end, + unsigned long *src, + unsigned long *dst, + void *private) +{ + return -EINVAL; +} +#endif + #endif /* _LINUX_MIGRATE_H */ diff --git a/mm/Kconfig b/mm/Kconfig index a430d51..c13677f 100644 --- a/mm/Kconfig +++ b/mm/Kconfig @@ -291,7 +291,7 @@ config ARCH_ENABLE_HUGEPAGE_MIGRATION config HMM bool - depends on MMU + depends on MMU && 64BIT config HMM_MIRROR bool "HMM mirror CPU page table into a device page table" @@ -307,6 +307,7 @@ config HMM_MIRROR Second side of the equation is replicating CPU page table content for range of virtual address. This require careful synchronization with CPU page table update. + depends on 64BIT config HMM_DEVMEM bool "HMM device memory helpers (to leverage ZONE_DEVICE)" @@ -314,6 +315,7 @@ config HMM_DEVMEM help HMM devmem are helpers to leverage new ZONE_DEVICE feature. This is just to avoid device driver to replicate boiler plate code. + depends on 64BIT config PHYS_ADDR_T_64BIT def_bool 64BIT || ARCH_PHYS_ADDR_T_64BIT diff --git a/mm/migrate.c b/mm/migrate.c index b9d25d1..15f2972 100644 --- a/mm/migrate.c +++ b/mm/migrate.c @@ -2080,7 +2080,7 @@ int migrate_misplaced_transhuge_page(struct mm_struct *mm, #endif /* CONFIG_NUMA */ - +#ifdef CONFIG_64BIT struct migrate_vma { struct vm_area_struct *vma; unsigned long *dst; @@ -2787,3 +2787,4 @@ int migrate_vma(const struct migrate_vma_ops *ops, return 0; } EXPORT_SYMBOL(migrate_vma); +#endif -- 2.10.2
WARNING: multiple messages have this Message-ID (diff)
From: Balbir Singh <bsingharora@gmail.com> To: John Hubbard <jhubbard@nvidia.com> Cc: "Andrew Morton" <akpm@linux-foundation.org>, "Jérôme Glisse" <jglisse@redhat.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, linux-mm <linux-mm@kvack.org>, "Naoya Horiguchi" <n-horiguchi@ah.jp.nec.com>, "David Nellans" <dnellans@nvidia.com>, "Evgeny Baskakov" <ebaskakov@nvidia.com>, "Mark Hairgrove" <mhairgrove@nvidia.com>, "Sherry Cheung" <SCheung@nvidia.com>, "Subhash Gutti" <sgutti@nvidia.com> Subject: Re: [HMM 07/16] mm/migrate: new memory migration helper for use with device memory v4 Date: Fri, 17 Mar 2017 15:51:33 +1100 [thread overview] Message-ID: <a8b67ed5-118c-6da5-1db6-6edf836f9230@gmail.com> (raw) In-Reply-To: <CAKTCnznV1D4iZcn-PWvfu92_NB-Ree=cOT3bKfuJSPSXVB_QAg@mail.gmail.com> On 17/03/17 14:42, Balbir Singh wrote: >>> Or make the HMM Kconfig feature 64BIT only by making it depend on 64BIT? >>> >> >> Yes, that was my first reaction too, but these particular routines are >> aspiring to be generic routines--in fact, you have had an influence there, >> because these might possibly help with NUMA migrations. :) >> > > Yes, I still stick to them being generic, but I'd be OK if they worked > just for 64 bit systems. > Having said that even the 64 bit works version work for upto physical > sizes of 64 - PAGE_SHIFT > which is a little limiting I think. > > One option is to make pfn's unsigned long long and do 32 and 64 bit computations > separately > > Option 2, could be something like you said > > a. Define a __weak migrate_vma to return -EINVAL > b. In a 64BIT only file define migrate_vma > > Option 3 > > Something totally different > > If we care to support 32 bit we go with 1, else option 2 is a good > starting point. There might > be other ways of doing option 2, like you've suggested So this is what I ended up with, a quick fix for the 32 bit build failures Date: Fri, 17 Mar 2017 15:42:52 +1100 Subject: [PATCH] mm/hmm: Fix build on 32 bit systems Fix build breakage of hmm-v18 in the current mmotm by making the migrate_vma() and related functions 64 bit only. The 32 bit variant will return -EINVAL. There are other approaches to solving this problem, but we can enable 32 bit systems as we need them. This patch tries to limit the impact on 32 bit systems by turning HMM off on them and not enabling the migrate functions. I've built this on ppc64/i386 and x86_64 Signed-off-by: Balbir Singh <bsingharora@gmail.com> --- include/linux/migrate.h | 18 +++++++++++++++++- mm/Kconfig | 4 +++- mm/migrate.c | 3 ++- 3 files changed, 22 insertions(+), 3 deletions(-) diff --git a/include/linux/migrate.h b/include/linux/migrate.h index 01f4945..1888a70 100644 --- a/include/linux/migrate.h +++ b/include/linux/migrate.h @@ -124,7 +124,7 @@ static inline int migrate_misplaced_transhuge_page(struct mm_struct *mm, } #endif /* CONFIG_NUMA_BALANCING && CONFIG_TRANSPARENT_HUGEPAGE*/ - +#ifdef CONFIG_64BIT #define MIGRATE_PFN_VALID (1UL << (BITS_PER_LONG_LONG - 1)) #define MIGRATE_PFN_MIGRATE (1UL << (BITS_PER_LONG_LONG - 2)) #define MIGRATE_PFN_HUGE (1UL << (BITS_PER_LONG_LONG - 3)) @@ -145,6 +145,7 @@ static inline unsigned long migrate_pfn_size(unsigned long mpfn) { return mpfn & MIGRATE_PFN_HUGE ? PMD_SIZE : PAGE_SIZE; } +#endif /* * struct migrate_vma_ops - migrate operation callback @@ -194,6 +195,7 @@ struct migrate_vma_ops { void *private); }; +#ifdef CONFIG_64BIT int migrate_vma(const struct migrate_vma_ops *ops, struct vm_area_struct *vma, unsigned long mentries, @@ -202,5 +204,19 @@ int migrate_vma(const struct migrate_vma_ops *ops, unsigned long *src, unsigned long *dst, void *private); +#else +static inline int migrate_vma(const struct migrate_vma_ops *ops, + struct vm_area_struct *vma, + unsigned long mentries, + unsigned long start, + unsigned long end, + unsigned long *src, + unsigned long *dst, + void *private) +{ + return -EINVAL; +} +#endif + #endif /* _LINUX_MIGRATE_H */ diff --git a/mm/Kconfig b/mm/Kconfig index a430d51..c13677f 100644 --- a/mm/Kconfig +++ b/mm/Kconfig @@ -291,7 +291,7 @@ config ARCH_ENABLE_HUGEPAGE_MIGRATION config HMM bool - depends on MMU + depends on MMU && 64BIT config HMM_MIRROR bool "HMM mirror CPU page table into a device page table" @@ -307,6 +307,7 @@ config HMM_MIRROR Second side of the equation is replicating CPU page table content for range of virtual address. This require careful synchronization with CPU page table update. + depends on 64BIT config HMM_DEVMEM bool "HMM device memory helpers (to leverage ZONE_DEVICE)" @@ -314,6 +315,7 @@ config HMM_DEVMEM help HMM devmem are helpers to leverage new ZONE_DEVICE feature. This is just to avoid device driver to replicate boiler plate code. + depends on 64BIT config PHYS_ADDR_T_64BIT def_bool 64BIT || ARCH_PHYS_ADDR_T_64BIT diff --git a/mm/migrate.c b/mm/migrate.c index b9d25d1..15f2972 100644 --- a/mm/migrate.c +++ b/mm/migrate.c @@ -2080,7 +2080,7 @@ int migrate_misplaced_transhuge_page(struct mm_struct *mm, #endif /* CONFIG_NUMA */ - +#ifdef CONFIG_64BIT struct migrate_vma { struct vm_area_struct *vma; unsigned long *dst; @@ -2787,3 +2787,4 @@ int migrate_vma(const struct migrate_vma_ops *ops, return 0; } EXPORT_SYMBOL(migrate_vma); +#endif -- 2.10.2 -- 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:[~2017-03-17 4:52 UTC|newest] Thread overview: 90+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-03-16 16:05 [HMM 00/16] HMM (Heterogeneous Memory Management) v18 Jérôme Glisse 2017-03-16 16:05 ` Jérôme Glisse 2017-03-16 16:05 ` [HMM 01/16] mm/memory/hotplug: convert device bool to int to allow for more flags v3 Jérôme Glisse 2017-03-16 16:05 ` Jérôme Glisse 2017-03-19 20:08 ` Mel Gorman 2017-03-19 20:08 ` Mel Gorman 2017-03-16 16:05 ` [HMM 02/16] mm/put_page: move ref decrement to put_zone_device_page() Jérôme Glisse 2017-03-16 16:05 ` Jérôme Glisse 2017-03-19 20:08 ` Mel Gorman 2017-03-19 20:08 ` Mel Gorman 2017-03-16 16:05 ` [HMM 03/16] mm/ZONE_DEVICE/free-page: callback when page is freed v3 Jérôme Glisse 2017-03-16 16:05 ` Jérôme Glisse 2017-03-19 20:08 ` Mel Gorman 2017-03-19 20:08 ` Mel Gorman 2017-03-16 16:05 ` [HMM 04/16] mm/ZONE_DEVICE/unaddressable: add support for un-addressable device memory v3 Jérôme Glisse 2017-03-16 16:05 ` Jérôme Glisse 2017-03-19 20:09 ` Mel Gorman 2017-03-19 20:09 ` Mel Gorman 2017-03-16 16:05 ` [HMM 05/16] mm/ZONE_DEVICE/x86: add support for un-addressable device memory Jérôme Glisse 2017-03-16 16:05 ` Jérôme Glisse 2017-03-16 16:05 ` [HMM 06/16] mm/migrate: add new boolean copy flag to migratepage() callback Jérôme Glisse 2017-03-16 16:05 ` Jérôme Glisse 2017-03-19 20:09 ` Mel Gorman 2017-03-19 20:09 ` Mel Gorman 2017-03-16 16:05 ` [HMM 07/16] mm/migrate: new memory migration helper for use with device memory v4 Jérôme Glisse 2017-03-16 16:05 ` Jérôme Glisse 2017-03-16 16:24 ` Reza Arbab 2017-03-16 16:24 ` Reza Arbab 2017-03-16 20:58 ` Balbir Singh 2017-03-16 20:58 ` Balbir Singh 2017-03-16 23:05 ` Andrew Morton 2017-03-16 23:05 ` Andrew Morton 2017-03-17 0:22 ` John Hubbard 2017-03-17 0:22 ` John Hubbard 2017-03-17 0:45 ` Balbir Singh 2017-03-17 0:45 ` Balbir Singh 2017-03-17 0:57 ` John Hubbard 2017-03-17 0:57 ` John Hubbard 2017-03-17 1:52 ` Jerome Glisse 2017-03-17 1:52 ` Jerome Glisse 2017-03-17 3:32 ` Andrew Morton 2017-03-17 3:32 ` Andrew Morton 2017-03-17 3:42 ` Balbir Singh 2017-03-17 3:42 ` Balbir Singh 2017-03-17 4:51 ` Balbir Singh [this message] 2017-03-17 4:51 ` Balbir Singh 2017-03-17 7:17 ` John Hubbard 2017-03-17 7:17 ` John Hubbard 2017-03-16 16:05 ` [HMM 08/16] mm/migrate: migrate_vma() unmap page from vma while collecting pages Jérôme Glisse 2017-03-16 16:05 ` Jérôme Glisse 2017-03-16 16:05 ` [HMM 09/16] mm/hmm: heterogeneous memory management (HMM for short) Jérôme Glisse 2017-03-16 16:05 ` Jérôme Glisse 2017-03-19 20:09 ` Mel Gorman 2017-03-19 20:09 ` Mel Gorman 2017-03-16 16:05 ` [HMM 10/16] mm/hmm/mirror: mirror process address space on device with HMM helpers Jérôme Glisse 2017-03-16 16:05 ` Jérôme Glisse 2017-03-19 20:09 ` Mel Gorman 2017-03-19 20:09 ` Mel Gorman 2017-03-16 16:05 ` [HMM 11/16] mm/hmm/mirror: helper to snapshot CPU page table v2 Jérôme Glisse 2017-03-16 16:05 ` Jérôme Glisse 2017-03-19 20:09 ` Mel Gorman 2017-03-19 20:09 ` Mel Gorman 2017-03-16 16:05 ` [HMM 12/16] mm/hmm/mirror: device page fault handler Jérôme Glisse 2017-03-16 16:05 ` Jérôme Glisse 2017-03-16 16:05 ` [HMM 13/16] mm/hmm/migrate: support un-addressable ZONE_DEVICE page in migration Jérôme Glisse 2017-03-16 16:05 ` Jérôme Glisse 2017-03-16 16:05 ` [HMM 14/16] mm/migrate: allow migrate_vma() to alloc new page on empty entry Jérôme Glisse 2017-03-16 16:05 ` Jérôme Glisse 2017-03-16 16:05 ` [HMM 15/16] mm/hmm/devmem: device memory hotplug using ZONE_DEVICE Jérôme Glisse 2017-03-16 16:05 ` Jérôme Glisse 2017-03-16 16:05 ` [HMM 16/16] mm/hmm/devmem: dummy HMM device for ZONE_DEVICE memory v2 Jérôme Glisse 2017-03-16 16:05 ` Jérôme Glisse 2017-03-17 6:55 ` Bob Liu 2017-03-17 6:55 ` Bob Liu 2017-03-17 16:53 ` Jerome Glisse 2017-03-17 16:53 ` Jerome Glisse 2017-03-16 20:43 ` [HMM 00/16] HMM (Heterogeneous Memory Management) v18 Andrew Morton 2017-03-16 20:43 ` Andrew Morton 2017-03-16 23:49 ` Jerome Glisse 2017-03-16 23:49 ` Jerome Glisse 2017-03-17 8:29 ` Bob Liu 2017-03-17 8:29 ` Bob Liu 2017-03-17 15:57 ` Jerome Glisse 2017-03-17 15:57 ` Jerome Glisse 2017-03-17 8:39 ` Bob Liu 2017-03-17 8:39 ` Bob Liu 2017-03-17 15:52 ` Jerome Glisse 2017-03-17 15:52 ` Jerome Glisse 2017-03-19 20:09 ` Mel Gorman 2017-03-19 20:09 ` Mel Gorman
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=a8b67ed5-118c-6da5-1db6-6edf836f9230@gmail.com \ --to=bsingharora@gmail.com \ --cc=SCheung@nvidia.com \ --cc=akpm@linux-foundation.org \ --cc=dnellans@nvidia.com \ --cc=ebaskakov@nvidia.com \ --cc=jglisse@redhat.com \ --cc=jhubbard@nvidia.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=mhairgrove@nvidia.com \ --cc=n-horiguchi@ah.jp.nec.com \ --cc=sgutti@nvidia.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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.