* [PATCH] ARM:mm: define arch-specific IOREMAP_MAX_ORDER only in !SMP && !LPAE case [not found] <1441680050-50490-1-git-send-email-zhenzhang.zhang@huawei.com> @ 2015-09-08 2:45 ` Zhang Zhen 2015-09-08 18:12 ` Sergey Dyasly 0 siblings, 1 reply; 5+ messages in thread From: Zhang Zhen @ 2015-09-08 2:45 UTC (permalink / raw) To: linux-arm-kernel The arch-specific IOREMAP_MAX_ORDER is introduced in commit: ff0daca([ARM] Add section support to ioremap) and commit: a069c89 ([ARM] 3705/1: add supersection support to ioremap()). But supersections and sections mappings are only used in !SMP && !LPAE case. Otherwise, mapping is created using the usual 4K pages. In most cases without !SMP && !LPAE, the big alignment cause high fragmentation issue in vmalloc area. Here we use arch-specific IOREMAP_MAX_ORDER only in !SMP && !LPAE case, otherwise use generic IOREMAP_MAX_ORDER in include/linux/vmalloc.h. Signed-off-by: Zhang Zhen <zhenzhang.zhang@huawei.com> --- arch/arm/include/asm/memory.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h index b7f6fb4..3209012 100644 --- a/arch/arm/include/asm/memory.h +++ b/arch/arm/include/asm/memory.h @@ -76,10 +76,12 @@ */ #define XIP_VIRT_ADDR(physaddr) (MODULES_VADDR + ((physaddr) & 0x000fffff)) +#if !defined(CONFIG_SMP) && !defined(CONFIG_ARM_LPAE) /* * Allow 16MB-aligned ioremap pages */ #define IOREMAP_MAX_ORDER 24 +#endif #else /* CONFIG_MMU */ -- 1.9.1 . ^ permalink raw reply related [flat|nested] 5+ messages in thread
* [PATCH] ARM:mm: define arch-specific IOREMAP_MAX_ORDER only in !SMP && !LPAE case 2015-09-08 2:45 ` [PATCH] ARM:mm: define arch-specific IOREMAP_MAX_ORDER only in !SMP && !LPAE case Zhang Zhen @ 2015-09-08 18:12 ` Sergey Dyasly 2015-09-09 1:22 ` Zhang Zhen 2015-09-09 3:10 ` Nicolas Pitre 0 siblings, 2 replies; 5+ messages in thread From: Sergey Dyasly @ 2015-09-08 18:12 UTC (permalink / raw) To: linux-arm-kernel On 08.09.2015 5:45, Zhang Zhen wrote: > The arch-specific IOREMAP_MAX_ORDER is introduced in > commit: ff0daca([ARM] Add section support to ioremap) and > commit: a069c89 ([ARM] 3705/1: add supersection support to ioremap()). > But supersections and sections mappings are only used in !SMP && !LPAE case. > Otherwise, mapping is created using the usual 4K pages. > > In most cases without !SMP && !LPAE, the big alignment cause high fragmentation > issue in vmalloc area. > Here we use arch-specific IOREMAP_MAX_ORDER only in !SMP && !LPAE case, > otherwise use generic IOREMAP_MAX_ORDER in include/linux/vmalloc.h. > > Signed-off-by: Zhang Zhen <zhenzhang.zhang@huawei.com> > --- > arch/arm/include/asm/memory.h | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h > index b7f6fb4..3209012 100644 > --- a/arch/arm/include/asm/memory.h > +++ b/arch/arm/include/asm/memory.h > @@ -76,10 +76,12 @@ > */ > #define XIP_VIRT_ADDR(physaddr) (MODULES_VADDR + ((physaddr) & 0x000fffff)) > > +#if !defined(CONFIG_SMP) && !defined(CONFIG_ARM_LPAE) > /* > * Allow 16MB-aligned ioremap pages > */ > #define IOREMAP_MAX_ORDER 24 > +#endif > > #else /* CONFIG_MMU */ > Hmm... This looks exactly like my old patch - http://thread.gmane.org/gmane.linux.kernel.mm/127620 (Thanks to Vladimir for pointing that out!) Hasn't there been any progress about this issue? ^ permalink raw reply [flat|nested] 5+ messages in thread
* [PATCH] ARM:mm: define arch-specific IOREMAP_MAX_ORDER only in !SMP && !LPAE case 2015-09-08 18:12 ` Sergey Dyasly @ 2015-09-09 1:22 ` Zhang Zhen 2015-09-09 3:10 ` Nicolas Pitre 1 sibling, 0 replies; 5+ messages in thread From: Zhang Zhen @ 2015-09-09 1:22 UTC (permalink / raw) To: linux-arm-kernel On 2015/9/9 2:12, Sergey Dyasly wrote: > On 08.09.2015 5:45, Zhang Zhen wrote: >> The arch-specific IOREMAP_MAX_ORDER is introduced in >> commit: ff0daca([ARM] Add section support to ioremap) and >> commit: a069c89 ([ARM] 3705/1: add supersection support to ioremap()). >> But supersections and sections mappings are only used in !SMP && !LPAE case. >> Otherwise, mapping is created using the usual 4K pages. >> >> In most cases without !SMP && !LPAE, the big alignment cause high fragmentation >> issue in vmalloc area. >> Here we use arch-specific IOREMAP_MAX_ORDER only in !SMP && !LPAE case, >> otherwise use generic IOREMAP_MAX_ORDER in include/linux/vmalloc.h. >> >> Signed-off-by: Zhang Zhen <zhenzhang.zhang@huawei.com> >> --- >> arch/arm/include/asm/memory.h | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h >> index b7f6fb4..3209012 100644 >> --- a/arch/arm/include/asm/memory.h >> +++ b/arch/arm/include/asm/memory.h >> @@ -76,10 +76,12 @@ >> */ >> #define XIP_VIRT_ADDR(physaddr) (MODULES_VADDR + ((physaddr) & 0x000fffff)) >> >> +#if !defined(CONFIG_SMP) && !defined(CONFIG_ARM_LPAE) >> /* >> * Allow 16MB-aligned ioremap pages >> */ >> #define IOREMAP_MAX_ORDER 24 >> +#endif >> >> #else /* CONFIG_MMU */ >> > > Hmm... This looks exactly like my old patch - > http://thread.gmane.org/gmane.linux.kernel.mm/127620 > (Thanks to Vladimir for pointing that out!) > > Hasn't there been any progress about this issue? > Oh sorry i didn't notice your old patch. I send this patch because we encountered high fragmentation issue in vmalloc area and the link about this issue. http://lists.infradead.org/pipermail/linux-arm-kernel/2015-January/313040.html Let's drop my patch. Besides, i just want to know why this patch is not included into the upstream kernel? Thanks! > . > ^ permalink raw reply [flat|nested] 5+ messages in thread
* [PATCH] ARM:mm: define arch-specific IOREMAP_MAX_ORDER only in !SMP && !LPAE case 2015-09-08 18:12 ` Sergey Dyasly 2015-09-09 1:22 ` Zhang Zhen @ 2015-09-09 3:10 ` Nicolas Pitre 2015-09-09 18:28 ` Sergey Dyasly 1 sibling, 1 reply; 5+ messages in thread From: Nicolas Pitre @ 2015-09-09 3:10 UTC (permalink / raw) To: linux-arm-kernel On Tue, 8 Sep 2015, Sergey Dyasly wrote: > On 08.09.2015 5:45, Zhang Zhen wrote: > > The arch-specific IOREMAP_MAX_ORDER is introduced in > > commit: ff0daca([ARM] Add section support to ioremap) and > > commit: a069c89 ([ARM] 3705/1: add supersection support to ioremap()). > > But supersections and sections mappings are only used in !SMP && !LPAE case. > > Otherwise, mapping is created using the usual 4K pages. > > > > In most cases without !SMP && !LPAE, the big alignment cause high > > fragmentation > > issue in vmalloc area. > > Here we use arch-specific IOREMAP_MAX_ORDER only in !SMP && !LPAE case, > > otherwise use generic IOREMAP_MAX_ORDER in include/linux/vmalloc.h. > > > > Signed-off-by: Zhang Zhen <zhenzhang.zhang@huawei.com> > > --- > > arch/arm/include/asm/memory.h | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h > > index b7f6fb4..3209012 100644 > > --- a/arch/arm/include/asm/memory.h > > +++ b/arch/arm/include/asm/memory.h > > @@ -76,10 +76,12 @@ > > */ > > #define XIP_VIRT_ADDR(physaddr) (MODULES_VADDR + ((physaddr) & > > 0x000fffff)) > > > > +#if !defined(CONFIG_SMP) && !defined(CONFIG_ARM_LPAE) > > /* > > * Allow 16MB-aligned ioremap pages > > */ > > #define IOREMAP_MAX_ORDER 24 > > +#endif > > > > #else /* CONFIG_MMU */ > > > > Hmm... This looks exactly like my old patch - > http://thread.gmane.org/gmane.linux.kernel.mm/127620 > (Thanks to Vladimir for pointing that out!) > > Hasn't there been any progress about this issue? IMHO the patch makes sense. Did you send it to RMK's patch system? Nicolas ^ permalink raw reply [flat|nested] 5+ messages in thread
* [PATCH] ARM:mm: define arch-specific IOREMAP_MAX_ORDER only in !SMP && !LPAE case 2015-09-09 3:10 ` Nicolas Pitre @ 2015-09-09 18:28 ` Sergey Dyasly 0 siblings, 0 replies; 5+ messages in thread From: Sergey Dyasly @ 2015-09-09 18:28 UTC (permalink / raw) To: linux-arm-kernel On 09.09.2015 6:10, Nicolas Pitre wrote: > On Tue, 8 Sep 2015, Sergey Dyasly wrote: > >> On 08.09.2015 5:45, Zhang Zhen wrote: >>> The arch-specific IOREMAP_MAX_ORDER is introduced in >>> commit: ff0daca([ARM] Add section support to ioremap) and >>> commit: a069c89 ([ARM] 3705/1: add supersection support to ioremap()). >>> But supersections and sections mappings are only used in !SMP && !LPAE case. >>> Otherwise, mapping is created using the usual 4K pages. >>> >>> In most cases without !SMP && !LPAE, the big alignment cause high >>> fragmentation >>> issue in vmalloc area. >>> Here we use arch-specific IOREMAP_MAX_ORDER only in !SMP && !LPAE case, >>> otherwise use generic IOREMAP_MAX_ORDER in include/linux/vmalloc.h. >>> >>> Signed-off-by: Zhang Zhen <zhenzhang.zhang@huawei.com> >>> --- >>> arch/arm/include/asm/memory.h | 2 ++ >>> 1 file changed, 2 insertions(+) >>> >>> diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h >>> index b7f6fb4..3209012 100644 >>> --- a/arch/arm/include/asm/memory.h >>> +++ b/arch/arm/include/asm/memory.h >>> @@ -76,10 +76,12 @@ >>> */ >>> #define XIP_VIRT_ADDR(physaddr) (MODULES_VADDR + ((physaddr) & >>> 0x000fffff)) >>> >>> +#if !defined(CONFIG_SMP) && !defined(CONFIG_ARM_LPAE) >>> /* >>> * Allow 16MB-aligned ioremap pages >>> */ >>> #define IOREMAP_MAX_ORDER 24 >>> +#endif >>> >>> #else /* CONFIG_MMU */ >>> >> Hmm... This looks exactly like my old patch - >> http://thread.gmane.org/gmane.linux.kernel.mm/127620 >> (Thanks to Vladimir for pointing that out!) >> >> Hasn't there been any progress about this issue? > IMHO the patch makes sense. > > Did you send it to RMK's patch system? Ok, submitted it to the patch system. Thanks! > > > Nicolas ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2015-09-09 18:28 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <1441680050-50490-1-git-send-email-zhenzhang.zhang@huawei.com>
2015-09-08 2:45 ` [PATCH] ARM:mm: define arch-specific IOREMAP_MAX_ORDER only in !SMP && !LPAE case Zhang Zhen
2015-09-08 18:12 ` Sergey Dyasly
2015-09-09 1:22 ` Zhang Zhen
2015-09-09 3:10 ` Nicolas Pitre
2015-09-09 18:28 ` Sergey Dyasly
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).