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: Wed, 20 Apr 2016 11:18:54 +0800 [thread overview]
Message-ID: <5716F51E.70101@hisilicon.com> (raw)
In-Reply-To: <20160412145903.GF8066@e104818-lin.cambridge.arm.com>
Hi Catalin,
Thanks for your reply.
On 2016/4/12 22:59, Catalin Marinas 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:
>>> On 2016/4/11 16:00, Ard Biesheuvel wrote:
>>>> On 11 April 2016 at 09:55, Chen Feng <puck.chen@hisilicon•com> wrote:
>>>>> On 2016/4/11 15:35, Ard Biesheuvel wrote:
>>>>>> On 11 April 2016 at 04:49, Chen Feng <puck.chen@hisilicon•com> wrote:
>>>>>>> 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.
>>>>>
>>>>
>>>> No, it is not. It may be covered by a section, but that does not mean
>>>> sparsemem vmemmap will actually allocate backing for it. The
>>>> granularity used by sparsemem vmemmap on a 4k pages kernel is 128 MB,
>>>> due to the fact that the backing is performed at PMD granularity.
>>>>
>>>> Please, could you share the contents of the vmemmap section in
>>>> /sys/kernel/debug/kernel_page_tables of your system running with
>>>> sparsemem vmemmap enabled? You will need to set CONFIG_ARM64_PTDUMP=y
>>>
>>> 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 ]---
> [...]
>>> 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.
>
> IIRC, SECTION_SIZE_BITS was chosen to be the maximum sane value we were
> thinking of at the time, assuming that 1GB RAM alignment to be fairly
> normal. For the !SPARSEMEM_VMEMMAP case, we should probably be fine with
> 29 but, as Will said, we need to be careful with the page flags. At a
> quick look, we have 25 page flags, 2 bits per zone, NUMA nodes and (48 -
> section_size_bits) for the section width. We also need to take into
> account 4 more bits for 52-bit PA support (ARMv8.2). So, without NUMA
> nodes, we are currently at 49 bits used in page->flags.
>
> For the SPARSEMEM_VMEMMAP case, we can decrease the SECTION_SIZE_BITS in
> the MAX_ORDER limit.
>
> An alternative would be to free the vmemmap holes later (but still keep
> the vmemmap mapping alias). Yet another option would be to change the
> sparse_mem_map_populate() logic get the actual section end rather than
> always assuming PAGES_PER_SECTION. But I don't think any of these are
> worth if we can safely reduce SECTION_SIZE_BITS.
>
Yes,
currently,it's safely to reduce the SECTION_SIZE_BITS to match this issue
very well.
As I mentioned before, if the memory layout is not like this scene. There
will be not suitable to reduce the SECTION_SIZE_BITS.
We have 4G memory, and 64GB phys address.
There will be a lot of holes in the memory layout.
And the *holes size are not always the same*.
So,it's the reason I want to enable flat-mem in ARM64-ARCH. Why not makes
the flat-mem an optional setting for arm64?
next prev parent reply other threads:[~2016-04-20 3:18 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
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 [this message]
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=5716F51E.70101@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