lkml.org 
[lkml]   [2022]   [Jun]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v4 2/2] mm: memory_hotplug: make hugetlb_optimize_vmemmap compatible with memmap_on_memory
On Mon, Jun 20, 2022 at 04:29:11PM +0800, Muchun Song wrote:
> > > Although it works, I think PageVmemmapSelfHosted() check for the 1st pfn's
> > > vmemmap page is not always reliable. Since we reused PG_owner_priv_1
> > > as PG_vmemmap_self_hosted, the test is noly reliable for vmemmap page's
> > > vmemmap page. Other non-vmemmap page can be flagged with PG_owner_priv_1.
> > > So this check can be false-positive. Maybe the following code snippet is
> > > the solution.
> >
> > How could that happen for pages used for backing a vmemmap?
> >
>
> It cannot happen for memmap_on_memory case. Howwver, it can happen for other
> cases. E.g. the 1st pfn (of boot memory block) whose vmemmap page may be flagged
> as PG_owner_priv_1 (if PG_swapcache is set). Then, the check is false-positive.

If this can really happen, which I am not that sure tbh, maybe a way out would be
to just define a new page-type as we did in previous versions of memmap_on_memory.
In that way we would not for flags, but for its type.

But as I said, I am not entirely sure about the potential fallout of what you mention.


--
Oscar Salvador
SUSE Labs

\
 
 \ /
  Last update: 2022-06-20 10:45    [W:0.149 / U:0.072 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site