From: David Hildenbrand <firstname.lastname@example.org> To: Mike Rapoport <email@example.com> Cc: Ard Biesheuvel <firstname.lastname@example.org>, Linux ARM <email@example.com>, Anshuman Khandual <firstname.lastname@example.org>, Catalin Marinas <email@example.com>, Marc Zyngier <firstname.lastname@example.org>, Mark Rutland <email@example.com>, Mike Rapoport <firstname.lastname@example.org>, Will Deacon <email@example.com>, kvmarm <firstname.lastname@example.org>, Linux Kernel Mailing List <email@example.com>, Linux Memory Management List <firstname.lastname@example.org> Subject: Re: [RFC/RFT PATCH 1/3] memblock: update initialization of reserved pages Date: Fri, 16 Apr 2021 13:54:00 +0200 [thread overview] Message-ID: <email@example.com> (raw) In-Reply-To: <YHl4mqgh5CtNk1l7@kernel.org> 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
next prev parent reply other threads:[~2021-04-16 11:54 UTC|newest] Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-04-07 17:26 [RFC/RFT PATCH 0/3] arm64: drop pfn_valid_within() and simplify pfn_valid() Mike Rapoport 2021-04-07 17:26 ` [RFC/RFT PATCH 1/3] memblock: update initialization of reserved pages Mike Rapoport 2021-04-08 5:16 ` Anshuman Khandual 2021-04-08 5:48 ` Mike Rapoport 2021-04-14 15:12 ` David Hildenbrand 2021-04-14 15:27 ` Ard Biesheuvel 2021-04-14 15:52 ` David Hildenbrand 2021-04-14 20:24 ` Mike Rapoport 2021-04-15 9:30 ` David Hildenbrand 2021-04-16 11:44 ` Mike Rapoport 2021-04-16 11:54 ` David Hildenbrand [this message] 2021-04-14 20:11 ` Mike Rapoport 2021-04-14 20:06 ` Mike Rapoport 2021-04-07 17:26 ` [RFC/RFT PATCH 2/3] arm64: decouple check whether pfn is normal memory from pfn_valid() Mike Rapoport 2021-04-08 5:14 ` Anshuman Khandual 2021-04-08 6:00 ` Mike Rapoport 2021-04-14 15:58 ` David Hildenbrand 2021-04-14 20:29 ` Mike Rapoport 2021-04-15 9:31 ` David Hildenbrand 2021-04-16 11:40 ` Mike Rapoport 2021-04-07 17:26 ` [RFC/RFT PATCH 3/3] arm64: drop pfn_valid_within() and simplify pfn_valid() Mike Rapoport 2021-04-08 5:12 ` Anshuman Khandual 2021-04-08 6:17 ` Mike Rapoport 2021-04-08 5:19 ` [RFC/RFT PATCH 0/3] " Anshuman Khandual 2021-04-08 6:27 ` Mike Rapoport
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 \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: [RFC/RFT PATCH 1/3] memblock: update initialization of reserved pages' \ /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
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).