Re: [PATCH v3 2/2] mm/page_alloc: add some comments to explain the possible hole in __pageblock_pfn_to_page()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 4/25/2023 5:05 PM, Michal Hocko wrote:
On Tue 25-04-23 09:27:23, Baolin Wang wrote:


On 4/25/2023 8:22 AM, Huang, Ying wrote:
Baolin Wang <baolin.wang@xxxxxxxxxxxxxxxxx> writes:
[...]
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 6457b64fe562..bd124390c79b 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -1502,6 +1502,15 @@ void __free_pages_core(struct page *page, unsigned int order)
    * interleaving within a single pageblock. It is therefore sufficient to check
    * the first and last page of a pageblock and avoid checking each individual
    * page in a pageblock.
+ *
+ * Note: the function may return non-NULL struct page even for a page block
+ * which contains a memory hole (i.e. there is no physical memory for a subset
+ * of the pfn range). For example, if the pageblock order is MAX_ORDER, which
+ * will fall into 2 sub-sections, and the end pfn of the pageblock may be hole
+ * even though the start pfn is online and valid. This should be safe most of
+ * the time because struct pages are still zero pre-filled and pfn walkers

I don't think the pfn is just zero-filled even it's a hole.  Can you
confirm that?  In memmap_init() and memmap_init_zone_range(),
init_unavailable_range() is called to initialize the struct page.

Yes, what I mean is the page frames were initialized to zero firstly, and
some fields were initialized to default value. The "zero pre-filled" seems
confusing, may be change to "initialized"?

Huang Ying is correct. Holes should have struct pages initialized and
init_unavailable_range actually marks those pages reserved. Which
is really good because they mean "do not touch unless this page is
yours". For some reason I thought those struct pages are simply zero
filled. I was clearly wrong. Maybe it would be good to reference
init_unavailable_range in the comment so that it is easier to track the
whole code path.

OK, will do as you and Huang Ying suggested. Thank you both.

Sorry about that!

never mind:)




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux