lkml.org 
[lkml]   [2019]   [Jun]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH v1 0/6] mm / virtio: Provide support for paravirtual waste page treatment
    On Tue, Jun 25, 2019 at 12:42 AM David Hildenbrand <david@redhat.com> wrote:
    >
    > On 20.06.19 00:32, Alexander Duyck wrote:
    > > This series provides an asynchronous means of hinting to a hypervisor
    > > that a guest page is no longer in use and can have the data associated
    > > with it dropped. To do this I have implemented functionality that allows
    > > for what I am referring to as waste page treatment.
    > >
    > > I have based many of the terms and functionality off of waste water
    > > treatment, the idea for the similarity occurred to me after I had reached
    > > the point of referring to the hints as "bubbles", as the hints used the
    > > same approach as the balloon functionality but would disappear if they
    > > were touched, as a result I started to think of the virtio device as an
    > > aerator. The general idea with all of this is that the guest should be
    > > treating the unused pages so that when they end up heading "downstream"
    > > to either another guest, or back at the host they will not need to be
    > > written to swap.
    > >
    > > When the number of "dirty" pages in a given free_area exceeds our high
    > > water mark, which is currently 32, we will schedule the aeration task to
    > > start going through and scrubbing the zone. While the scrubbing is taking
    > > place a boundary will be defined that we use to seperate the "aerated"
    > > pages from the "dirty" ones. We use the ZONE_AERATION_ACTIVE bit to flag
    > > when these boundaries are in place.
    >
    > I still *detest* the terminology, sorry. Can't you come up with a
    > simpler terminology that makes more sense in the context of operating
    > systems and pages we want to hint to the hypervisor? (that is the only
    > use case you are using it for so far)

    I'm open to suggestions. The terminology is just what I went with as I
    had gone from balloon to thinking of this as a bubble since it was a
    balloon without the deflate logic. From there I got to aeration since
    it is filling the buddy allocator with those bubbles.

    > >
    > > I am leaving a number of things hard-coded such as limiting the lowest
    > > order processed to PAGEBLOCK_ORDER, and have left it up to the guest to
    > > determine what batch size it wants to allocate to process the hints.
    > >
    > > My primary testing has just been to verify the memory is being freed after
    > > allocation by running memhog 32g in the guest and watching the total free
    > > memory via /proc/meminfo on the host. With this I have verified most of
    > > the memory is freed after each iteration. As far as performance I have
    > > been mainly focusing on the will-it-scale/page_fault1 test running with
    > > 16 vcpus. With that I have seen a less than 1% difference between the
    >
    > 1% throughout all benchmarks? Guess that is quite good.

    That is the general idea. What I wanted to avoid was this introducing
    any significant slowdown, especially in the case where we weren't
    using it.

    > > base kernel without these patches, with the patches and virtio-balloon
    > > disabled, and with the patches and virtio-balloon enabled with hinting.
    > >
    > > Changes from the RFC:
    > > Moved aeration requested flag out of aerator and into zone->flags.
    > > Moved boundary out of free_area and into local variables for aeration.
    > > Moved aeration cycle out of interrupt and into workqueue.
    > > Left nr_free as total pages instead of splitting it between raw and aerated.
    > > Combined size and physical address values in virtio ring into one 64b value.
    > > Restructured the patch set to reduce patches from 11 to 6.
    > >
    >
    > I'm planning to look into the details, but will be on PTO for two weeks
    > starting this Saturday (and still have other things to finish first :/ ).

    Thanks. No rush. I will be on PTO for the next couple of weeks myself.

    > > ---
    > >
    > > Alexander Duyck (6):
    > > mm: Adjust shuffle code to allow for future coalescing
    > > mm: Move set/get_pcppage_migratetype to mmzone.h
    > > mm: Use zone and order instead of free area in free_list manipulators
    > > mm: Introduce "aerated" pages
    > > mm: Add logic for separating "aerated" pages from "raw" pages
    > > virtio-balloon: Add support for aerating memory via hinting
    > >
    > >
    > > drivers/virtio/Kconfig | 1
    > > drivers/virtio/virtio_balloon.c | 110 ++++++++++++++
    > > include/linux/memory_aeration.h | 118 +++++++++++++++
    > > include/linux/mmzone.h | 113 +++++++++------
    > > include/linux/page-flags.h | 8 +
    > > include/uapi/linux/virtio_balloon.h | 1
    > > mm/Kconfig | 5 +
    > > mm/Makefile | 1
    > > mm/aeration.c | 270 +++++++++++++++++++++++++++++++++++
    > > mm/page_alloc.c | 203 ++++++++++++++++++--------
    > > mm/shuffle.c | 24 ---
    > > mm/shuffle.h | 35 +++++
    > > 12 files changed, 753 insertions(+), 136 deletions(-)
    > > create mode 100644 include/linux/memory_aeration.h
    > > create mode 100644 mm/aeration.c
    >
    > Compared to
    >
    > 17 files changed, 838 insertions(+), 86 deletions(-)
    > create mode 100644 include/linux/memory_aeration.h
    > create mode 100644 mm/aeration.c
    >
    > this looks like a good improvement :)

    Thanks.

    - Alex

    \
     
     \ /
      Last update: 2019-06-25 18:10    [W:4.104 / U:0.060 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site