[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <19f47b787269b95bb76d81bb1e6bfcc3@suse.de>
Date: Tue, 10 Aug 2021 11:29:11 +0200
From: Oscar Salvador <osalvador@...e.de>
To: Mike Kravetz <mike.kravetz@...cle.com>
Cc: linux-mm@...ck.org, linux-kernel@...r.kernel.org,
Muchun Song <songmuchun@...edance.com>,
Michal Hocko <mhocko@...e.com>,
David Hildenbrand <david@...hat.com>,
Matthew Wilcox <willy@...radead.org>,
Naoya Horiguchi <naoya.horiguchi@...ux.dev>,
Mina Almasry <almasrymina@...gle.com>,
Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH v2 1/3] hugetlb: simplify prep_compound_gigantic_page ref
count racing code
On 2021-08-09 20:48, Mike Kravetz wrote:
> Code in prep_compound_gigantic_page waits for a rcu grace period if it
> notices a temporarily inflated ref count on a tail page. This was due
> to the identified potential race with speculative page cache references
> which could only last for a rcu grace period. This is overly
> complicated
> as this situation is VERY unlikely to ever happen. Instead, just
> quickly
> return an error.
> Also, only print a warning in prep_compound_gigantic_page instead of
> multiple callers.
The above makes sense to me.
My only question would be: gather_bootmem_prealloc() is an __init
function.
Can we have speculative refcounts due to e.g: pagecache at that early
stage?
I think we cannot, but I am not really sure.
We might be able to remove that else() in case we cannot have such
scenarios.
--
Oscar Salvador
SUSE L3
Powered by blists - more mailing lists