linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: lauraa@codeaurora.org (Laura Abbott)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC 2/2] arm: Get rid of meminfo
Date: Wed, 15 Jan 2014 09:55:33 -0800	[thread overview]
Message-ID: <52D6CB95.1000402@codeaurora.org> (raw)
In-Reply-To: <20140115112516.GA17371@arm.com>

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

  reply	other threads:[~2014-01-15 17:55 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-15  5:55 [RFC 0/2] Early patches to get rid of meminfo Laura Abbott
     [not found] ` <1389765322-28582-3-git-send-email-lauraa@codeaurora.org>
2014-01-15  9:49   ` [RFC 2/2] arm: Get " Russell King - ARM Linux
2014-01-15 10:22     ` Catalin Marinas
2014-01-15 10:53       ` Russell King - ARM Linux
2014-01-15 11:25         ` Catalin Marinas
2014-01-15 17:55           ` Laura Abbott [this message]
2014-01-15 13:50 ` [RFC 0/2] Early patches to get " Leif Lindholm
2014-01-15 18:01   ` Laura Abbott
2014-01-15 18:03     ` Ard Biesheuvel
2014-01-15 19:08       ` Laura Abbott
2014-01-15 15:26 ` Rob Herring

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=52D6CB95.1000402@codeaurora.org \
    --to=lauraa@codeaurora.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).