From: puck.chen@hisilicon•com (Chen Feng)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH 1/2] arm64: mem-model: add flatmem model for arm64
Date: Mon, 11 Apr 2016 15:55:33 +0800 [thread overview]
Message-ID: <570B5875.20804@hisilicon.com> (raw)
In-Reply-To: <CAKv+Gu8iQ0NzLFWHy9Ggyv+jL-BqJ3x-KaRD1SZ1mU6yU3c7UQ@mail.gmail.com>
Hi Ard,
On 2016/4/11 15:35, Ard Biesheuvel wrote:
> On 11 April 2016 at 04:49, Chen Feng <puck.chen@hisilicon•com> wrote:
>> Hi will,
>> Thanks for review.
>>
>> On 2016/4/7 22:21, Will Deacon wrote:
>>> On Tue, Apr 05, 2016 at 04:22:51PM +0800, Chen Feng wrote:
>>>> We can reduce the memory allocated at mem-map
>>>> by flatmem.
>>>>
>>>> currently, the default memory-model in arm64 is
>>>> sparse memory. The mem-map array is not freed in
>>>> this scene. If the physical address is too long,
>>>> it will reserved too much memory for the mem-map
>>>> array.
>>>
>>> Can you elaborate a bit more on this, please? We use the vmemmap, so any
>>> spaces between memory banks only burns up virtual space. What exactly is
>>> the problem you're seeing that makes you want to use flatmem (which is
>>> probably unsuitable for the majority of arm64 machines).
>>>
>> The root cause we want to use flat-mem is the mam_map alloced in sparse-mem
>> is not freed.
>>
>> take a look at here:
>> arm64/mm/init.c
>> void __init mem_init(void)
>> {
>> #ifndef CONFIG_SPARSEMEM_VMEMMAP
>> free_unused_memmap();
>> #endif
>> }
>>
>> Memory layout (3GB)
>>
>> 0 1.5G 2G 3.5G 4G
>> | | | | |
>> +--------------+------+---------------+--------------+
>> | MEM | hole | MEM | IO (regs) |
>> +--------------+------+---------------+--------------+
>>
>>
>> Memory layout (4GB)
>>
>> 0 3.5G 4G 4.5G
>> | | | |
>> +-------------------------------------+--------------+-------+
>> | MEM | IO (regs) | MEM |
>> +-------------------------------------+--------------+-------+
>>
>> Currently, the sparse memory section is 1GB.
>>
>> 3GB ddr: the 1.5 ~2G and 3.5 ~ 4G are holes.
>> 3GB ddr: the 3.5 ~ 4G and 4.5 ~ 5G are holes.
>>
>> This will alloc 1G/4K * (struct page) memory for mem_map array.
>>
>
> No, this is incorrect. Sparsemem vmemmap only allocates struct pages
> for memory regions that are actually populated.
>
> For instance, on the Foundation model with 4 GB of memory, you may see
> something like this in the boot log
>
> [ 0.000000] vmemmap : 0xffffffbdc0000000 - 0xffffffbfc0000000
> ( 8 GB maximum)
> [ 0.000000] 0xffffffbdc0000000 - 0xffffffbde2000000
> ( 544 MB actual)
>
> but in reality, only the following regions have been allocated
>
> ---[ vmemmap start ]---
> 0xffffffbdc0000000-0xffffffbdc2000000 32M RW NX SHD AF
> BLK UXN MEM/NORMAL
> 0xffffffbde0000000-0xffffffbde2000000 32M RW NX SHD AF
> BLK UXN MEM/NORMAL
> ---[ vmemmap end ]---
>
> so only 64 MB is used to back 4 GB of RAM with struct pages, which is
> minimal. Moving to flatmem will not reduce the memory footprint at
> all.
Yes,but the populate is section, which is 1GB. Take a look at the above
memory layout.
The section 1G ~ 2G is a section. But 1.5G ~ 2G is a hole.
The section 3G ~ 4G is a section. But 3.5G ~ 4G is a hole.
>> 0 1.5G 2G 3.5G 4G
>> | | | | |
>> +--------------+------+---------------+--------------+
>> | MEM | hole | MEM | IO (regs) |
>> +--------------+------+---------------+--------------+
The hole in 1.5G ~ 2G is also allocated mem-map array. And also with the 3.5G ~ 4G.
We want free the the mem-map array. With flat-mem we can work with this scene very well.
Thanks,
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo at kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@kvack•org"> email at kvack.org </a>
>
> .
>
next prev parent reply other threads:[~2016-04-11 7:55 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-05 8:22 [PATCH 1/2] arm64: mem-model: add flatmem model for arm64 Chen Feng
2016-04-05 8:22 ` [PATCH 2/2] arm64: mm: make pfn always valid with flat memory Chen Feng
2016-04-07 7:39 ` Chen Feng
2016-04-11 11:08 ` Xishi Qiu
2016-04-12 15:00 ` Catalin Marinas
2016-04-07 7:38 ` [PATCH 1/2] arm64: mem-model: add flatmem model for arm64 Chen Feng
2016-04-07 14:21 ` Will Deacon
2016-04-11 2:49 ` Chen Feng
2016-04-11 7:35 ` Ard Biesheuvel
2016-04-11 7:55 ` Chen Feng [this message]
2016-04-11 8:00 ` Ard Biesheuvel
2016-04-11 9:59 ` Chen Feng
2016-04-11 10:31 ` Ard Biesheuvel
2016-04-11 10:40 ` Will Deacon
2016-04-11 10:57 ` Chen Feng
2016-04-11 18:11 ` Laura Abbott
2016-04-12 14:44 ` Catalin Marinas
2016-04-12 14:59 ` Catalin Marinas
2016-04-20 3:18 ` Chen Feng
2016-04-20 9:32 ` Catalin Marinas
2016-04-11 10:48 ` Chen Feng
2016-04-11 11:02 ` Ard Biesheuvel
2016-04-12 14:03 ` Jungseok Lee
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=570B5875.20804@hisilicon.com \
--to=puck.chen@hisilicon$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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