linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mel Gorman <mgorman@techsingularity.net>
To: Alexander Duyck <alexander.h.duyck@linux.intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Alexander Duyck <alexander.duyck@gmail.com>,
	kvm@vger.kernel.org, david@redhat.com, mst@redhat.com,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	yang.zhang.wz@gmail.com, pagupta@redhat.com,
	konrad.wilk@oracle.com, nitesh@redhat.com, riel@surriel.com,
	willy@infradead.org, lcapitulino@redhat.com,
	dave.hansen@intel.com, wei.w.wang@intel.com, aarcange@redhat.com,
	pbonzini@redhat.com, dan.j.williams@intel.com, mhocko@kernel.org,
	vbabka@suse.cz, osalvador@suse.de
Subject: Re: [PATCH v17 0/9] mm / virtio: Provide support for free page reporting
Date: Wed, 19 Feb 2020 15:06:52 +0000	[thread overview]
Message-ID: <20200219150652.GV3466@techsingularity.net> (raw)
In-Reply-To: <31383bb111737c9f8ffbb1e6e4446cb4fd620a53.camel@linux.intel.com>

On Tue, Feb 18, 2020 at 08:37:46AM -0800, Alexander Duyck wrote:
> On Tue, 2020-02-11 at 16:19 -0800, Andrew Morton wrote:
> > On Tue, 11 Feb 2020 15:55:31 -0800 Alexander Duyck <alexander.h.duyck@linux.intel.com> wrote:
> > 
> > > On the host I just have to monitor /proc/meminfo and I can see the
> > > difference. I get the following results on the host, in the enabled case
> > > it takes about 30 seconds for it to settle into the final state since I
> > > only report page a bit at a time:
> > > Baseline/Applied
> > >   MemTotal:    131963012 kB
> > >   MemFree:      95189740 kB
> > > 
> > > Enabled:
> > >   MemTotal:    131963012 kB
> > >   MemFree:     126459472 kB
> > > 
> > > This is what I was referring to with the comment above. I had a test I was
> > > running back around the first RFC that consisted of bringing up enough VMs
> > > so that there was a bit of memory overcommit and then having the VMs in
> > > turn run memhog. As I recall the difference between the two was  something
> > > like a couple minutes to run through all the VMs as the memhog would take
> > > up to 40+ seconds for one that was having to pull from swap while it took
> > > only 5 to 7 seconds for the VMs that were all running the page hinting.
> > > 
> > > I had referenced it here in the RFC:
> > > https://lore.kernel.org/lkml/20190204181118.12095.38300.stgit@localhost.localdomain/
> > > 
> > > I have been verifying the memory has been getting freed but didn't feel
> > > like the test added much value so I haven't added it to the cover page for
> > > a while since the time could vary widely and is dependent on things like
> > > the disk type used for the host swap since my SSD is likely faster than
> > > spinning rust, but may not be as fast as other SSDs on the market. Since
> > > the disk speed can play such a huge role I wasn't comfortable posting
> > > numbers since the benefits could vary so widely.
> > 
> > OK, thanks.  I'll add the patches to the mm pile.  The new
> > mm/page_reporting.c is unreviewed afaict, so I guess you own that for
> > now ;)
> > 
> > It would be very nice to get some feedback from testers asserting "yes,
> > this really helped my workload" but I understand this sort of testing
> > is hard to obtain at this stage.
> > 
> 
> Mel,
> 
> Any ETA on when you would be available to review these patches? They are
> now in Andrew's tree and in linux-next. I am hoping to get any remaining
> review from the community sorted out in the next few weeks so I can move
> onto focusing on how best to exert pressure on the page cache so that we
> can keep the guest memory footprint small.
> 

Sorry for the delay but I got through most of the patches -- I ignored
the qemu ones. Overall I think it's fine, while I made a suggestion on
how one section can be a bit more defensive, I don't consider it
mandatory to update the series.

Last time I got upset by the use of zone lock, premature optimisation and
some potential page allocator overhead. Now how you use the zone lock is
justified and I think the state managed by atomics is ok. The optimisations
are split out and so if there is a bug lurking in there, they can be
backed out relatively easily and it was easier to review the series in
this way. Finally, the overhead to the page allocator when the feature
is disabled should be non-existent as it's protected by a static branch
so I have no further objections.

Thanks!

-- 
Mel Gorman
SUSE Labs

      parent reply	other threads:[~2020-02-19 15:06 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-11 22:45 Alexander Duyck
2020-02-11 22:46 ` [PATCH v17 1/9] mm: Adjust shuffle code to allow for future coalescing Alexander Duyck
2020-02-11 22:46 ` [PATCH v17 2/9] mm: Use zone and order instead of free area in free_list manipulators Alexander Duyck
2020-02-11 22:46 ` [PATCH v17 3/9] mm: Add function __putback_isolated_page Alexander Duyck
2020-02-19 14:33   ` Mel Gorman
2020-02-11 22:46 ` [PATCH v17 4/9] mm: Introduce Reported pages Alexander Duyck
2020-02-19 14:55   ` Mel Gorman
2020-02-20 18:44     ` Alexander Duyck
2020-02-20 22:35       ` Mel Gorman
2020-02-21 19:25         ` Alexander Duyck
2020-02-21 20:19           ` Mel Gorman
2020-02-11 22:46 ` [PATCH v17 5/9] virtio-balloon: Pull page poisoning config out of free page hinting Alexander Duyck
2020-02-11 22:46 ` [PATCH v17 6/9] virtio-balloon: Add support for providing free page reports to host Alexander Duyck
2020-02-11 22:47 ` [PATCH v17 7/9] mm/page_reporting: Rotate reported pages to the tail of the list Alexander Duyck
2020-02-19 14:59   ` Mel Gorman
2020-02-11 22:47 ` [PATCH v17 8/9] mm/page_reporting: Add budget limit on how many pages can be reported per pass Alexander Duyck
2020-02-19 15:02   ` Mel Gorman
2020-02-11 22:47 ` [PATCH v17 9/9] mm/page_reporting: Add free page reporting documentation Alexander Duyck
2020-02-11 22:51 ` [PATCH v17 QEMU 1/3] virtio-ballon: Implement support for page poison tracking feature Alexander Duyck
2020-02-11 22:51 ` [PATCH v17 QEMU 2/3] virtio-balloon: Add support for providing free page reports to host Alexander Duyck
2020-02-11 22:51 ` [PATCH v17 QEMU 3/3] virtio-balloon: Provide a interface for free page reporting Alexander Duyck
2020-02-11 22:53 ` [PATCH v17 QEMU 4/3 RFC] memory: Add support for MADV_FREE as mechanism to lazy discard pages Alexander Duyck
2020-02-11 23:05 ` [PATCH v17 0/9] mm / virtio: Provide support for free page reporting Andrew Morton
2020-02-11 23:55   ` Alexander Duyck
2020-02-12  0:19     ` Andrew Morton
2020-02-12  1:19       ` Alexander Duyck
2020-02-18 16:37       ` Alexander Duyck
2020-02-19  8:49         ` Mel Gorman
2020-02-19 15:06         ` Mel Gorman [this message]

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=20200219150652.GV3466@techsingularity.net \
    --to=mgorman@techsingularity.net \
    --cc=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=alexander.duyck@gmail.com \
    --cc=alexander.h.duyck@linux.intel.com \
    --cc=dan.j.williams@intel.com \
    --cc=dave.hansen@intel.com \
    --cc=david@redhat.com \
    --cc=konrad.wilk@oracle.com \
    --cc=kvm@vger.kernel.org \
    --cc=lcapitulino@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@kernel.org \
    --cc=mst@redhat.com \
    --cc=nitesh@redhat.com \
    --cc=osalvador@suse.de \
    --cc=pagupta@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=riel@surriel.com \
    --cc=vbabka@suse.cz \
    --cc=wei.w.wang@intel.com \
    --cc=willy@infradead.org \
    --cc=yang.zhang.wz@gmail.com \
    --subject='Re: [PATCH v17 0/9] mm / virtio: Provide support for free page reporting' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).