All of lore.kernel.org
 help / color / mirror / Atom feed
From: Zhang Zhen <zhenzhang.zhang@huawei.com>
To: Yinghai Lu <yinghai@kernel.org>
Cc: Linux MM <linux-mm@kvack.org>, wangnan0@huawei.com
Subject: Re: How to boot up an ARM board enabled CONFIG_SPARSEMEM
Date: Wed, 2 Jul 2014 14:48:27 +0800	[thread overview]
Message-ID: <53B3AB3B.1050809@huawei.com> (raw)
In-Reply-To: <CAE9FiQWpPOELEAOZxxZafpkYqYPurL_Fx_zJsS4XM+DmFCYbxg@mail.gmail.com>

On 2014/7/2 2:45, Yinghai Lu wrote:
> On Tue, Jul 1, 2014 at 12:29 AM, Zhang Zhen <zhenzhang.zhang@huawei.com> wrote:
>> Hi,
>>
>> Recently We are testing stable kernel 3.10 on an ARM board.
>> It failed to boot if we enabled CONFIG_SPARSEMEM config.
> 
> Arm support 2 sockets and numa now?
> 
ARM doesn't support numa until now. We have added memory hotplug feature on ARM arch.
So we need to enable CONFIG_SPARSEMEM.

>> 1. In mem_init() and show_mem() compare pfn instead of page just like the patch in attachement.
>> 2. Enable CONFIG_SPARSEMEM_ALLOC_MEM_MAP_TOGETHER when enabled CONFIG_SPARSEMEM.
>>
>> QUESTION:
>>
>> I want to know why CONFIG_SPARSEMEM_ALLOC_MEM_MAP_TOGETHER depends on x86_64 ?
> 
> That make memory allocation have less memory hole, from old bootmem bitmap
> allocation stage.
> 
> Maybe we don't need that anymore as we have memblock allocation that is more
> smarter with alignment handling.
> 
> Also allocating big size and use them block by block, could save some time on
> searching on allocation function when memblock have lots of entries on
> memory/reserved arrays.
> 
> Thanks
> 
> Yinghai
> 
Hi, Yinghai

Have you seen my patch ?
If we enabled CONFIG_SPARSEMEM here in the patch need to enable CONFIG_SPARSEMEM_ALLOC_MEM_MAP_TOGETHER to
guarantee the pages of different sections are continuous.

So in my opinion, CONFIG_SPARSEMEM_ALLOC_MEM_MAP_TOGETHER doesn't need to depend on x86_64, which helps futher
coding.

If i'm wrong, please let me know !

Thanks for your comments!

> 


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

      reply	other threads:[~2014-07-02  6:48 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <53B26229.5030504@huawei.com>
2014-07-01  7:29 ` How to boot up an ARM board enabled CONFIG_SPARSEMEM Zhang Zhen
2014-07-01 18:45   ` Yinghai Lu
2014-07-02  6:48     ` Zhang Zhen [this message]

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=53B3AB3B.1050809@huawei.com \
    --to=zhenzhang.zhang@huawei.com \
    --cc=linux-mm@kvack.org \
    --cc=wangnan0@huawei.com \
    --cc=yinghai@kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.