[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210106160827.GO13207@dhcp22.suse.cz>
Date: Wed, 6 Jan 2021 17:08:27 +0100
From: Michal Hocko <mhocko@...e.com>
To: Liang Li <liliang324@...il.com>
Cc: Alexander Duyck <alexander.h.duyck@...ux.intel.com>,
Mel Gorman <mgorman@...hsingularity.net>,
Andrew Morton <akpm@...ux-foundation.org>,
Andrea Arcangeli <aarcange@...hat.com>,
Dan Williams <dan.j.williams@...el.com>,
"Michael S. Tsirkin" <mst@...hat.com>,
David Hildenbrand <david@...hat.com>,
Jason Wang <jasowang@...hat.com>,
Dave Hansen <dave.hansen@...el.com>,
Liang Li <liliangleo@...iglobal.com>,
Mike Kravetz <mike.kravetz@...cle.com>, linux-mm@...ck.org,
linux-kernel@...r.kernel.org,
virtualization@...ts.linux-foundation.org
Subject: Re: [PATCH 3/6] hugetlb: add free page reporting support
On Tue 05-01-21 22:49:21, Liang Li wrote:
> hugetlb manages its page in hstate's free page list, not in buddy
> system, this patch try to make it works for hugetlbfs. It canbe
> used for memory overcommit in virtualization and hugetlb pre zero
> out.
David has layed down some more fundamental questions in the reply to the
cover letter (btw. can you fix your scripts to send patches and make all
the patches to be in reply to the cover letter please?). But I would
like to point out that this changelog would need to change a lot as
well. It doesn't explain really what, why and how. E.g. what would any
guest gain by being able to report free huge pages? What would guarantee
that the pool is replenished when there is a demand? Can this make the
fault fail or it just takes more time to be satisfied? Why did you
decide that the reporting infrastructure should be abused to do the
zeroying? I do remember Alexander pushing back against that and so you
should better have a very strong arguments to proceed that way.
I am pretty sure there are more questions to come when more details are
uncovered.
--
Michal Hocko
SUSE Labs
Powered by blists - more mailing lists