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
next prev parent 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).