linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@suse.com>
To: Liang Li <liliang324@gmail.com>
Cc: Alexander Duyck <alexander.h.duyck@linux.intel.com>,
	Mel Gorman <mgorman@techsingularity.net>,
	Andrew Morton <akpm@linux-foundation.org>,
	Andrea Arcangeli <aarcange@redhat.com>,
	Dan Williams <dan.j.williams@intel.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	David Hildenbrand <david@redhat.com>,
	Jason Wang <jasowang@redhat.com>,
	Dave Hansen <dave.hansen@intel.com>,
	Liang Li <liliangleo@didiglobal.com>,
	Mike Kravetz <mike.kravetz@oracle.com>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	virtualization@lists.linux-foundation.org
Subject: Re: [PATCH 3/6] hugetlb: add free page reporting support
Date: Wed, 6 Jan 2021 17:08:27 +0100	[thread overview]
Message-ID: <20210106160827.GO13207@dhcp22.suse.cz> (raw)
In-Reply-To: <20210106034918.GA1154@open-light-1.localdomain>

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


  reply	other threads:[~2021-01-06 16:08 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-06  3:49 Liang Li
2021-01-06 16:08 ` Michal Hocko [this message]
2021-01-07  3:38   ` Liang Li
2021-01-07  8:53     ` David Hildenbrand
2021-01-11  4:00       ` Liang Li
2021-01-07 22:04 ` Mike Kravetz
2021-01-11  4:09   ` Liang Li

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 \
    --in-reply-to=20210106160827.GO13207@dhcp22.suse.cz \
    --to=mhocko@suse.com \
    --cc=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=alexander.h.duyck@linux.intel.com \
    --cc=dan.j.williams@intel.com \
    --cc=dave.hansen@intel.com \
    --cc=david@redhat.com \
    --cc=jasowang@redhat.com \
    --cc=liliang324@gmail.com \
    --cc=liliangleo@didiglobal.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@techsingularity.net \
    --cc=mike.kravetz@oracle.com \
    --cc=mst@redhat.com \
    --cc=virtualization@lists.linux-foundation.org \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox