[RFC 0/2] Early patches to get rid of meminfo

[RFC 0/2] Early patches to get rid of meminfo

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

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

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

[RFC 2/2] arm: Get rid of meminfo

[Russell King - ARM Linux]

On Tue, Jan 14, 2014 at 09:55:22PM -0800, Laura Abbott wrote:
> 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.

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

[Catalin Marinas]

On 15 January 2014 09:49, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Tue, Jan 14, 2014 at 09:55:22PM -0800, Laura Abbott wrote:
>> 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.)

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

-- 
Catalin

[RFC 2/2] arm: Get rid of meminfo

[Russell King - ARM Linux]

On Wed, Jan 15, 2014 at 10:22:02AM +0000, Catalin Marinas wrote:
> On 15 January 2014 09:49, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Tue, Jan 14, 2014 at 09:55:22PM -0800, Laura Abbott wrote:
> >> 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.)
> 
> 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?

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

[Catalin Marinas]

On Wed, Jan 15, 2014 at 10:53:47AM +0000, Russell King - ARM Linux wrote:
> On Wed, Jan 15, 2014 at 10:22:02AM +0000, Catalin Marinas wrote:
> > On 15 January 2014 09:49, Russell King - ARM Linux
> > <linux@arm.linux.org.uk> wrote:
> > > On Tue, Jan 14, 2014 at 09:55:22PM -0800, Laura Abbott wrote:
> > >> 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.)
> > 
> > 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?

-- 
Catalin

[RFC 0/2] Early patches to get rid of meminfo

[Leif Lindholm]

Hi Laura,

On Tue, Jan 14, 2014 at 09:55:20PM -0800, Laura Abbott wrote:
> 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

[RFC 0/2] Early patches to get rid of meminfo

[Rob Herring]

On Tue, Jan 14, 2014 at 11:55 PM, Laura Abbott <lauraa@codeaurora.org> wrote:
> 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

[RFC 2/2] arm: Get rid of meminfo

[Laura Abbott]

On 1/15/2014 3:25 AM, Catalin Marinas wrote:
> On Wed, Jan 15, 2014 at 10:53:47AM +0000, Russell King - ARM Linux wrote:
>> On Wed, Jan 15, 2014 at 10:22:02AM +0000, Catalin Marinas wrote:
>>> On 15 January 2014 09:49, Russell King - ARM Linux
>>> <linux@arm.linux.org.uk> wrote:
>>>> On Tue, Jan 14, 2014 at 09:55:22PM -0800, Laura Abbott wrote:
>>>>> 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.)
>>>
>>> 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
-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

[RFC 0/2] Early patches to get rid of meminfo

[Laura Abbott]

On 1/15/2014 5:50 AM, Leif Lindholm wrote:
> Hi Laura,
>
> On Tue, Jan 14, 2014 at 09:55:20PM -0800, Laura Abbott wrote:
>> 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


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

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

[RFC 0/2] Early patches to get rid of meminfo

[Ard Biesheuvel]

On 15 January 2014 19:01, Laura Abbott <lauraa@codeaurora.org> wrote:
> On 1/15/2014 5:50 AM, Leif Lindholm wrote:
>>
>> Hi Laura,
>>
>> On Tue, Jan 14, 2014 at 09:55:20PM -0800, Laura Abbott wrote:
>>>
>>> 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
>
>
>
> 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' ?

-- 
Ard.

[RFC 0/2] Early patches to get rid of meminfo

[Laura Abbott]

On 1/15/2014 10:03 AM, Ard Biesheuvel wrote:
> On 15 January 2014 19:01, Laura Abbott <lauraa@codeaurora.org> wrote:
>> On 1/15/2014 5:50 AM, Leif Lindholm wrote:
>>>
>>> Hi Laura,
>>>
>>> On Tue, Jan 14, 2014 at 09:55:20PM -0800, Laura Abbott wrote:
>>>>
>>>> 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
>>
>>
>>
>> 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' ?
>

Thanks for catching that, I will resend.

Laura

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation