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 18:57:20 +0800 [thread overview]
Message-ID: <570B8310.40103@hisilicon.com> (raw)
In-Reply-To: <20160411104013.GG15729@arm.com>
Hi Will,
On 2016/4/11 18:40, Will Deacon wrote:
> On Mon, Apr 11, 2016 at 12:31:53PM +0200, Ard Biesheuvel wrote:
>> On 11 April 2016 at 11:59, Chen Feng <puck.chen@hisilicon•com> wrote:
>>> Please see the pg-tables below.
>>>
>>>
>>> With sparse and vmemmap enable.
>>>
>>> ---[ vmemmap start ]---
>>> 0xffffffbdc0200000-0xffffffbdc4800000 70M RW NX SHD AF UXN MEM/NORMAL
>>> ---[ vmemmap end ]---
>>>
>>
>> OK, I see what you mean now. Sorry for taking so long to catch up.
>>
>>> The board is 4GB, and the memap is 70MB
>>> 1G memory --- 14MB mem_map array.
>>
>> No, this is incorrect. 1 GB corresponds with 16 MB worth of struct
>> pages assuming sizeof(struct page) == 64
>>
>> So you are losing 6 MB to rounding here, which I agree is significant.
>> I wonder if it makes sense to use a lower value for SECTION_SIZE_BITS
>> on 4k pages kernels, but perhaps we're better off asking the opinion
>> of the other cc'ees.
>
> You need to be really careful making SECTION_SIZE_BITS smaller because
> it has a direct correlation on the use of page->flags and you can end up
> running out of bits fairly easily.
Yes, making SECTION_SIZE_BITS smaller can solve the current situation.
But if the phys-addr is 64GB, but only 4GB ddr is the valid address. And the
holes are not always 512MB.
But, can you tell us why *smaller SIZE makes running out of bits fairly easily*?
And how about the flat-mem model?
>
> Will
>
> .
>
next prev parent reply other threads:[~2016-04-11 10:57 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
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 [this message]
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=570B8310.40103@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