Early patches to get rid of meminfo
cover Early patches to get rid of meminfo
Hi,
With the move away from bootmem and the convergence on memblock, it seems like meminfo should be deprecated as well to avoid duplication. This is a first pass attempt to just use memblock and not have meminfo integrated. There is still a major issue in terms of actually specifying mem at location on the command line but I wanted to send this out for some early feedback before putting any more effort into this. I've done basic boot testing on a simple DT target.
Thanks,
Laura
Laura Abbott (2):
mm/memblock: add memblock_get_current_limit
arm: Get rid of meminfo
arch/arm/include/asm/mach/arch.h | 4 +- arch/arm/include/asm/memblock.h | 3 +- arch/arm/include/asm/setup.h | 23 ------ arch/arm/kernel/atags_parse.c | 5 +- arch/arm/kernel/setup.c | 33 +++------ arch/arm/mach-clps711x/board-clep7312.c | 7 +- arch/arm/mach-clps711x/board-edb7211.c | 10 +-- arch/arm/mach-clps711x/board-p720t.c | 2 +- arch/arm/mach-footbridge/cats-hw.c | 2 +- arch/arm/mach-footbridge/netwinder-hw.c | 2 +- arch/arm/mach-msm/board-halibut.c | 6 -- arch/arm/mach-msm/board-mahimahi.c | 13 +-- arch/arm/mach-msm/board-msm7x30.c | 3 +- arch/arm/mach-msm/board-sapphire.c | 13 +-- arch/arm/mach-msm/board-trout.c | 8 +- arch/arm/mach-orion5x/common.c | 3 +- arch/arm/mach-orion5x/common.h | 3 +- arch/arm/mach-pxa/cm-x300.c | 3 +- arch/arm/mach-pxa/corgi.c | 10 +-- arch/arm/mach-pxa/eseries.c | 9 +- arch/arm/mach-pxa/poodle.c | 8 +- arch/arm/mach-pxa/spitz.c | 9 +-- arch/arm/mach-pxa/tosa.c | 8 +- arch/arm/mach-realview/core.c | 11 +-- arch/arm/mach-realview/core.h | 3 +- arch/arm/mach-realview/realview_pb1176.c | 8 +- arch/arm/mach-realview/realview_pbx.c | 17 ++--- arch/arm/mach-s3c24xx/mach-smdk2413.c | 8 +- arch/arm/mach-s3c24xx/mach-vstms.c | 8 +- arch/arm/mach-sa1100/assabet.c | 2 +- arch/arm/mm/init.c | 61 ++++++---------- arch/arm/mm/mmu.c | 122 ++++++++++-------------------- include/linux/memblock.h | 2 + mm/memblock.c | 5 + 34 files changed, 150 insertions(+), 284 deletions(-)
Signature · 2 lines
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation
A message that is not in the archive (sent off-list or not yet received): [email protected]
RFC 2/2 arm: Get rid of meminfo
Quoted 4 lines · Laura Abbott
memblock is now fully integrated into the kernel and is the prefered method for tracking memory. Rather than reinvent the wheel with meminfo, migrate to using memblock directly instead of meminfo as an intermediate.
The reason I never killed meminfo was that for some of the functions here is that meminfo has a slightly different property to memblock.
With meminfo, each sparsemem section mapping or discontigmem node must be specified as a separate bank of memory, even if it is contiguous with the previous block. This is so that the functions which walk the page arrays can do so efficiently (without having to convert from a PFN to a struct page for every page in the system, which is very inefficient.)
Memblock appends contiguous blocks together, so it reports only one block. This means that if we take the struct page for the start of the block, and the struct page for the end of the block, these may be different struct page arrays, and we can't walk it by just incrementing the struct page pointer.
Signature · 3 lines
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad. Estimate before purchase was "up to 13.2Mbit".
RFC 2/2 arm: Get rid of meminfo
Quoted 6 lines · Russell King - ARM Linux
Quoted 4 lines · Laura Abbott
memblock is now fully integrated into the kernel and is the prefered method for tracking memory. Rather than reinvent the wheel with meminfo, migrate to using memblock directly instead of meminfo as an intermediate.
Quoted 8 lines
The reason I never killed meminfo was that for some of the functions here is that meminfo has a slightly different property to memblock.
With meminfo, each sparsemem section mapping or discontigmem node must be specified as a separate bank of memory, even if it is contiguous with the previous block. This is so that the functions which walk the page arrays can do so efficiently (without having to convert from a PFN to a struct page for every page in the system, which is very inefficient.)
pfn_to_page() conversion is indeed expensive with sparsemem (on 32-bit) but does meminfo actually add a noticeable improvement to the boot time? I don't think so but it's worth testing (something a thousand cycles maximum would be lost in the noise).
Signature · 1 line
Catalin
RFC 2/2 arm: Get rid of meminfo
Quoted 17 lines · Catalin Marinas
Quoted 6 lines · Russell King - ARM Linux
Quoted 4 lines · Laura Abbott
memblock is now fully integrated into the kernel and is the prefered method for tracking memory. Rather than reinvent the wheel with meminfo, migrate to using memblock directly instead of meminfo as an intermediate.
Quoted 8 lines
The reason I never killed meminfo was that for some of the functions here is that meminfo has a slightly different property to memblock.
With meminfo, each sparsemem section mapping or discontigmem node must be specified as a separate bank of memory, even if it is contiguous with the previous block. This is so that the functions which walk the page arrays can do so efficiently (without having to convert from a PFN to a struct page for every page in the system, which is very inefficient.)
Quoted 4 lines
pfn_to_page()conversion is indeed expensive with sparsemem (on 32-bit) but does meminfo actually add a noticeable improvement to the boot time? I don't think so but it's worth testing (something a thousand cycles maximum would be lost in the noise).
Why do you ask about boot time?
Signature · 3 lines
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad. Estimate before purchase was "up to 13.2Mbit".
RFC 2/2 arm: Get rid of meminfo
Quoted 18 lines · Russell King - ARM Linux
Quoted 17 lines · Catalin Marinas
Quoted 14 lines · Russell King - ARM Linux
Quoted 4 lines · Laura Abbott
memblock is now fully integrated into the kernel and is the prefered method for tracking memory. Rather than reinvent the wheel with meminfo, migrate to using memblock directly instead of meminfo as an intermediate.
The reason I never killed meminfo was that for some of the functions here is that meminfo has a slightly different property to memblock.
With meminfo, each sparsemem section mapping or discontigmem node must be specified as a separate bank of memory, even if it is contiguous with the previous block. This is so that the functions which walk the page arrays can do so efficiently (without having to convert from a PFN to a struct page for every page in the system, which is very inefficient.)
Quoted 6 lines
Quoted 4 lines
pfn_to_page()conversion is indeed expensive with sparsemem (on 32-bit) but does meminfo actually add a noticeable improvement to the boot time? I don't think so but it's worth testing (something a thousand cycles maximum would be lost in the noise).Why do you ask about boot time?
Is meminfo used on a critical path at run-time?
Signature · 1 line
Catalin
RFC 2/2 arm: Get rid of meminfo
Quoted 19 lines · Catalin Marinas
Quoted 18 lines · Russell King - ARM Linux
Quoted 17 lines · Catalin Marinas
Quoted 14 lines · Russell King - ARM Linux
Quoted 4 lines · Laura Abbott
memblock is now fully integrated into the kernel and is the prefered method for tracking memory. Rather than reinvent the wheel with meminfo, migrate to using memblock directly instead of meminfo as an intermediate.
The reason I never killed meminfo was that for some of the functions here is that meminfo has a slightly different property to memblock.
With meminfo, each sparsemem section mapping or discontigmem node must be specified as a separate bank of memory, even if it is contiguous with the previous block. This is so that the functions which walk the page arrays can do so efficiently (without having to convert from a PFN to a struct page for every page in the system, which is very inefficient.)
Quoted 9 lines
Quoted 6 lines
Quoted 4 lines
pfn_to_page()conversion is indeed expensive with sparsemem (on 32-bit) but does meminfo actually add a noticeable improvement to the boot time? I don't think so but it's worth testing (something a thousand cycles maximum would be lost in the noise).Why do you ask about boot time?
Is meminfo used on a critical path at run-time?
As far as I can tell, the only place meminfo is used after initialization is in show_mem which isn't a critical path. Are there other paths I missed?
Thanks,
Laura
Signature · 2 lines
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
cover Early patches to get rid of meminfo
In reply to Laura AbbottHi Laura,
Quoted 7 lines · Laura Abbott
With the move away from bootmem and the convergence on memblock, it seems like meminfo should be deprecated as well to avoid duplication. This is a first pass attempt to just use memblock and not have meminfo integrated. There is still a major issue in terms of actually specifying mem at location on the command line but I wanted to send this out for some early feedback before putting any more effort into this. I've done basic boot testing on a simple DT target.
I can't see 1/2 and 2/2 - either in my inbox or in the archive. Could you resend?
/
Leif
cover Early patches to get rid of meminfo
Quoted 11 lines · Leif Lindholm
Hi Laura,
Quoted 7 lines · Laura Abbott
With the move away from bootmem and the convergence on memblock, it seems like meminfo should be deprecated as well to avoid duplication. This is a first pass attempt to just use memblock and not have meminfo integrated. There is still a major issue in terms of actually specifying mem at location on the command line but I wanted to send this out for some early feedback before putting any more effort into this. I've done basic boot testing on a simple DT target.
Quoted 5 lines
I can't see 1/2 and 2/2 - either in my inbox or in the archive. Could you resend?
/
Leif
The patches are being held for moderation because apparently they have "a suspicious header". Not sure how the cover letter made it through but the patches didn't. If they don't get approved by end of the day I'll try re-sending.
Thanks,
Laura
Signature · 2 lines
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
cover Early patches to get rid of meminfo
Quoted 24 lines · Laura Abbott
Quoted 15 lines · Leif Lindholm
Hi Laura,
Quoted 9 lines · Laura Abbott
With the move away from bootmem and the convergence on memblock, it seems like meminfo should be deprecated as well to avoid duplication. This is a first pass attempt to just use memblock and not have meminfo integrated.
There is still a major issue in terms of actually specifying mem at location on the command line but I wanted to send this out for some early feedback before putting any more effort into this. I've done basic boot testing on a simple DT target.Quoted 5 lines
I can't see 1/2 and 2/2 - either in my inbox or in the archive. Could you resend?
/
Leif
Quoted 5 lines
The patches are being held for moderation because apparently they have "a suspicious header". Not sure how the cover letter made it through but the patches didn't. If they don't get approved by end of the day I'll try re-sending.
Hi Laura,
This is a known issue that is triggered by the fact that the word PATCH is missing from your subject line.
Could you resend but replace 'RFC' with 'RFC PATCH' ?
Signature · 1 line
Ard.
cover Early patches to get rid of meminfo
Quoted 31 lines · Ard Biesheuvel
Quoted 24 lines · Laura Abbott
Quoted 15 lines · Leif Lindholm
Hi Laura,
Quoted 9 lines · Laura Abbott
With the move away from bootmem and the convergence on memblock, it seems like meminfo should be deprecated as well to avoid duplication. This is a first pass attempt to just use memblock and not have meminfo integrated.
There is still a major issue in terms of actually specifying mem at location on the command line but I wanted to send this out for some early feedback before putting any more effort into this. I've done basic boot testing on a simple DT target.Quoted 5 lines
I can't see 1/2 and 2/2 - either in my inbox or in the archive. Could you resend?
/
LeifQuoted 5 lines
The patches are being held for moderation because apparently they have "a suspicious header". Not sure how the cover letter made it through but the patches didn't. If they don't get approved by end of the day I'll try re-sending.
Quoted 6 lines
Hi Laura,
This is a known issue that is triggered by the fact that the word PATCH is missing from your subject line.
Could you resend but replace 'RFC' with 'RFC PATCH' ?
Thanks for catching that, I will resend.
Laura
Signature · 2 lines
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
cover Early patches to get rid of meminfo
In reply to Laura AbbottQuoted 9 lines · Laura Abbott
Hi,
With the move away from bootmem and the convergence on memblock, it seems like meminfo should be deprecated as well to avoid duplication. This is a first pass attempt to just use memblock and not have meminfo integrated. There is still a major issue in terms of actually specifying mem at location on the command line but I wanted to send this out for some early feedback before putting any more effort into this. I've done basic boot testing on a simple DT target.
Nice. One thing I would like to see done in this area is ARM using the default early_init_dt_add_memory_arch function. It currently doesn't because of the dependency on meminfo.
Rob