[RFC/RFT PATCH 1/3] memblock: update initialization of reserved pages
David Hildenbrand
david at redhat.com
Fri Apr 16 12:54:00 BST 2021
On 16.04.21 13:44, Mike Rapoport wrote:
> On Thu, Apr 15, 2021 at 11:30:12AM +0200, David Hildenbrand wrote:
>>> Not sure we really need a new pagetype here, PG_Reserved seems to be quite
>>> enough to say "don't touch this". I generally agree that we could make
>>> PG_Reserved a PageType and then have several sub-types for reserved memory.
>>> This definitely will add clarity but I'm not sure that this justifies
>>> amount of churn and effort required to audit uses of PageResrved().
>>>> Then, we could mostly avoid having to query memblock at runtime to figure
>>>> out that this is special memory. This would obviously be an extension to
>>>> this series. Just a thought.
>>>
>>> Stop pushing memblock out of kernel! ;-)
>>
>> Can't stop. Won't stop. :D
>>
>> It's lovely for booting up a kernel until we have other data-structures in
>> place ;)
>
> A bit more seriously, we don't have any data structure that reliably
> represents physical memory layout and arch-independent fashion.
> memblock is probably the best starting point for eventually having one.
We have the (slowish) kernel resource tree after boot and the (faster)
memmap. I really don't see why we really need another slowish variant.
We might be better off to just extend and speed up the kernel resource tree.
Memblock as is is not a reasonable datastructure to keep around after
boot: for example, how we handle boottime allocations and reserve
regions both as reserved.
--
Thanks,
David / dhildenb
More information about the linux-arm-kernel
mailing list