[PATCH v2 0/5] mm / virtio: Provide support for page hinting

[PATCH v2 0/5] mm / virtio: Provide support for page hinting

[Alexander Duyck]

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 page hinting

The functionality for this is fairly simple. When enabled it will allocate
statistics to track the number of hinted pages in a given free area. When
the number of free pages exceeds this value plus a high water value,
currently 32, it will begin performing page hinting which consists of
pulling pages off of free list and placing them into a scatter list. The
scatterlist is then given to the page hinting device and it will perform
the required action to make the pages "hinted", in the case of
virtio-balloon this results in the pages being madvised as MADV_DONTNEED
and as such they are forced out of the guest. After this they are placed
back on the free list, and an additional bit is added if they are not
merged indicating that they are a hinted buddy page instead of a standard
buddy page. The cycle then repeats with additional non-hinted pages being
pulled until the free areas all consist of hinted pages.

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 the limit is on how many pages 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 79g on a 80g 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 at most a 2% difference between the base
kernel without these patches and the patches with virtio-balloon disabled.
With the patches and virtio-balloon enabled with hinting the results
largely depend on the host kernel. On a 3.10 RHEL kernel I saw up to a 2%
drop in performance as I approached 16 threads, however on the the lastest
linux-next kernel I saw roughly a 4% to 5% improvement in performance for
all tests with 8 or more threads. I believe the difference seen is due to
the overhead for faulting pages back into the guest and zeroing of memory.

Patch 4 is a bit on the large side at about 600 lines of change, however
I really didn't see a good way to break it up since each piece feeds into
the next. So I couldn't add the statistics by themselves as it didn't
really make sense to add them without something that will either read or
increment/decrement them, or add the Hinted state without something that
would set/unset it. As such I just ended up adding the entire thing as
one patch. It makes it a bit bigger but avoids the issues in the previous
set where I was referencing things before they had been added.

Changes from the RFC:
https://lore.kernel.org/lkml/20190530215223.13974.22445.stgit@localhost.localdomain/
Moved aeration requested flag out of aerator and into zone->flags.
Moved bounary 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.

Changes from v1:
https://lore.kernel.org/lkml/20190619222922.1231.27432.stgit@localhost.localdomain/
Dropped "waste page treatment" in favor of "page hinting"
Renamed files and functions from "aeration" to "page_hinting"
Moved from page->lru list to scatterlist
Replaced wait on refcnt in shutdown with RCU and cancel_delayed_work_sync
Virtio now uses scatterlist directly instead of intermedate array
Moved stats out of free_area, now in seperate area and pointed to from zone
Merged patch 5 into patch 4 to improve reviewability
Updated various code comments throughout

---

Alexander Duyck (5):
      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 Hinted pages
      virtio-balloon: Add support for providing page hints to host


 drivers/virtio/Kconfig              |    1 
 drivers/virtio/virtio_balloon.c     |   47 ++++++
 include/linux/mmzone.h              |  116 ++++++++------
 include/linux/page-flags.h          |    8 +
 include/linux/page_hinting.h        |  139 ++++++++++++++++
 include/uapi/linux/virtio_balloon.h |    1 
 mm/Kconfig                          |    5 +
 mm/Makefile                         |    1 
 mm/internal.h                       |   18 ++
 mm/memory_hotplug.c                 |    1 
 mm/page_alloc.c                     |  238 ++++++++++++++++++++--------
 mm/page_hinting.c                   |  298 +++++++++++++++++++++++++++++++++++
 mm/shuffle.c                        |   24 ---
 mm/shuffle.h                        |   32 ++++
 14 files changed, 796 insertions(+), 133 deletions(-)
 create mode 100644 include/linux/page_hinting.h
 create mode 100644 mm/page_hinting.c

--

[PATCH v2 1/5] mm: Adjust shuffle code to allow for future coalescing

[Alexander Duyck]

From: Alexander Duyck <alexander.h.duyck@linux.intel.com>

This patch is meant to move the head/tail adding logic out of the shuffle
code and into the __free_one_page function since ultimately that is where
it is really needed anyway. By doing this we should be able to reduce the
overhead and can consolidate all of the list addition bits in one spot.

Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
---
 include/linux/mmzone.h |   12 --------
 mm/page_alloc.c        |   70 +++++++++++++++++++++++++++---------------------
 mm/shuffle.c           |   24 ----------------
 mm/shuffle.h           |   32 ++++++++++++++++++++++
 4 files changed, 71 insertions(+), 67 deletions(-)

diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index d77d717c620c..738e9c758135 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -116,18 +116,6 @@ static inline void add_to_free_area_tail(struct page *page, struct free_area *ar
 	area->nr_free++;
 }
 
-#ifdef CONFIG_SHUFFLE_PAGE_ALLOCATOR
-/* Used to preserve page allocation order entropy */
-void add_to_free_area_random(struct page *page, struct free_area *area,
-		int migratetype);
-#else
-static inline void add_to_free_area_random(struct page *page,
-		struct free_area *area, int migratetype)
-{
-	add_to_free_area(page, area, migratetype);
-}
-#endif
-
 /* Used for pages which are on another list */
 static inline void move_to_free_area(struct page *page, struct free_area *area,
 			     int migratetype)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 272c6de1bf4e..1c4644b6cdc3 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -877,6 +877,36 @@ static inline struct capture_control *task_capc(struct zone *zone)
 #endif /* CONFIG_COMPACTION */
 
 /*
+ * If this is not the largest possible page, check if the buddy
+ * of the next-highest order is free. If it is, it's possible
+ * that pages are being freed that will coalesce soon. In case,
+ * that is happening, add the free page to the tail of the list
+ * so it's less likely to be used soon and more likely to be merged
+ * as a higher order page
+ */
+static inline bool
+buddy_merge_likely(unsigned long pfn, unsigned long buddy_pfn,
+		   struct page *page, unsigned int order)
+{
+	struct page *higher_page, *higher_buddy;
+	unsigned long combined_pfn;
+
+	if (order >= MAX_ORDER - 2)
+		return false;
+
+	if (!pfn_valid_within(buddy_pfn))
+		return false;
+
+	combined_pfn = buddy_pfn & pfn;
+	higher_page = page + (combined_pfn - pfn);
+	buddy_pfn = __find_buddy_pfn(combined_pfn, order + 1);
+	higher_buddy = higher_page + (buddy_pfn - combined_pfn);
+
+	return pfn_valid_within(buddy_pfn) &&
+	       page_is_buddy(higher_page, higher_buddy, order + 1);
+}
+
+/*
  * Freeing function for a buddy system allocator.
  *
  * The concept of a buddy system is to maintain direct-mapped table
@@ -905,11 +935,12 @@ static inline void __free_one_page(struct page *page,
 		struct zone *zone, unsigned int order,
 		int migratetype)
 {
-	unsigned long combined_pfn;
+	struct capture_control *capc = task_capc(zone);
 	unsigned long uninitialized_var(buddy_pfn);
-	struct page *buddy;
+	unsigned long combined_pfn;
+	struct free_area *area;
 	unsigned int max_order;
-	struct capture_control *capc = task_capc(zone);
+	struct page *buddy;
 
 	max_order = min_t(unsigned int, MAX_ORDER, pageblock_order + 1);
 
@@ -978,35 +1009,12 @@ static inline void __free_one_page(struct page *page,
 done_merging:
 	set_page_order(page, order);
 
-	/*
-	 * If this is not the largest possible page, check if the buddy
-	 * of the next-highest order is free. If it is, it's possible
-	 * that pages are being freed that will coalesce soon. In case,
-	 * that is happening, add the free page to the tail of the list
-	 * so it's less likely to be used soon and more likely to be merged
-	 * as a higher order page
-	 */
-	if ((order < MAX_ORDER-2) && pfn_valid_within(buddy_pfn)
-			&& !is_shuffle_order(order)) {
-		struct page *higher_page, *higher_buddy;
-		combined_pfn = buddy_pfn & pfn;
-		higher_page = page + (combined_pfn - pfn);
-		buddy_pfn = __find_buddy_pfn(combined_pfn, order + 1);
-		higher_buddy = higher_page + (buddy_pfn - combined_pfn);
-		if (pfn_valid_within(buddy_pfn) &&
-		    page_is_buddy(higher_page, higher_buddy, order + 1)) {
-			add_to_free_area_tail(page, &zone->free_area[order],
-					      migratetype);
-			return;
-		}
-	}
-
-	if (is_shuffle_order(order))
-		add_to_free_area_random(page, &zone->free_area[order],
-				migratetype);
+	area = &zone->free_area[order];
+	if (is_shuffle_order(order) ? shuffle_add_to_tail() :
+	    buddy_merge_likely(pfn, buddy_pfn, page, order))
+		add_to_free_area_tail(page, area, migratetype);
 	else
-		add_to_free_area(page, &zone->free_area[order], migratetype);
-
+		add_to_free_area(page, area, migratetype);
 }
 
 /*
diff --git a/mm/shuffle.c b/mm/shuffle.c
index 3ce12481b1dc..55d592e62526 100644
--- a/mm/shuffle.c
+++ b/mm/shuffle.c
@@ -4,7 +4,6 @@
 #include <linux/mm.h>
 #include <linux/init.h>
 #include <linux/mmzone.h>
-#include <linux/random.h>
 #include <linux/moduleparam.h>
 #include "internal.h"
 #include "shuffle.h"
@@ -182,26 +181,3 @@ void __meminit __shuffle_free_memory(pg_data_t *pgdat)
 	for (z = pgdat->node_zones; z < pgdat->node_zones + MAX_NR_ZONES; z++)
 		shuffle_zone(z);
 }
-
-void add_to_free_area_random(struct page *page, struct free_area *area,
-		int migratetype)
-{
-	static u64 rand;
-	static u8 rand_bits;
-
-	/*
-	 * The lack of locking is deliberate. If 2 threads race to
-	 * update the rand state it just adds to the entropy.
-	 */
-	if (rand_bits == 0) {
-		rand_bits = 64;
-		rand = get_random_u64();
-	}
-
-	if (rand & 1)
-		add_to_free_area(page, area, migratetype);
-	else
-		add_to_free_area_tail(page, area, migratetype);
-	rand_bits--;
-	rand >>= 1;
-}
diff --git a/mm/shuffle.h b/mm/shuffle.h
index 777a257a0d2f..add763cc0995 100644
--- a/mm/shuffle.h
+++ b/mm/shuffle.h
@@ -3,6 +3,7 @@
 #ifndef _MM_SHUFFLE_H
 #define _MM_SHUFFLE_H
 #include <linux/jump_label.h>
+#include <linux/random.h>
 
 /*
  * SHUFFLE_ENABLE is called from the command line enabling path, or by
@@ -43,6 +44,32 @@ static inline bool is_shuffle_order(int order)
 		return false;
 	return order >= SHUFFLE_ORDER;
 }
+
+static inline bool shuffle_add_to_tail(void)
+{
+	static u64 rand;
+	static u8 rand_bits;
+	u64 rand_old;
+
+	/*
+	 * The lack of locking is deliberate. If 2 threads race to
+	 * update the rand state it just adds to the entropy.
+	 */
+	if (rand_bits-- == 0) {
+		rand_bits = 64;
+		rand = get_random_u64();
+	}
+
+	/*
+	 * Test highest order bit while shifting our random value. This
+	 * should result in us testing for the carry flag following the
+	 * shift.
+	 */
+	rand_old = rand;
+	rand <<= 1;
+
+	return rand < rand_old;
+}
 #else
 static inline void shuffle_free_memory(pg_data_t *pgdat)
 {
@@ -60,5 +87,10 @@ static inline bool is_shuffle_order(int order)
 {
 	return false;
 }
+
+static inline bool shuffle_add_to_tail(void)
+{
+	return false;
+}
 #endif
 #endif /* _MM_SHUFFLE_H */

[PATCH v2 2/5] mm: Move set/get_pcppage_migratetype to mmzone.h

[Alexander Duyck]

From: Alexander Duyck <alexander.h.duyck@linux.intel.com>

In order to support page aeration it will be necessary to store and
retrieve the migratetype of a page. To enable that I am moving the set and
get operations for pcppage_migratetype into the mm/internal.h header so
that they can be used outside of the page_alloc.c file.

Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
---
 mm/internal.h   |   18 ++++++++++++++++++
 mm/page_alloc.c |   18 ------------------
 2 files changed, 18 insertions(+), 18 deletions(-)

diff --git a/mm/internal.h b/mm/internal.h
index e32390802fd3..e432c7d5940d 100644
--- a/mm/internal.h
+++ b/mm/internal.h
@@ -549,6 +549,24 @@ static inline bool is_migrate_highatomic_page(struct page *page)
 	return get_pageblock_migratetype(page) == MIGRATE_HIGHATOMIC;
 }
 
+/*
+ * A cached value of the page's pageblock's migratetype, used when the page is
+ * put on a pcplist. Used to avoid the pageblock migratetype lookup when
+ * freeing from pcplists in most cases, at the cost of possibly becoming stale.
+ * Also the migratetype set in the page does not necessarily match the pcplist
+ * index, e.g. page might have MIGRATE_CMA set but be on a pcplist with any
+ * other index - this ensures that it will be put on the correct CMA freelist.
+ */
+static inline int get_pcppage_migratetype(struct page *page)
+{
+	return page->index;
+}
+
+static inline void set_pcppage_migratetype(struct page *page, int migratetype)
+{
+	page->index = migratetype;
+}
+
 void setup_zone_pageset(struct zone *zone);
 extern struct page *alloc_new_node_page(struct page *page, unsigned long node);
 #endif	/* __MM_INTERNAL_H */
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 1c4644b6cdc3..3d612a6b1771 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -185,24 +185,6 @@ static int __init early_init_on_free(char *buf)
 }
 early_param("init_on_free", early_init_on_free);
 
-/*
- * A cached value of the page's pageblock's migratetype, used when the page is
- * put on a pcplist. Used to avoid the pageblock migratetype lookup when
- * freeing from pcplists in most cases, at the cost of possibly becoming stale.
- * Also the migratetype set in the page does not necessarily match the pcplist
- * index, e.g. page might have MIGRATE_CMA set but be on a pcplist with any
- * other index - this ensures that it will be put on the correct CMA freelist.
- */
-static inline int get_pcppage_migratetype(struct page *page)
-{
-	return page->index;
-}
-
-static inline void set_pcppage_migratetype(struct page *page, int migratetype)
-{
-	page->index = migratetype;
-}
-
 #ifdef CONFIG_PM_SLEEP
 /*
  * The following functions are used by the suspend/hibernate code to temporarily

[PATCH v2 3/5] mm: Use zone and order instead of free area in free_list manipulators

[Alexander Duyck]

From: Alexander Duyck <alexander.h.duyck@linux.intel.com>

In order to enable the use of the zone from the list manipulator functions
I will need access to the zone pointer. As it turns out most of the
accessors were always just being directly passed &zone->free_area[order]
anyway so it would make sense to just fold that into the function itself
and pass the zone and order as arguments instead of the free area.

In order to be able to reference the zone we need to move the declaration
of the functions down so that we have the zone defined before we define the
list manipulation functions.

Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
---
 include/linux/mmzone.h |   70 ++++++++++++++++++++++++++----------------------
 mm/page_alloc.c        |   30 ++++++++-------------
 2 files changed, 49 insertions(+), 51 deletions(-)

diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index 738e9c758135..f0c68b6b6154 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -100,29 +100,6 @@ struct free_area {
 	unsigned long		nr_free;
 };
 
-/* Used for pages not on another list */
-static inline void add_to_free_area(struct page *page, struct free_area *area,
-			     int migratetype)
-{
-	list_add(&page->lru, &area->free_list[migratetype]);
-	area->nr_free++;
-}
-
-/* Used for pages not on another list */
-static inline void add_to_free_area_tail(struct page *page, struct free_area *area,
-				  int migratetype)
-{
-	list_add_tail(&page->lru, &area->free_list[migratetype]);
-	area->nr_free++;
-}
-
-/* Used for pages which are on another list */
-static inline void move_to_free_area(struct page *page, struct free_area *area,
-			     int migratetype)
-{
-	list_move(&page->lru, &area->free_list[migratetype]);
-}
-
 static inline struct page *get_page_from_free_area(struct free_area *area,
 					    int migratetype)
 {
@@ -130,15 +107,6 @@ static inline struct page *get_page_from_free_area(struct free_area *area,
 					struct page, lru);
 }
 
-static inline void del_page_from_free_area(struct page *page,
-		struct free_area *area)
-{
-	list_del(&page->lru);
-	__ClearPageBuddy(page);
-	set_page_private(page, 0);
-	area->nr_free--;
-}
-
 static inline bool free_area_empty(struct free_area *area, int migratetype)
 {
 	return list_empty(&area->free_list[migratetype]);
@@ -787,6 +755,44 @@ static inline bool pgdat_is_empty(pg_data_t *pgdat)
 	return !pgdat->node_start_pfn && !pgdat->node_spanned_pages;
 }
 
+/* Used for pages not on another list */
+static inline void add_to_free_list(struct page *page, struct zone *zone,
+				    unsigned int order, int migratetype)
+{
+	struct free_area *area = &zone->free_area[order];
+
+	list_add(&page->lru, &area->free_list[migratetype]);
+	area->nr_free++;
+}
+
+/* Used for pages not on another list */
+static inline void add_to_free_list_tail(struct page *page, struct zone *zone,
+					 unsigned int order, int migratetype)
+{
+	struct free_area *area = &zone->free_area[order];
+
+	list_add_tail(&page->lru, &area->free_list[migratetype]);
+	area->nr_free++;
+}
+
+/* Used for pages which are on another list */
+static inline void move_to_free_list(struct page *page, struct zone *zone,
+				     unsigned int order, int migratetype)
+{
+	struct free_area *area = &zone->free_area[order];
+
+	list_move(&page->lru, &area->free_list[migratetype]);
+}
+
+static inline void del_page_from_free_list(struct page *page, struct zone *zone,
+					   unsigned int order)
+{
+	list_del(&page->lru);
+	__ClearPageBuddy(page);
+	set_page_private(page, 0);
+	zone->free_area[order].nr_free--;
+}
+
 #include <linux/memory_hotplug.h>
 
 void build_all_zonelists(pg_data_t *pgdat);
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 3d612a6b1771..9a73f69b37af 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -920,7 +920,6 @@ static inline void __free_one_page(struct page *page,
 	struct capture_control *capc = task_capc(zone);
 	unsigned long uninitialized_var(buddy_pfn);
 	unsigned long combined_pfn;
-	struct free_area *area;
 	unsigned int max_order;
 	struct page *buddy;
 
@@ -957,7 +956,7 @@ static inline void __free_one_page(struct page *page,
 		if (page_is_guard(buddy))
 			clear_page_guard(zone, buddy, order, migratetype);
 		else
-			del_page_from_free_area(buddy, &zone->free_area[order]);
+			del_page_from_free_list(buddy, zone, order);
 		combined_pfn = buddy_pfn & pfn;
 		page = page + (combined_pfn - pfn);
 		pfn = combined_pfn;
@@ -991,12 +990,11 @@ static inline void __free_one_page(struct page *page,
 done_merging:
 	set_page_order(page, order);
 
-	area = &zone->free_area[order];
 	if (is_shuffle_order(order) ? shuffle_add_to_tail() :
 	    buddy_merge_likely(pfn, buddy_pfn, page, order))
-		add_to_free_area_tail(page, area, migratetype);
+		add_to_free_list_tail(page, zone, order, migratetype);
 	else
-		add_to_free_area(page, area, migratetype);
+		add_to_free_list(page, zone, order, migratetype);
 }
 
 /*
@@ -2000,13 +1998,11 @@ void __init init_cma_reserved_pageblock(struct page *page)
  * -- nyc
  */
 static inline void expand(struct zone *zone, struct page *page,
-	int low, int high, struct free_area *area,
-	int migratetype)
+	int low, int high, int migratetype)
 {
 	unsigned long size = 1 << high;
 
 	while (high > low) {
-		area--;
 		high--;
 		size >>= 1;
 		VM_BUG_ON_PAGE(bad_range(zone, &page[size]), &page[size]);
@@ -2020,7 +2016,7 @@ static inline void expand(struct zone *zone, struct page *page,
 		if (set_page_guard(zone, &page[size], high, migratetype))
 			continue;
 
-		add_to_free_area(&page[size], area, migratetype);
+		add_to_free_list(&page[size], zone, high, migratetype);
 		set_page_order(&page[size], high);
 	}
 }
@@ -2178,8 +2174,8 @@ struct page *__rmqueue_smallest(struct zone *zone, unsigned int order,
 		page = get_page_from_free_area(area, migratetype);
 		if (!page)
 			continue;
-		del_page_from_free_area(page, area);
-		expand(zone, page, order, current_order, area, migratetype);
+		del_page_from_free_list(page, zone, current_order);
+		expand(zone, page, order, current_order, migratetype);
 		set_pcppage_migratetype(page, migratetype);
 		return page;
 	}
@@ -2187,7 +2183,6 @@ struct page *__rmqueue_smallest(struct zone *zone, unsigned int order,
 	return NULL;
 }
 
-
 /*
  * This array describes the order lists are fallen back to when
  * the free lists for the desirable migrate type are depleted
@@ -2264,7 +2259,7 @@ static int move_freepages(struct zone *zone,
 		}
 
 		order = page_order(page);
-		move_to_free_area(page, &zone->free_area[order], migratetype);
+		move_to_free_list(page, zone, order, migratetype);
 		page += 1 << order;
 		pages_moved += 1 << order;
 	}
@@ -2380,7 +2375,6 @@ static void steal_suitable_fallback(struct zone *zone, struct page *page,
 		unsigned int alloc_flags, int start_type, bool whole_block)
 {
 	unsigned int current_order = page_order(page);
-	struct free_area *area;
 	int free_pages, movable_pages, alike_pages;
 	int old_block_type;
 
@@ -2451,8 +2445,7 @@ static void steal_suitable_fallback(struct zone *zone, struct page *page,
 	return;
 
 single_page:
-	area = &zone->free_area[current_order];
-	move_to_free_area(page, area, start_type);
+	move_to_free_list(page, zone, current_order, start_type);
 }
 
 /*
@@ -3123,7 +3116,6 @@ void split_page(struct page *page, unsigned int order)
 
 int __isolate_free_page(struct page *page, unsigned int order)
 {
-	struct free_area *area = &page_zone(page)->free_area[order];
 	unsigned long watermark;
 	struct zone *zone;
 	int mt;
@@ -3149,7 +3141,7 @@ int __isolate_free_page(struct page *page, unsigned int order)
 
 	/* Remove page from free list */
 
-	del_page_from_free_area(page, area);
+	del_page_from_free_list(page, zone, order);
 
 	/*
 	 * Set the pageblock if the isolated page is at least half of a
@@ -8560,7 +8552,7 @@ void zone_pcp_reset(struct zone *zone)
 		pr_info("remove from free list %lx %d %lx\n",
 			pfn, 1 << order, end_pfn);
 #endif
-		del_page_from_free_area(page, &zone->free_area[order]);
+		del_page_from_free_list(page, zone, order);
 		for (i = 0; i < (1 << order); i++)
 			SetPageReserved((page+i));
 		pfn += (1 << order);

[PATCH v2 4/5] mm: Introduce Hinted pages

[Alexander Duyck]

From: Alexander Duyck <alexander.h.duyck@linux.intel.com>

In order to pave the way for free page hinting in virtualized environments
we will need a way to get pages out of the free lists and identify those
pages after they have been returned. To accomplish this, this patch adds
the concept of a Hinted Buddy, which is essentially meant to just be the
Offline page type used in conjunction with the Buddy page type.

It adds a set of pointers we shall call "boundary" which represents the
upper boundary between the unhinted and hinted pages. The general idea is
that in order for a page to cross from one side of the boundary to the
other it will need to go through the hinting process. Ultimately a
free_list has been fully processed when the boundary has been moved from
the tail all they way up to occupying the first entry in the list.

Doing this we should be able to make certain that we keep the hinted
pages as one contiguous block in each free list. This will allow us to
efficiently manipulate the free lists whenever we need to go in and start
sending hints to the hypervisor that there are new pages that have been
freed and are no longer in use.

An added advantage to this approach is that we should be reducing the
overall memory footprint of the guest as it will be more likely to recycle
warm pages versus trying to allocate the hinted pages that were likely
evicted from the guest memory.

Since we will only be hinting one zone at a time we keep the boundary
limited to being defined for just the zone we are currently placing hinted
pages into. Doing this we can keep the number of additional pointers needed
quite small. To flag that the boundaries are in place we use a single bit
in the zone to indicate that hinting and the boundaries are active.

The determination of when to start hinting is based on the tracking of the
number of free pages in a given area versus the number of hinted pages in
that area. We keep track of the number of hinted pages per free_area in a
separate zone specific area. We do this to avoid modifying the free_area
structure as this can lead to false sharing for the highest order with the
zone lock which leads to a noticeable performance degradation.

Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
---
 include/linux/mmzone.h       |   40 +++++-
 include/linux/page-flags.h   |    8 +
 include/linux/page_hinting.h |  139 ++++++++++++++++++++
 mm/Kconfig                   |    5 +
 mm/Makefile                  |    1 
 mm/memory_hotplug.c          |    1 
 mm/page_alloc.c              |  136 ++++++++++++++++++-
 mm/page_hinting.c            |  298 ++++++++++++++++++++++++++++++++++++++++++
 8 files changed, 620 insertions(+), 8 deletions(-)
 create mode 100644 include/linux/page_hinting.h
 create mode 100644 mm/page_hinting.c

diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index f0c68b6b6154..42bdebb20484 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -460,6 +460,14 @@ struct zone {
 	seqlock_t		span_seqlock;
 #endif
 
+#ifdef CONFIG_PAGE_HINTING
+	/*
+	 * Pointer to hinted page tracking statistics array. The size of
+	 * the array is MAX_ORDER - PAGE_HINTING_MIN_ORDER. NULL when
+	 * page hinting is not present.
+	 */
+	unsigned long		*hinted_pages;
+#endif
 	int initialized;
 
 	/* Write-intensive fields used from the page allocator */
@@ -535,6 +543,14 @@ enum zone_flags {
 	ZONE_BOOSTED_WATERMARK,		/* zone recently boosted watermarks.
 					 * Cleared when kswapd is woken.
 					 */
+	ZONE_PAGE_HINTING_REQUESTED,	/* zone enabled page hinting and has
+					 * requested flushing the data out of
+					 * higher order pages.
+					 */
+	ZONE_PAGE_HINTING_ACTIVE,	/* zone enabled page hinting and is
+					 * activly flushing the data out of
+					 * higher order pages.
+					 */
 };
 
 static inline unsigned long zone_managed_pages(struct zone *zone)
@@ -755,6 +771,8 @@ static inline bool pgdat_is_empty(pg_data_t *pgdat)
 	return !pgdat->node_start_pfn && !pgdat->node_spanned_pages;
 }
 
+#include <linux/page_hinting.h>
+
 /* Used for pages not on another list */
 static inline void add_to_free_list(struct page *page, struct zone *zone,
 				    unsigned int order, int migratetype)
@@ -769,10 +787,16 @@ static inline void add_to_free_list(struct page *page, struct zone *zone,
 static inline void add_to_free_list_tail(struct page *page, struct zone *zone,
 					 unsigned int order, int migratetype)
 {
-	struct free_area *area = &zone->free_area[order];
+	struct list_head *tail = get_unhinted_tail(zone, order, migratetype);
 
-	list_add_tail(&page->lru, &area->free_list[migratetype]);
-	area->nr_free++;
+	/*
+	 * To prevent the unhinted pages from being interleaved with the
+	 * hinted ones while we are actively processing pages we will use
+	 * the head of the hinted pages to determine the tail of the free
+	 * list.
+	 */
+	list_add_tail(&page->lru, tail);
+	zone->free_area[order].nr_free++;
 }
 
 /* Used for pages which are on another list */
@@ -781,12 +805,22 @@ static inline void move_to_free_list(struct page *page, struct zone *zone,
 {
 	struct free_area *area = &zone->free_area[order];
 
+	/*
+	 * Clear Hinted flag, if present, to avoid placing hinted pages
+	 * at the top of the free_list. It is cheaper to just process this
+	 * page again, then have to walk around a page that is already hinted.
+	 */
+	clear_page_hinted(page, zone);
+
 	list_move(&page->lru, &area->free_list[migratetype]);
 }
 
 static inline void del_page_from_free_list(struct page *page, struct zone *zone,
 					   unsigned int order)
 {
+	/* Clear Hinted flag, if present, before clearing the Buddy flag */
+	clear_page_hinted(page, zone);
+
 	list_del(&page->lru);
 	__ClearPageBuddy(page);
 	set_page_private(page, 0);
diff --git a/include/linux/page-flags.h b/include/linux/page-flags.h
index b848517da64c..b753dbf673cb 100644
--- a/include/linux/page-flags.h
+++ b/include/linux/page-flags.h
@@ -745,6 +745,14 @@ static inline int page_has_type(struct page *page)
 PAGE_TYPE_OPS(Offline, offline)
 
 /*
+ * PageHinted() is an alias for Offline, however it is not meant to be an
+ * exclusive value. It should be combined with PageBuddy() when seen as it
+ * is meant to indicate that the page has been scrubbed while waiting in
+ * the buddy system.
+ */
+PAGE_TYPE_OPS(Hinted, offline)
+
+/*
  * If kmemcg is enabled, the buddy allocator will set PageKmemcg() on
  * pages allocated with __GFP_ACCOUNT. It gets cleared on page free.
  */
diff --git a/include/linux/page_hinting.h b/include/linux/page_hinting.h
new file mode 100644
index 000000000000..526fb26663d9
--- /dev/null
+++ b/include/linux/page_hinting.h
@@ -0,0 +1,139 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _LINUX_PAGE_HINTING_H
+#define _LINUX_PAGE_HINTING_H
+
+#include <linux/mmzone.h>
+#include <linux/jump_label.h>
+#include <linux/pageblock-flags.h>
+#include <asm/pgtable_types.h>
+
+#define PAGE_HINTING_MIN_ORDER	pageblock_order
+#define PAGE_HINTING_HWM		32
+
+#ifdef CONFIG_PAGE_HINTING
+struct page_hinting_dev_info {
+	/* function that alters pages to make them "hinted" */
+	void (*react)(struct page_hinting_dev_info *phdev,
+		      unsigned int num_hints);
+
+	/* scatterlist containing pages to be processed */
+	struct scatterlist *sg;
+
+	/*
+	 * Upper limit on the number of pages that the react function
+	 * expects to be placed into the batch list to be processed.
+	 */
+	unsigned long capacity;
+
+	/* work struct for processing hints */
+	struct delayed_work work;
+
+	/*
+	 * The number of zones requesting hinting, plus one additional if
+	 * processing thread is active.
+	 */
+	atomic_t refcnt;
+};
+
+extern struct static_key page_hinting_notify_enabled;
+
+/* Boundary functions */
+struct list_head *__page_hinting_get_boundary(unsigned int order,
+					      int migratetype);
+void page_hinting_del_from_boundary(struct page *page, struct zone *zone);
+void page_hinting_add_to_boundary(struct page *page, struct zone *zone,
+			     int migratetype);
+
+/* Hinted page accessors, defined in page_alloc.c */
+struct page *get_unhinted_page(struct zone *zone, unsigned int order,
+			       int migratetype);
+void put_hinted_page(struct zone *zone, struct page *page);
+
+void __page_hinting_request(struct zone *zone);
+void __page_hinting_free_stats(struct zone *zone);
+
+/* Tear-down and bring-up for page hinting devices */
+void page_hinting_shutdown(struct page_hinting_dev_info *phdev);
+int page_hinting_startup(struct page_hinting_dev_info *phdev);
+#endif /* CONFIG_PAGE_HINTING */
+
+static inline struct list_head *get_unhinted_tail(struct zone *zone,
+						  unsigned int order,
+						  int migratetype)
+{
+#ifdef CONFIG_PAGE_HINTING
+	if (order >= PAGE_HINTING_MIN_ORDER &&
+	    test_bit(ZONE_PAGE_HINTING_ACTIVE, &zone->flags))
+		return __page_hinting_get_boundary(order, migratetype);
+#endif
+	return &zone->free_area[order].free_list[migratetype];
+}
+
+static inline void clear_page_hinted(struct page *page,
+				     struct zone *zone)
+{
+#ifdef CONFIG_PAGE_HINTING
+	if (likely(!PageHinted(page)))
+		return;
+
+	/* push boundary back if we removed the upper boundary */
+	if (test_bit(ZONE_PAGE_HINTING_ACTIVE, &zone->flags))
+		page_hinting_del_from_boundary(page, zone);
+
+	__ClearPageHinted(page);
+
+	/* page_private will contain the page order, so just use it directly */
+	zone->hinted_pages[page_private(page) - PAGE_HINTING_MIN_ORDER]--;
+#endif
+}
+
+/* Free hinted_pages and reset hinted page tracking count to 0 */
+static inline void page_hinting_reset(struct zone *zone)
+{
+#ifdef CONFIG_PAGE_HINTING
+	if (zone->hinted_pages)
+		__page_hinting_free_stats(zone);
+#endif
+}
+
+/**
+ * page_hinting_notify_free - Free page notification to start page processing
+ * @zone: Pointer to current zone of last page processed
+ * @order: Order of last page added to zone
+ *
+ * This function is meant to act as a screener for __page_hinting_request which
+ * will determine if a give zone has crossed over the high-water mark that
+ * will justify us beginning page treatment. If we have crossed that
+ * threshold then it will start the process of pulling some pages and
+ * placing them in the batch list for treatment.
+ */
+static inline void page_hinting_notify_free(struct zone *zone, int order)
+{
+#ifdef CONFIG_PAGE_HINTING
+	unsigned long nr_hinted;
+
+	/* Called from hot path in __free_one_page() */
+	if (!static_key_false(&page_hinting_notify_enabled))
+		return;
+
+	/* Limit notifications only to higher order pages */
+	if (order < PAGE_HINTING_MIN_ORDER)
+		return;
+
+	/* Do not bother with tests if we have already requested hinting */
+	if (test_bit(ZONE_PAGE_HINTING_REQUESTED, &zone->flags))
+		return;
+
+	/* If hinted_pages is not populated, assume 0 */
+	nr_hinted = zone->hinted_pages ?
+		    zone->hinted_pages[order - PAGE_HINTING_MIN_ORDER] : 0;
+
+	/* Only request it if we have enough to begin the page hinting */
+	if (zone->free_area[order].nr_free < nr_hinted + PAGE_HINTING_HWM)
+		return;
+
+	/* This is slow, but should be called very rarely */
+	__page_hinting_request(zone);
+#endif
+}
+#endif /*_LINUX_PAGE_HINTING_H */
diff --git a/mm/Kconfig b/mm/Kconfig
index 56cec636a1fc..38354668f849 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -237,6 +237,11 @@ config COMPACTION
           linux-mm@kvack.org.
 
 #
+# support for free page hinting
+config PAGE_HINTING
+	bool
+
+#
 # support for page migration
 #
 config MIGRATION
diff --git a/mm/Makefile b/mm/Makefile
index 338e528ad436..7277ced923ab 100644
--- a/mm/Makefile
+++ b/mm/Makefile
@@ -104,3 +104,4 @@ obj-$(CONFIG_HARDENED_USERCOPY) += usercopy.o
 obj-$(CONFIG_PERCPU_STATS) += percpu-stats.o
 obj-$(CONFIG_HMM_MIRROR) += hmm.o
 obj-$(CONFIG_MEMFD_CREATE) += memfd.o
+obj-$(CONFIG_PAGE_HINTING) += page_hinting.o
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index 2a9bbddb0e55..7c2d49b1a918 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -1622,6 +1622,7 @@ static int __ref __offline_pages(unsigned long start_pfn,
 	if (!populated_zone(zone)) {
 		zone_pcp_reset(zone);
 		build_all_zonelists(NULL);
+		page_hinting_reset(zone);
 	} else
 		zone_pcp_update(zone);
 
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 9a73f69b37af..c83cb4a30aff 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -68,6 +68,7 @@
 #include <linux/lockdep.h>
 #include <linux/nmi.h>
 #include <linux/psi.h>
+#include <linux/page_hinting.h>
 
 #include <asm/sections.h>
 #include <asm/tlbflush.h>
@@ -915,7 +916,7 @@ static inline struct capture_control *task_capc(struct zone *zone)
 static inline void __free_one_page(struct page *page,
 		unsigned long pfn,
 		struct zone *zone, unsigned int order,
-		int migratetype)
+		int migratetype, bool hinted)
 {
 	struct capture_control *capc = task_capc(zone);
 	unsigned long uninitialized_var(buddy_pfn);
@@ -990,11 +991,20 @@ static inline void __free_one_page(struct page *page,
 done_merging:
 	set_page_order(page, order);
 
-	if (is_shuffle_order(order) ? shuffle_add_to_tail() :
-	    buddy_merge_likely(pfn, buddy_pfn, page, order))
+	if (hinted ||
+	    (is_shuffle_order(order) ? shuffle_add_to_tail() :
+	     buddy_merge_likely(pfn, buddy_pfn, page, order)))
 		add_to_free_list_tail(page, zone, order, migratetype);
 	else
 		add_to_free_list(page, zone, order, migratetype);
+
+	/*
+	 * No need to notify on a hinted page as the total count of
+	 * unhinted pages will not have increased since we have essentially
+	 * merged the hinted page with one or more unhinted pages.
+	 */
+	if (!hinted)
+		page_hinting_notify_free(zone, order);
 }
 
 /*
@@ -1305,7 +1315,7 @@ static void free_pcppages_bulk(struct zone *zone, int count,
 		if (unlikely(isolated_pageblocks))
 			mt = get_pageblock_migratetype(page);
 
-		__free_one_page(page, page_to_pfn(page), zone, 0, mt);
+		__free_one_page(page, page_to_pfn(page), zone, 0, mt, false);
 		trace_mm_page_pcpu_drain(page, 0, mt);
 	}
 	spin_unlock(&zone->lock);
@@ -1321,7 +1331,7 @@ static void free_one_page(struct zone *zone,
 		is_migrate_isolate(migratetype))) {
 		migratetype = get_pfnblock_migratetype(page, pfn);
 	}
-	__free_one_page(page, pfn, zone, order, migratetype);
+	__free_one_page(page, pfn, zone, order, migratetype, false);
 	spin_unlock(&zone->lock);
 }
 
@@ -2183,6 +2193,122 @@ struct page *__rmqueue_smallest(struct zone *zone, unsigned int order,
 	return NULL;
 }
 
+#ifdef CONFIG_PAGE_HINTING
+/**
+ * get_unhinted_page - Pull an unhinted page from the free_list
+ * @zone: Zone to draw pages from
+ * @order: Order to draw pages from
+ * @mt: Migratetype to draw pages from
+ *
+ * This function will obtain a page from the free list. It will start by
+ * attempting to pull from the tail of the free list and if that is already
+ * hinted on it will instead pull the head if that is unhinted.
+ *
+ * The page will have the migrate type and order stored in the page
+ * metadata. While being processed the page will not be avaialble for
+ * allocation.
+ *
+ * Return: page pointer if raw page found, otherwise NULL
+ */
+struct page *get_unhinted_page(struct zone *zone, unsigned int order, int mt)
+{
+	struct list_head *tail = get_unhinted_tail(zone, order, mt);
+	struct free_area *area = &(zone->free_area[order]);
+	struct list_head *list = &area->free_list[mt];
+	struct page *page;
+
+	/* zone lock should be held when this function is called */
+	lockdep_assert_held(&zone->lock);
+
+	/* Find a page of the appropriate size in the preferred list */
+	page = list_last_entry(tail, struct page, lru);
+	list_for_each_entry_from_reverse(page, list, lru) {
+		/* If we entered this loop then the "raw" list isn't empty */
+
+		/* If the page is hinted try the head of the list */
+		if (PageHinted(page)) {
+			page = list_first_entry(list, struct page, lru);
+
+			/*
+			 * If both the head and tail are hinted then reset
+			 * the boundary so that we read as an empty list
+			 * next time and bail out.
+			 */
+			if (PageHinted(page)) {
+				page_hinting_add_to_boundary(page, zone, mt);
+				break;
+			}
+		}
+
+		del_page_from_free_list(page, zone, order);
+
+		/* record migratetype and order within page */
+		set_pcppage_migratetype(page, mt);
+		set_page_private(page, order);
+
+		/*
+		 * Page will not be available for allocation while we are
+		 * processing it so update the freepage state.
+		 */
+		__mod_zone_freepage_state(zone, -(1 << order), mt);
+
+		return page;
+	}
+
+	return NULL;
+}
+
+/**
+ * put_hinted_page - Return a now-hinted page back where we got it
+ * @zone: Zone to return pages to
+ * @page: Page that was hinted
+ *
+ * This function will pull the migratetype and order information out
+ * of the page and attempt to return it where it found it. If the page
+ * is added to the free list without changes we will mark it as being
+ * hinted.
+ */
+void put_hinted_page(struct zone *zone, struct page *page)
+{
+	unsigned int order, mt;
+	unsigned long pfn;
+
+	/* zone lock should be held when this function is called */
+	lockdep_assert_held(&zone->lock);
+
+	mt = get_pcppage_migratetype(page);
+	pfn = page_to_pfn(page);
+
+	if (unlikely(has_isolate_pageblock(zone) || is_migrate_isolate(mt))) {
+		mt = get_pfnblock_migratetype(page, pfn);
+		set_pcppage_migratetype(page, mt);
+	}
+
+	order = page_private(page);
+	set_page_private(page, 0);
+
+	__free_one_page(page, pfn, zone, order, mt, true);
+
+	/*
+	 * If page was comingled with another page we cannot consider
+	 * the result to be "hinted" since part of the page hasn't been.
+	 * In this case we will simply exit and not update the "hinted"
+	 * state. Instead just treat the result as a unhinted page.
+	 */
+	if (!PageBuddy(page) || page_order(page) != order)
+		return;
+
+	/* update areated page accounting */
+	zone->hinted_pages[order - PAGE_HINTING_MIN_ORDER]++;
+
+	/* update boundary of new migratetype and record it */
+	page_hinting_add_to_boundary(page, zone, mt);
+
+	/* flag page as hinted */
+	__SetPageHinted(page);
+}
+#endif /* CONFIG_PAGE_HINTING */
+
 /*
  * This array describes the order lists are fallen back to when
  * the free lists for the desirable migrate type are depleted
diff --git a/mm/page_hinting.c b/mm/page_hinting.c
new file mode 100644
index 000000000000..d06d3762b315
--- /dev/null
+++ b/mm/page_hinting.c
@@ -0,0 +1,298 @@
+// SPDX-License-Identifier: GPL-2.0
+#include <linux/mm.h>
+#include <linux/mmzone.h>
+#include <linux/page-isolation.h>
+#include <linux/gfp.h>
+#include <linux/export.h>
+#include <linux/delay.h>
+#include <linux/slab.h>
+#include <linux/scatterlist.h>
+#include "internal.h"
+
+static struct page_hinting_dev_info __rcu *ph_dev_info __read_mostly;
+struct static_key page_hinting_notify_enabled;
+
+struct list_head *boundary[MAX_ORDER - PAGE_HINTING_MIN_ORDER][MIGRATE_TYPES];
+
+static void page_hinting_reset_boundary(struct zone *zone, unsigned int order,
+				   unsigned int migratetype)
+{
+	boundary[order - PAGE_HINTING_MIN_ORDER][migratetype] =
+			&zone->free_area[order].free_list[migratetype];
+}
+
+#define for_each_hinting_migratetype_order(_order, _type) \
+	for (_order = MAX_ORDER; _order-- != PAGE_HINTING_MIN_ORDER;) \
+		for (_type = MIGRATE_TYPES; _type--;)
+
+static int page_hinting_populate_metadata(struct zone *zone)
+{
+	unsigned int order, mt;
+
+	/*
+	 * We need to make sure we have somewhere to store the tracking
+	 * data for how many hinted pages are in the zone. To do that
+	 * we need to make certain zone->hinted_pages is populated.
+	 */
+	if (!zone->hinted_pages) {
+		zone->hinted_pages = kcalloc(MAX_ORDER - PAGE_HINTING_MIN_ORDER,
+					     sizeof(unsigned long),
+					     GFP_KERNEL);
+		if (!zone->hinted_pages)
+			return -ENOMEM;
+	}
+
+	/* Update boundary data to reflect the zone we are currently working */
+	for_each_hinting_migratetype_order(order, mt)
+		page_hinting_reset_boundary(zone, order, mt);
+
+	return 0;
+}
+
+struct list_head *__page_hinting_get_boundary(unsigned int order,
+					      int migratetype)
+{
+	return boundary[order - PAGE_HINTING_MIN_ORDER][migratetype];
+}
+
+void page_hinting_del_from_boundary(struct page *page, struct zone *zone)
+{
+	unsigned int order = page_private(page) - PAGE_HINTING_MIN_ORDER;
+	int mt = get_pcppage_migratetype(page);
+	struct list_head **tail = &boundary[order][mt];
+
+	if (*tail == &page->lru)
+		*tail = page->lru.next;
+}
+
+void page_hinting_add_to_boundary(struct page *page, struct zone *zone,
+			     int migratetype)
+{
+	unsigned int order = page_private(page) - PAGE_HINTING_MIN_ORDER;
+	struct list_head **tail = &boundary[order][migratetype];
+
+	*tail = &page->lru;
+}
+
+static unsigned int page_hinting_fill(struct zone *zone,
+				      struct page_hinting_dev_info *phdev)
+{
+	struct scatterlist *sg = phdev->sg;
+	unsigned int order, mt, count = 0;
+
+	sg_init_table(phdev->sg, phdev->capacity);
+
+	for_each_hinting_migratetype_order(order, mt) {
+		struct page *page;
+
+		/*
+		 * Pull pages from free list until we have drained
+		 * it or we have reached capacity.
+		 */
+		while ((page = get_unhinted_page(zone, order, mt))) {
+			sg_set_page(&sg[count], page, PAGE_SIZE << order, 0);
+
+			if (++count == phdev->capacity)
+				return count;
+		}
+	}
+
+	/* mark end of scatterlist due to underflow */
+	if (count)
+		sg_mark_end(&sg[count - 1]);
+
+	/*
+	 * If there are no longer enough free pages to fully populate
+	 * the scatterlist, then we can just shut it down for this zone.
+	 */
+	clear_bit(ZONE_PAGE_HINTING_REQUESTED, &zone->flags);
+	atomic_dec(&phdev->refcnt);
+
+	return count;
+}
+
+static void page_hinting_drain(struct zone *zone,
+			       struct page_hinting_dev_info *phdev)
+{
+	struct scatterlist *sg = phdev->sg;
+
+	/*
+	 * Drain the now hinted pages back into their respective
+	 * free lists/areas. We assume at least one page is populated.
+	 */
+	do {
+		put_hinted_page(zone, sg_page(sg));
+	} while (!sg_is_last(sg++));
+}
+
+/*
+ * The page hinting cycle consists of 4 stages, fill, react, drain, and idle.
+ * We will cycle through the first 3 stages until we fail to obtain any
+ * pages, in that case we will switch to idle.
+ */
+static void page_hinting_cycle(struct zone *zone,
+			       struct page_hinting_dev_info *phdev)
+{
+	/*
+	 * Guarantee boundaries and stats are populated before we
+	 * start placing hinted pages in the zone.
+	 */
+	if (page_hinting_populate_metadata(zone))
+		return;
+
+	spin_lock(&zone->lock);
+
+	/* set bit indicating boundaries are present */
+	set_bit(ZONE_PAGE_HINTING_ACTIVE, &zone->flags);
+
+	do {
+		/* Pull pages out of allocator into a scaterlist */
+		unsigned int num_hints = page_hinting_fill(zone, phdev);
+
+		/* no pages were acquired, give up */
+		if (!num_hints)
+			break;
+
+		spin_unlock(&zone->lock);
+
+		/* begin processing pages in local list */
+		phdev->react(phdev, num_hints);
+
+		spin_lock(&zone->lock);
+
+		/*
+		 * We should have a scatterlist of pages that have been
+		 * processed. Return them to their original free lists.
+		 */
+		page_hinting_drain(zone, phdev);
+
+		/* keep pulling pages till there are none to pull */
+	} while (test_bit(ZONE_PAGE_HINTING_REQUESTED, &zone->flags));
+
+	/* processing of the zone is complete, we can disable boundaries */
+	clear_bit(ZONE_PAGE_HINTING_ACTIVE, &zone->flags);
+
+	spin_unlock(&zone->lock);
+}
+
+static void page_hinting_process(struct work_struct *work)
+{
+	struct delayed_work *d_work = to_delayed_work(work);
+	struct page_hinting_dev_info *phdev =
+		container_of(d_work, struct page_hinting_dev_info, work);
+	struct zone *zone = first_online_pgdat()->node_zones;
+
+	do {
+		if (test_bit(ZONE_PAGE_HINTING_REQUESTED, &zone->flags))
+			page_hinting_cycle(zone, phdev);
+
+		/*
+		 * Move to next zone, if at the end of the list
+		 * test to see if we can just go into idle.
+		 */
+		zone = next_zone(zone);
+		if (zone)
+			continue;
+		zone = first_online_pgdat()->node_zones;
+
+		/*
+		 * As long as refcnt has not reached zero there are still
+		 * zones to be processed.
+		 */
+	} while (atomic_read(&phdev->refcnt));
+}
+
+/* request page hinting on this zone */
+void __page_hinting_request(struct zone *zone)
+{
+	struct page_hinting_dev_info *phdev;
+
+	rcu_read_lock();
+
+	/*
+	 * We use RCU to protect the ph_dev_info pointer. In almost all
+	 * cases this should be present, however in the unlikely case of
+	 * a shutdown this will be NULL and we should exit.
+	 */
+	phdev = rcu_dereference(ph_dev_info);
+	if (unlikely(!phdev))
+		return;
+
+	/*
+	 * We can use separate test and set operations here as there
+	 * is nothing else that can set or clear this bit while we are
+	 * holding the zone lock. The advantage to doing it this way is
+	 * that we don't have to dirty the cacheline unless we are
+	 * changing the value.
+	 */
+	set_bit(ZONE_PAGE_HINTING_REQUESTED, &zone->flags);
+
+	/*
+	 * Delay the start of work to allow a sizable queue to
+	 * build. For now we are limiting this to running no more
+	 * than 10 times per second.
+	 */
+	if (!atomic_fetch_inc(&phdev->refcnt))
+		schedule_delayed_work(&phdev->work, HZ / 10);
+
+	rcu_read_unlock();
+}
+
+void __page_hinting_free_stats(struct zone *zone)
+{
+	/* free hinted_page statisitics */
+	kfree(zone->hinted_pages);
+	zone->hinted_pages = NULL;
+}
+
+void page_hinting_shutdown(struct page_hinting_dev_info *phdev)
+{
+	if (rcu_access_pointer(ph_dev_info) != phdev)
+		return;
+
+	/* Disable page hinting notification */
+	static_key_slow_dec(&page_hinting_notify_enabled);
+	RCU_INIT_POINTER(ph_dev_info, NULL);
+	synchronize_rcu();
+
+	/* Flush any existing work, and lock it out */
+	cancel_delayed_work_sync(&phdev->work);
+
+	/* Free scatterlist */
+	kfree(phdev->sg);
+	phdev->sg = NULL;
+}
+EXPORT_SYMBOL_GPL(page_hinting_shutdown);
+
+int page_hinting_startup(struct page_hinting_dev_info *phdev)
+{
+	struct zone *zone;
+
+	/* nothing to do if already in use */
+	if (rcu_access_pointer(ph_dev_info))
+		return -EBUSY;
+
+	/* allocate scatterlist to store pages being hinted on */
+	phdev->sg = kcalloc(phdev->capacity, sizeof(*phdev->sg), GFP_KERNEL);
+	if (!phdev->sg)
+		return -ENOMEM;
+
+	/* initialize refcnt and work structures */
+	atomic_set(&phdev->refcnt, 0);
+	INIT_DELAYED_WORK(&phdev->work, &page_hinting_process);
+
+	/* assign device, and begin initial flush of populated zones */
+	rcu_assign_pointer(ph_dev_info, phdev);
+	for_each_populated_zone(zone) {
+		spin_lock(&zone->lock);
+		__page_hinting_request(zone);
+		spin_unlock(&zone->lock);
+	}
+
+	/* enable page hinting notification */
+	static_key_slow_inc(&page_hinting_notify_enabled);
+
+	return 0;
+}
+EXPORT_SYMBOL_GPL(page_hinting_startup);
+

[PATCH v2 5/5] virtio-balloon: Add support for providing page hints to host

[Alexander Duyck]

From: Alexander Duyck <alexander.h.duyck@linux.intel.com>

Add support for the page hinting feature provided by virtio-balloon.
Hinting differs from the regular balloon functionality in that is is
much less durable than a standard memory balloon. Instead of creating a
list of pages that cannot be accessed the pages are only inaccessible
while they are being indicated to the virtio interface. Once the
interface has acknowledged them they are placed back into their respective
free lists and are once again accessible by the guest system.

Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
---
 drivers/virtio/Kconfig              |    1 +
 drivers/virtio/virtio_balloon.c     |   47 +++++++++++++++++++++++++++++++++++
 include/uapi/linux/virtio_balloon.h |    1 +
 3 files changed, 49 insertions(+)

diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig
index 078615cf2afc..d45556ae1f81 100644
--- a/drivers/virtio/Kconfig
+++ b/drivers/virtio/Kconfig
@@ -58,6 +58,7 @@ config VIRTIO_BALLOON
 	tristate "Virtio balloon driver"
 	depends on VIRTIO
 	select MEMORY_BALLOON
+	select PAGE_HINTING
 	---help---
 	 This driver supports increasing and decreasing the amount
 	 of memory within a KVM guest.
diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
index 226fbb995fb0..dee9f8f3ad09 100644
--- a/drivers/virtio/virtio_balloon.c
+++ b/drivers/virtio/virtio_balloon.c
@@ -19,6 +19,7 @@
 #include <linux/mount.h>
 #include <linux/magic.h>
 #include <linux/pseudo_fs.h>
+#include <linux/page_hinting.h>
 
 /*
  * Balloon device works in 4K page units.  So each page is pointed to by
@@ -27,6 +28,7 @@
  */
 #define VIRTIO_BALLOON_PAGES_PER_PAGE (unsigned)(PAGE_SIZE >> VIRTIO_BALLOON_PFN_SHIFT)
 #define VIRTIO_BALLOON_ARRAY_PFNS_MAX 256
+#define VIRTIO_BALLOON_ARRAY_HINTS_MAX	32
 #define VIRTBALLOON_OOM_NOTIFY_PRIORITY 80
 
 #define VIRTIO_BALLOON_FREE_PAGE_ALLOC_FLAG (__GFP_NORETRY | __GFP_NOWARN | \
@@ -46,6 +48,7 @@ enum virtio_balloon_vq {
 	VIRTIO_BALLOON_VQ_DEFLATE,
 	VIRTIO_BALLOON_VQ_STATS,
 	VIRTIO_BALLOON_VQ_FREE_PAGE,
+	VIRTIO_BALLOON_VQ_HINTING,
 	VIRTIO_BALLOON_VQ_MAX
 };
 
@@ -113,6 +116,10 @@ struct virtio_balloon {
 
 	/* To register a shrinker to shrink memory upon memory pressure */
 	struct shrinker shrinker;
+
+	/* Unused page hinting device */
+	struct virtqueue *hinting_vq;
+	struct page_hinting_dev_info ph_dev_info;
 };
 
 static struct virtio_device_id id_table[] = {
@@ -152,6 +159,22 @@ static void tell_host(struct virtio_balloon *vb, struct virtqueue *vq)
 
 }
 
+void virtballoon_page_hinting_react(struct page_hinting_dev_info *ph_dev_info,
+				    unsigned int num_hints)
+{
+	struct virtio_balloon *vb =
+		container_of(ph_dev_info, struct virtio_balloon, ph_dev_info);
+	struct virtqueue *vq = vb->hinting_vq;
+	unsigned int unused;
+
+	/* We should always be able to add these buffers to an empty queue. */
+	virtqueue_add_inbuf(vq, ph_dev_info->sg, num_hints, vb, GFP_KERNEL);
+	virtqueue_kick(vq);
+
+	/* When host has read buffer, this completes via balloon_ack */
+	wait_event(vb->acked, virtqueue_get_buf(vq, &unused));
+}
+
 static void set_page_pfns(struct virtio_balloon *vb,
 			  __virtio32 pfns[], struct page *page)
 {
@@ -476,6 +499,7 @@ static int init_vqs(struct virtio_balloon *vb)
 	names[VIRTIO_BALLOON_VQ_DEFLATE] = "deflate";
 	names[VIRTIO_BALLOON_VQ_STATS] = NULL;
 	names[VIRTIO_BALLOON_VQ_FREE_PAGE] = NULL;
+	names[VIRTIO_BALLOON_VQ_HINTING] = NULL;
 
 	if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_STATS_VQ)) {
 		names[VIRTIO_BALLOON_VQ_STATS] = "stats";
@@ -487,11 +511,19 @@ static int init_vqs(struct virtio_balloon *vb)
 		callbacks[VIRTIO_BALLOON_VQ_FREE_PAGE] = NULL;
 	}
 
+	if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_HINTING)) {
+		names[VIRTIO_BALLOON_VQ_HINTING] = "hinting_vq";
+		callbacks[VIRTIO_BALLOON_VQ_HINTING] = balloon_ack;
+	}
+
 	err = vb->vdev->config->find_vqs(vb->vdev, VIRTIO_BALLOON_VQ_MAX,
 					 vqs, callbacks, names, NULL, NULL);
 	if (err)
 		return err;
 
+	if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_HINTING))
+		vb->hinting_vq = vqs[VIRTIO_BALLOON_VQ_HINTING];
+
 	vb->inflate_vq = vqs[VIRTIO_BALLOON_VQ_INFLATE];
 	vb->deflate_vq = vqs[VIRTIO_BALLOON_VQ_DEFLATE];
 	if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_STATS_VQ)) {
@@ -924,12 +956,24 @@ static int virtballoon_probe(struct virtio_device *vdev)
 		if (err)
 			goto out_del_balloon_wq;
 	}
+
+	vb->ph_dev_info.react = virtballoon_page_hinting_react;
+	vb->ph_dev_info.capacity = VIRTIO_BALLOON_ARRAY_HINTS_MAX;
+	if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_HINTING)) {
+		err = page_hinting_startup(&vb->ph_dev_info);
+		if (err)
+			goto out_unregister_shrinker;
+	}
+
 	virtio_device_ready(vdev);
 
 	if (towards_target(vb))
 		virtballoon_changed(vdev);
 	return 0;
 
+out_unregister_shrinker:
+	if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_DEFLATE_ON_OOM))
+		virtio_balloon_unregister_shrinker(vb);
 out_del_balloon_wq:
 	if (virtio_has_feature(vdev, VIRTIO_BALLOON_F_FREE_PAGE_HINT))
 		destroy_workqueue(vb->balloon_wq);
@@ -958,6 +1002,8 @@ static void virtballoon_remove(struct virtio_device *vdev)
 {
 	struct virtio_balloon *vb = vdev->priv;
 
+	if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_HINTING))
+		page_hinting_shutdown(&vb->ph_dev_info);
 	if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_DEFLATE_ON_OOM))
 		virtio_balloon_unregister_shrinker(vb);
 	spin_lock_irq(&vb->stop_update_lock);
@@ -1027,6 +1073,7 @@ static int virtballoon_validate(struct virtio_device *vdev)
 	VIRTIO_BALLOON_F_DEFLATE_ON_OOM,
 	VIRTIO_BALLOON_F_FREE_PAGE_HINT,
 	VIRTIO_BALLOON_F_PAGE_POISON,
+	VIRTIO_BALLOON_F_HINTING,
 };
 
 static struct virtio_driver virtio_balloon_driver = {
diff --git a/include/uapi/linux/virtio_balloon.h b/include/uapi/linux/virtio_balloon.h
index a1966cd7b677..2b0f62814e22 100644
--- a/include/uapi/linux/virtio_balloon.h
+++ b/include/uapi/linux/virtio_balloon.h
@@ -36,6 +36,7 @@
 #define VIRTIO_BALLOON_F_DEFLATE_ON_OOM	2 /* Deflate balloon on OOM */
 #define VIRTIO_BALLOON_F_FREE_PAGE_HINT	3 /* VQ to report free pages */
 #define VIRTIO_BALLOON_F_PAGE_POISON	4 /* Guest is using page poisoning */
+#define VIRTIO_BALLOON_F_HINTING	5 /* Page hinting virtqueue */
 
 /* Size of a PFN in the balloon interface. */
 #define VIRTIO_BALLOON_PFN_SHIFT 12

[PATCH v2 QEMU] virtio-balloon: Provide a interface for "bubble hinting"

[Alexander Duyck]

From: Alexander Duyck <alexander.h.duyck@linux.intel.com>

Add support for what I am referring to as "bubble hinting". Basically the
idea is to function very similar to how the balloon works in that we
basically end up madvising the page as not being used. However we don't
really need to bother with any deflate type logic since the page will be
faulted back into the guest when it is read or written to.

This is meant to be a simplification of the existing balloon interface
to use for providing hints to what memory needs to be freed. I am assuming
this is safe to do as the deflate logic does not actually appear to do very
much other than tracking what subpages have been released and which ones
haven't.

Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
---
 hw/virtio/virtio-balloon.c                      |   40 +++++++++++++++++++++++
 include/hw/virtio/virtio-balloon.h              |    2 +
 include/standard-headers/linux/virtio_balloon.h |    1 +
 3 files changed, 42 insertions(+), 1 deletion(-)

diff --git a/hw/virtio/virtio-balloon.c b/hw/virtio/virtio-balloon.c
index 2112874055fb..70c0004c0f88 100644
--- a/hw/virtio/virtio-balloon.c
+++ b/hw/virtio/virtio-balloon.c
@@ -328,6 +328,39 @@ static void balloon_stats_set_poll_interval(Object *obj, Visitor *v,
     balloon_stats_change_timer(s, 0);
 }
 
+static void virtio_bubble_handle_output(VirtIODevice *vdev, VirtQueue *vq)
+{
+    VirtQueueElement *elem;
+
+    while ((elem = virtqueue_pop(vq, sizeof(VirtQueueElement)))) {
+    	unsigned int i;
+
+        for (i = 0; i < elem->in_num; i++) {
+            void *addr = elem->in_sg[i].iov_base;
+            size_t size = elem->in_sg[i].iov_len;
+            ram_addr_t ram_offset;
+            size_t rb_page_size;
+            RAMBlock *rb;
+
+            if (qemu_balloon_is_inhibited())
+                continue;
+
+            rb = qemu_ram_block_from_host(addr, false, &ram_offset);
+            rb_page_size = qemu_ram_pagesize(rb);
+
+            /* For now we will simply ignore unaligned memory regions */
+            if ((ram_offset | size) & (rb_page_size - 1))
+                continue;
+
+            ram_block_discard_range(rb, ram_offset, size);
+        }
+
+        virtqueue_push(vq, elem, 0);
+        virtio_notify(vdev, vq);
+        g_free(elem);
+    }
+}
+
 static void virtio_balloon_handle_output(VirtIODevice *vdev, VirtQueue *vq)
 {
     VirtIOBalloon *s = VIRTIO_BALLOON(vdev);
@@ -782,6 +815,11 @@ static void virtio_balloon_device_realize(DeviceState *dev, Error **errp)
     s->svq = virtio_add_queue(vdev, 128, virtio_balloon_receive_stats);
 
     if (virtio_has_feature(s->host_features,
+                           VIRTIO_BALLOON_F_HINTING)) {
+        s->hvq = virtio_add_queue(vdev, 128, virtio_bubble_handle_output);
+    }
+
+    if (virtio_has_feature(s->host_features,
                            VIRTIO_BALLOON_F_FREE_PAGE_HINT)) {
         s->free_page_vq = virtio_add_queue(vdev, VIRTQUEUE_MAX_SIZE,
                                            virtio_balloon_handle_free_page_vq);
@@ -897,6 +935,8 @@ static Property virtio_balloon_properties[] = {
                     VIRTIO_BALLOON_F_DEFLATE_ON_OOM, false),
     DEFINE_PROP_BIT("free-page-hint", VirtIOBalloon, host_features,
                     VIRTIO_BALLOON_F_FREE_PAGE_HINT, false),
+    DEFINE_PROP_BIT("guest-page-hinting", VirtIOBalloon, host_features,
+                    VIRTIO_BALLOON_F_HINTING, true),
     DEFINE_PROP_LINK("iothread", VirtIOBalloon, iothread, TYPE_IOTHREAD,
                      IOThread *),
     DEFINE_PROP_END_OF_LIST(),
diff --git a/include/hw/virtio/virtio-balloon.h b/include/hw/virtio/virtio-balloon.h
index 1afafb12f6bc..a58b24fdf29d 100644
--- a/include/hw/virtio/virtio-balloon.h
+++ b/include/hw/virtio/virtio-balloon.h
@@ -44,7 +44,7 @@ enum virtio_balloon_free_page_report_status {
 
 typedef struct VirtIOBalloon {
     VirtIODevice parent_obj;
-    VirtQueue *ivq, *dvq, *svq, *free_page_vq;
+    VirtQueue *ivq, *dvq, *svq, *free_page_vq, *hvq;
     uint32_t free_page_report_status;
     uint32_t num_pages;
     uint32_t actual;
diff --git a/include/standard-headers/linux/virtio_balloon.h b/include/standard-headers/linux/virtio_balloon.h
index 9375ca2a70de..f9e3e8256261 100644
--- a/include/standard-headers/linux/virtio_balloon.h
+++ b/include/standard-headers/linux/virtio_balloon.h
@@ -36,6 +36,7 @@
 #define VIRTIO_BALLOON_F_DEFLATE_ON_OOM	2 /* Deflate balloon on OOM */
 #define VIRTIO_BALLOON_F_FREE_PAGE_HINT	3 /* VQ to report free pages */
 #define VIRTIO_BALLOON_F_PAGE_POISON	4 /* Guest is using page poisoning */
+#define VIRTIO_BALLOON_F_HINTING	5 /* Page hinting virtqueue */
 
 /* Size of a PFN in the balloon interface. */
 #define VIRTIO_BALLOON_PFN_SHIFT 12

Re: [PATCH v2 0/5] mm / virtio: Provide support for page hinting

[Nitesh Narayan Lal]

On 7/24/19 12:54 PM, 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 page hinting
>
> The functionality for this is fairly simple. When enabled it will allocate
> statistics to track the number of hinted pages in a given free area. When
> the number of free pages exceeds this value plus a high water value,
> currently 32,
Shouldn't we configure this to a lower number such as 16?
>  it will begin performing page hinting which consists of
> pulling pages off of free list and placing them into a scatter list. The
> scatterlist is then given to the page hinting device and it will perform
> the required action to make the pages "hinted", in the case of
> virtio-balloon this results in the pages being madvised as MADV_DONTNEED
> and as such they are forced out of the guest. After this they are placed
> back on the free list, and an additional bit is added if they are not
> merged indicating that they are a hinted buddy page instead of a standard
> buddy page. The cycle then repeats with additional non-hinted pages being
> pulled until the free areas all consist of hinted pages.
>
> I am leaving a number of things hard-coded such as limiting the lowest
> order processed to PAGEBLOCK_ORDER,
Have you considered making this option configurable at the compile time?
>  and have left it up to the guest to
> determine what the limit is on how many pages it wants to allocate to
> process the hints.
It might make sense to set the number of pages to be hinted at a time from the
hypervisor.
>
> My primary testing has just been to verify the memory is being freed after
> allocation by running memhog 79g on a 80g 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 at most a 2% difference between the base
> kernel without these patches and the patches with virtio-balloon disabled.
> With the patches and virtio-balloon enabled with hinting the results
> largely depend on the host kernel. On a 3.10 RHEL kernel I saw up to a 2%
> drop in performance as I approached 16 threads,
I think this is acceptable.
>  however on the the lastest
> linux-next kernel I saw roughly a 4% to 5% improvement in performance for
> all tests with 8 or more threads. 
Do you mean that with your patches the will-it-scale/page_fault1 numbers were
better by 4-5% over an unmodified kernel?
> I believe the difference seen is due to
> the overhead for faulting pages back into the guest and zeroing of memory.
It may also make sense to test these patches with netperf to observe how much
performance drop it is introducing.
> Patch 4 is a bit on the large side at about 600 lines of change, however
> I really didn't see a good way to break it up since each piece feeds into
> the next. So I couldn't add the statistics by themselves as it didn't
> really make sense to add them without something that will either read or
> increment/decrement them, or add the Hinted state without something that
> would set/unset it. As such I just ended up adding the entire thing as
> one patch. It makes it a bit bigger but avoids the issues in the previous
> set where I was referencing things before they had been added.
>
> Changes from the RFC:
> https://lore.kernel.org/lkml/20190530215223.13974.22445.stgit@localhost.localdomain/
> Moved aeration requested flag out of aerator and into zone->flags.
> Moved bounary 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.
>
> Changes from v1:
> https://lore.kernel.org/lkml/20190619222922.1231.27432.stgit@localhost.localdomain/
> Dropped "waste page treatment" in favor of "page hinting"
We may still have to try and find a better name for virtio-balloon side changes.
As "FREE_PAGE_HINT" and "PAGE_HINTING" are still confusing.
> Renamed files and functions from "aeration" to "page_hinting"
> Moved from page->lru list to scatterlist
> Replaced wait on refcnt in shutdown with RCU and cancel_delayed_work_sync
> Virtio now uses scatterlist directly instead of intermedate array
> Moved stats out of free_area, now in seperate area and pointed to from zone
> Merged patch 5 into patch 4 to improve reviewability
> Updated various code comments throughout
>
> ---
>
> Alexander Duyck (5):
>       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 Hinted pages
>       virtio-balloon: Add support for providing page hints to host
>
>
>  drivers/virtio/Kconfig              |    1 
>  drivers/virtio/virtio_balloon.c     |   47 ++++++
>  include/linux/mmzone.h              |  116 ++++++++------
>  include/linux/page-flags.h          |    8 +
>  include/linux/page_hinting.h        |  139 ++++++++++++++++
>  include/uapi/linux/virtio_balloon.h |    1 
>  mm/Kconfig                          |    5 +
>  mm/Makefile                         |    1 
>  mm/internal.h                       |   18 ++
>  mm/memory_hotplug.c                 |    1 
>  mm/page_alloc.c                     |  238 ++++++++++++++++++++--------
>  mm/page_hinting.c                   |  298 +++++++++++++++++++++++++++++++++++
>  mm/shuffle.c                        |   24 ---
>  mm/shuffle.h                        |   32 ++++
>  14 files changed, 796 insertions(+), 133 deletions(-)
>  create mode 100644 include/linux/page_hinting.h
>  create mode 100644 mm/page_hinting.c
>
> --
-- 
Thanks
Nitesh

Re: [PATCH v2 0/5] mm / virtio: Provide support for page hinting

[David Hildenbrand]

On 24.07.19 20:40, Nitesh Narayan Lal wrote:
> 
> On 7/24/19 12:54 PM, 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 page hinting
>>
>> The functionality for this is fairly simple. When enabled it will allocate
>> statistics to track the number of hinted pages in a given free area. When
>> the number of free pages exceeds this value plus a high water value,
>> currently 32,
> Shouldn't we configure this to a lower number such as 16?
>>  it will begin performing page hinting which consists of
>> pulling pages off of free list and placing them into a scatter list. The
>> scatterlist is then given to the page hinting device and it will perform
>> the required action to make the pages "hinted", in the case of
>> virtio-balloon this results in the pages being madvised as MADV_DONTNEED
>> and as such they are forced out of the guest. After this they are placed
>> back on the free list, and an additional bit is added if they are not
>> merged indicating that they are a hinted buddy page instead of a standard
>> buddy page. The cycle then repeats with additional non-hinted pages being
>> pulled until the free areas all consist of hinted pages.
>>
>> I am leaving a number of things hard-coded such as limiting the lowest
>> order processed to PAGEBLOCK_ORDER,
> Have you considered making this option configurable at the compile time?
>>  and have left it up to the guest to
>> determine what the limit is on how many pages it wants to allocate to
>> process the hints.
> It might make sense to set the number of pages to be hinted at a time from the
> hypervisor.
>>
>> My primary testing has just been to verify the memory is being freed after
>> allocation by running memhog 79g on a 80g 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 at most a 2% difference between the base
>> kernel without these patches and the patches with virtio-balloon disabled.
>> With the patches and virtio-balloon enabled with hinting the results
>> largely depend on the host kernel. On a 3.10 RHEL kernel I saw up to a 2%
>> drop in performance as I approached 16 threads,
> I think this is acceptable.
>>  however on the the lastest
>> linux-next kernel I saw roughly a 4% to 5% improvement in performance for
>> all tests with 8 or more threads. 
> Do you mean that with your patches the will-it-scale/page_fault1 numbers were
> better by 4-5% over an unmodified kernel?
>> I believe the difference seen is due to
>> the overhead for faulting pages back into the guest and zeroing of memory.
> It may also make sense to test these patches with netperf to observe how much
> performance drop it is introducing.
>> Patch 4 is a bit on the large side at about 600 lines of change, however
>> I really didn't see a good way to break it up since each piece feeds into
>> the next. So I couldn't add the statistics by themselves as it didn't
>> really make sense to add them without something that will either read or
>> increment/decrement them, or add the Hinted state without something that
>> would set/unset it. As such I just ended up adding the entire thing as
>> one patch. It makes it a bit bigger but avoids the issues in the previous
>> set where I was referencing things before they had been added.
>>
>> Changes from the RFC:
>> https://lore.kernel.org/lkml/20190530215223.13974.22445.stgit@localhost.localdomain/
>> Moved aeration requested flag out of aerator and into zone->flags.
>> Moved bounary 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.
>>
>> Changes from v1:
>> https://lore.kernel.org/lkml/20190619222922.1231.27432.stgit@localhost.localdomain/
>> Dropped "waste page treatment" in favor of "page hinting"
> We may still have to try and find a better name for virtio-balloon side changes.
> As "FREE_PAGE_HINT" and "PAGE_HINTING" are still confusing.

We should have named that free page reporting, but that train already
has left.

-- 

Thanks,

David / dhildenb

Re: [PATCH v2 5/5] virtio-balloon: Add support for providing page hints to host

[Michael S. Tsirkin]

On Wed, Jul 24, 2019 at 10:05:14AM -0700, Alexander Duyck wrote:
> From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> 
> Add support for the page hinting feature provided by virtio-balloon.
> Hinting differs from the regular balloon functionality in that is is
> much less durable than a standard memory balloon. Instead of creating a
> list of pages that cannot be accessed the pages are only inaccessible
> while they are being indicated to the virtio interface. Once the
> interface has acknowledged them they are placed back into their respective
> free lists and are once again accessible by the guest system.
> 
> Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>

Looking at the design, it seems that hinted pages can immediately be
reused. I wonder how we can efficiently support this
with kvm when poisoning is in effect. Of course we can just
ignore the poison. However it seems cleaner to
1. verify page is poisoned with the correct value
2. fill the page with the correct value on fault

Requirement 2 requires some kind of madvise that
will save the poison e.g. in the VMA.

Not a blocker for sure ... 


> ---
>  drivers/virtio/Kconfig              |    1 +
>  drivers/virtio/virtio_balloon.c     |   47 +++++++++++++++++++++++++++++++++++
>  include/uapi/linux/virtio_balloon.h |    1 +
>  3 files changed, 49 insertions(+)
> 
> diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig
> index 078615cf2afc..d45556ae1f81 100644
> --- a/drivers/virtio/Kconfig
> +++ b/drivers/virtio/Kconfig
> @@ -58,6 +58,7 @@ config VIRTIO_BALLOON
>  	tristate "Virtio balloon driver"
>  	depends on VIRTIO
>  	select MEMORY_BALLOON
> +	select PAGE_HINTING
>  	---help---
>  	 This driver supports increasing and decreasing the amount
>  	 of memory within a KVM guest.
> diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
> index 226fbb995fb0..dee9f8f3ad09 100644
> --- a/drivers/virtio/virtio_balloon.c
> +++ b/drivers/virtio/virtio_balloon.c
> @@ -19,6 +19,7 @@
>  #include <linux/mount.h>
>  #include <linux/magic.h>
>  #include <linux/pseudo_fs.h>
> +#include <linux/page_hinting.h>
>  
>  /*
>   * Balloon device works in 4K page units.  So each page is pointed to by
> @@ -27,6 +28,7 @@
>   */
>  #define VIRTIO_BALLOON_PAGES_PER_PAGE (unsigned)(PAGE_SIZE >> VIRTIO_BALLOON_PFN_SHIFT)
>  #define VIRTIO_BALLOON_ARRAY_PFNS_MAX 256
> +#define VIRTIO_BALLOON_ARRAY_HINTS_MAX	32
>  #define VIRTBALLOON_OOM_NOTIFY_PRIORITY 80
>  
>  #define VIRTIO_BALLOON_FREE_PAGE_ALLOC_FLAG (__GFP_NORETRY | __GFP_NOWARN | \
> @@ -46,6 +48,7 @@ enum virtio_balloon_vq {
>  	VIRTIO_BALLOON_VQ_DEFLATE,
>  	VIRTIO_BALLOON_VQ_STATS,
>  	VIRTIO_BALLOON_VQ_FREE_PAGE,
> +	VIRTIO_BALLOON_VQ_HINTING,
>  	VIRTIO_BALLOON_VQ_MAX
>  };
>  
> @@ -113,6 +116,10 @@ struct virtio_balloon {
>  
>  	/* To register a shrinker to shrink memory upon memory pressure */
>  	struct shrinker shrinker;
> +
> +	/* Unused page hinting device */
> +	struct virtqueue *hinting_vq;
> +	struct page_hinting_dev_info ph_dev_info;
>  };
>  
>  static struct virtio_device_id id_table[] = {
> @@ -152,6 +159,22 @@ static void tell_host(struct virtio_balloon *vb, struct virtqueue *vq)
>  
>  }
>  
> +void virtballoon_page_hinting_react(struct page_hinting_dev_info *ph_dev_info,
> +				    unsigned int num_hints)
> +{
> +	struct virtio_balloon *vb =
> +		container_of(ph_dev_info, struct virtio_balloon, ph_dev_info);
> +	struct virtqueue *vq = vb->hinting_vq;
> +	unsigned int unused;
> +
> +	/* We should always be able to add these buffers to an empty queue. */


can be an out of memory condition, and then ...

> +	virtqueue_add_inbuf(vq, ph_dev_info->sg, num_hints, vb, GFP_KERNEL);
> +	virtqueue_kick(vq);

... this will block forever.

> +	/* When host has read buffer, this completes via balloon_ack */
> +	wait_event(vb->acked, virtqueue_get_buf(vq, &unused));

However below I suggest limiting capacity which will solve
this problem for you.



> +}
> +
>  static void set_page_pfns(struct virtio_balloon *vb,
>  			  __virtio32 pfns[], struct page *page)
>  {
> @@ -476,6 +499,7 @@ static int init_vqs(struct virtio_balloon *vb)
>  	names[VIRTIO_BALLOON_VQ_DEFLATE] = "deflate";
>  	names[VIRTIO_BALLOON_VQ_STATS] = NULL;
>  	names[VIRTIO_BALLOON_VQ_FREE_PAGE] = NULL;
> +	names[VIRTIO_BALLOON_VQ_HINTING] = NULL;
>  
>  	if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_STATS_VQ)) {
>  		names[VIRTIO_BALLOON_VQ_STATS] = "stats";
> @@ -487,11 +511,19 @@ static int init_vqs(struct virtio_balloon *vb)
>  		callbacks[VIRTIO_BALLOON_VQ_FREE_PAGE] = NULL;
>  	}
>  
> +	if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_HINTING)) {
> +		names[VIRTIO_BALLOON_VQ_HINTING] = "hinting_vq";
> +		callbacks[VIRTIO_BALLOON_VQ_HINTING] = balloon_ack;
> +	}
> +
>  	err = vb->vdev->config->find_vqs(vb->vdev, VIRTIO_BALLOON_VQ_MAX,
>  					 vqs, callbacks, names, NULL, NULL);
>  	if (err)
>  		return err;
>  
> +	if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_HINTING))
> +		vb->hinting_vq = vqs[VIRTIO_BALLOON_VQ_HINTING];
> +
>  	vb->inflate_vq = vqs[VIRTIO_BALLOON_VQ_INFLATE];
>  	vb->deflate_vq = vqs[VIRTIO_BALLOON_VQ_DEFLATE];
>  	if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_STATS_VQ)) {
> @@ -924,12 +956,24 @@ static int virtballoon_probe(struct virtio_device *vdev)
>  		if (err)
>  			goto out_del_balloon_wq;
>  	}
> +
> +	vb->ph_dev_info.react = virtballoon_page_hinting_react;
> +	vb->ph_dev_info.capacity = VIRTIO_BALLOON_ARRAY_HINTS_MAX;

As explained above I think you should limit this by vq size.
Otherwise virtqueue add buf might fail.
In fact by struct spec reading you need to limit it
anyway otherwise it will fail unconditionally.
In practice on most hypervisors it will typically work ...

> +	if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_HINTING)) {
> +		err = page_hinting_startup(&vb->ph_dev_info);
> +		if (err)
> +			goto out_unregister_shrinker;
> +	}
> +
>  	virtio_device_ready(vdev);
>  
>  	if (towards_target(vb))
>  		virtballoon_changed(vdev);
>  	return 0;
>  
> +out_unregister_shrinker:
> +	if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_DEFLATE_ON_OOM))
> +		virtio_balloon_unregister_shrinker(vb);
>  out_del_balloon_wq:
>  	if (virtio_has_feature(vdev, VIRTIO_BALLOON_F_FREE_PAGE_HINT))
>  		destroy_workqueue(vb->balloon_wq);
> @@ -958,6 +1002,8 @@ static void virtballoon_remove(struct virtio_device *vdev)
>  {
>  	struct virtio_balloon *vb = vdev->priv;
>  
> +	if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_HINTING))
> +		page_hinting_shutdown(&vb->ph_dev_info);
>  	if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_DEFLATE_ON_OOM))
>  		virtio_balloon_unregister_shrinker(vb);
>  	spin_lock_irq(&vb->stop_update_lock);
> @@ -1027,6 +1073,7 @@ static int virtballoon_validate(struct virtio_device *vdev)
>  	VIRTIO_BALLOON_F_DEFLATE_ON_OOM,
>  	VIRTIO_BALLOON_F_FREE_PAGE_HINT,
>  	VIRTIO_BALLOON_F_PAGE_POISON,
> +	VIRTIO_BALLOON_F_HINTING,
>  };
>  
>  static struct virtio_driver virtio_balloon_driver = {
> diff --git a/include/uapi/linux/virtio_balloon.h b/include/uapi/linux/virtio_balloon.h
> index a1966cd7b677..2b0f62814e22 100644
> --- a/include/uapi/linux/virtio_balloon.h
> +++ b/include/uapi/linux/virtio_balloon.h
> @@ -36,6 +36,7 @@
>  #define VIRTIO_BALLOON_F_DEFLATE_ON_OOM	2 /* Deflate balloon on OOM */
>  #define VIRTIO_BALLOON_F_FREE_PAGE_HINT	3 /* VQ to report free pages */
>  #define VIRTIO_BALLOON_F_PAGE_POISON	4 /* Guest is using page poisoning */
> +#define VIRTIO_BALLOON_F_HINTING	5 /* Page hinting virtqueue */
>  
>  /* Size of a PFN in the balloon interface. */
>  #define VIRTIO_BALLOON_PFN_SHIFT 12

Re: [PATCH v2 QEMU] virtio-balloon: Provide a interface for "bubble hinting"

[Michael S. Tsirkin]

On Wed, Jul 24, 2019 at 10:12:10AM -0700, Alexander Duyck wrote:
> From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> 
> Add support for what I am referring to as "bubble hinting". Basically the
> idea is to function very similar to how the balloon works in that we
> basically end up madvising the page as not being used. However we don't
> really need to bother with any deflate type logic since the page will be
> faulted back into the guest when it is read or written to.
> 
> This is meant to be a simplification of the existing balloon interface
> to use for providing hints to what memory needs to be freed. I am assuming
> this is safe to do as the deflate logic does not actually appear to do very
> much other than tracking what subpages have been released and which ones
> haven't.
> 
> Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> ---
>  hw/virtio/virtio-balloon.c                      |   40 +++++++++++++++++++++++
>  include/hw/virtio/virtio-balloon.h              |    2 +
>  include/standard-headers/linux/virtio_balloon.h |    1 +
>  3 files changed, 42 insertions(+), 1 deletion(-)
> 
> diff --git a/hw/virtio/virtio-balloon.c b/hw/virtio/virtio-balloon.c
> index 2112874055fb..70c0004c0f88 100644
> --- a/hw/virtio/virtio-balloon.c
> +++ b/hw/virtio/virtio-balloon.c
> @@ -328,6 +328,39 @@ static void balloon_stats_set_poll_interval(Object *obj, Visitor *v,
>      balloon_stats_change_timer(s, 0);
>  }
>  
> +static void virtio_bubble_handle_output(VirtIODevice *vdev, VirtQueue *vq)
> +{
> +    VirtQueueElement *elem;
> +
> +    while ((elem = virtqueue_pop(vq, sizeof(VirtQueueElement)))) {
> +    	unsigned int i;
> +
> +        for (i = 0; i < elem->in_num; i++) {
> +            void *addr = elem->in_sg[i].iov_base;
> +            size_t size = elem->in_sg[i].iov_len;
> +            ram_addr_t ram_offset;
> +            size_t rb_page_size;
> +            RAMBlock *rb;
> +
> +            if (qemu_balloon_is_inhibited())
> +                continue;
> +
> +            rb = qemu_ram_block_from_host(addr, false, &ram_offset);
> +            rb_page_size = qemu_ram_pagesize(rb);
> +
> +            /* For now we will simply ignore unaligned memory regions */
> +            if ((ram_offset | size) & (rb_page_size - 1))
> +                continue;
> +
> +            ram_block_discard_range(rb, ram_offset, size);

I suspect this needs to do like the migration type of
hinting and get disabled if page poisoning is in effect.
Right?

> +        }
> +
> +        virtqueue_push(vq, elem, 0);
> +        virtio_notify(vdev, vq);
> +        g_free(elem);
> +    }
> +}
> +
>  static void virtio_balloon_handle_output(VirtIODevice *vdev, VirtQueue *vq)
>  {
>      VirtIOBalloon *s = VIRTIO_BALLOON(vdev);
> @@ -782,6 +815,11 @@ static void virtio_balloon_device_realize(DeviceState *dev, Error **errp)
>      s->svq = virtio_add_queue(vdev, 128, virtio_balloon_receive_stats);
>  
>      if (virtio_has_feature(s->host_features,
> +                           VIRTIO_BALLOON_F_HINTING)) {
> +        s->hvq = virtio_add_queue(vdev, 128, virtio_bubble_handle_output);
> +    }
> +
> +    if (virtio_has_feature(s->host_features,
>                             VIRTIO_BALLOON_F_FREE_PAGE_HINT)) {
>          s->free_page_vq = virtio_add_queue(vdev, VIRTQUEUE_MAX_SIZE,
>                                             virtio_balloon_handle_free_page_vq);
> @@ -897,6 +935,8 @@ static Property virtio_balloon_properties[] = {
>                      VIRTIO_BALLOON_F_DEFLATE_ON_OOM, false),
>      DEFINE_PROP_BIT("free-page-hint", VirtIOBalloon, host_features,
>                      VIRTIO_BALLOON_F_FREE_PAGE_HINT, false),
> +    DEFINE_PROP_BIT("guest-page-hinting", VirtIOBalloon, host_features,
> +                    VIRTIO_BALLOON_F_HINTING, true),
>      DEFINE_PROP_LINK("iothread", VirtIOBalloon, iothread, TYPE_IOTHREAD,
>                       IOThread *),
>      DEFINE_PROP_END_OF_LIST(),
> diff --git a/include/hw/virtio/virtio-balloon.h b/include/hw/virtio/virtio-balloon.h
> index 1afafb12f6bc..a58b24fdf29d 100644
> --- a/include/hw/virtio/virtio-balloon.h
> +++ b/include/hw/virtio/virtio-balloon.h
> @@ -44,7 +44,7 @@ enum virtio_balloon_free_page_report_status {
>  
>  typedef struct VirtIOBalloon {
>      VirtIODevice parent_obj;
> -    VirtQueue *ivq, *dvq, *svq, *free_page_vq;
> +    VirtQueue *ivq, *dvq, *svq, *free_page_vq, *hvq;
>      uint32_t free_page_report_status;
>      uint32_t num_pages;
>      uint32_t actual;
> diff --git a/include/standard-headers/linux/virtio_balloon.h b/include/standard-headers/linux/virtio_balloon.h
> index 9375ca2a70de..f9e3e8256261 100644
> --- a/include/standard-headers/linux/virtio_balloon.h
> +++ b/include/standard-headers/linux/virtio_balloon.h
> @@ -36,6 +36,7 @@
>  #define VIRTIO_BALLOON_F_DEFLATE_ON_OOM	2 /* Deflate balloon on OOM */
>  #define VIRTIO_BALLOON_F_FREE_PAGE_HINT	3 /* VQ to report free pages */
>  #define VIRTIO_BALLOON_F_PAGE_POISON	4 /* Guest is using page poisoning */
> +#define VIRTIO_BALLOON_F_HINTING	5 /* Page hinting virtqueue */
>  
>  /* Size of a PFN in the balloon interface. */
>  #define VIRTIO_BALLOON_PFN_SHIFT 12

Re: [PATCH v2 5/5] virtio-balloon: Add support for providing page hints to host

[Nitesh Narayan Lal]

On 7/24/19 3:02 PM, Michael S. Tsirkin wrote:
> On Wed, Jul 24, 2019 at 10:05:14AM -0700, Alexander Duyck wrote:
>> From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
>>
>> Add support for the page hinting feature provided by virtio-balloon.
>> Hinting differs from the regular balloon functionality in that is is
>> much less durable than a standard memory balloon. Instead of creating a
>> list of pages that cannot be accessed the pages are only inaccessible
>> while they are being indicated to the virtio interface. Once the
>> interface has acknowledged them they are placed back into their respective
>> free lists and are once again accessible by the guest system.
>>
>> Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> Looking at the design, it seems that hinted pages can immediately be
> reused. I wonder how we can efficiently support this
> with kvm when poisoning is in effect. Of course we can just
> ignore the poison. However it seems cleaner to
> 1. verify page is poisoned with the correct value
> 2. fill the page with the correct value on fault
Once VIRTIO_BALLOON_F_PAGE_POISON user side support is available.
Can't we just use that at the time of initialization?
> Requirement 2 requires some kind of madvise that
> will save the poison e.g. in the VMA.
>
> Not a blocker for sure ... 
>
>
>> ---
>>  drivers/virtio/Kconfig              |    1 +
>>  drivers/virtio/virtio_balloon.c     |   47 +++++++++++++++++++++++++++++++++++
>>  include/uapi/linux/virtio_balloon.h |    1 +
>>  3 files changed, 49 insertions(+)
>>
>> diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig
>> index 078615cf2afc..d45556ae1f81 100644
>> --- a/drivers/virtio/Kconfig
>> +++ b/drivers/virtio/Kconfig
>> @@ -58,6 +58,7 @@ config VIRTIO_BALLOON
>>  	tristate "Virtio balloon driver"
>>  	depends on VIRTIO
>>  	select MEMORY_BALLOON
>> +	select PAGE_HINTING
>>  	---help---
>>  	 This driver supports increasing and decreasing the amount
>>  	 of memory within a KVM guest.
>> diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
>> index 226fbb995fb0..dee9f8f3ad09 100644
>> --- a/drivers/virtio/virtio_balloon.c
>> +++ b/drivers/virtio/virtio_balloon.c
>> @@ -19,6 +19,7 @@
>>  #include <linux/mount.h>
>>  #include <linux/magic.h>
>>  #include <linux/pseudo_fs.h>
>> +#include <linux/page_hinting.h>
>>  
>>  /*
>>   * Balloon device works in 4K page units.  So each page is pointed to by
>> @@ -27,6 +28,7 @@
>>   */
>>  #define VIRTIO_BALLOON_PAGES_PER_PAGE (unsigned)(PAGE_SIZE >> VIRTIO_BALLOON_PFN_SHIFT)
>>  #define VIRTIO_BALLOON_ARRAY_PFNS_MAX 256
>> +#define VIRTIO_BALLOON_ARRAY_HINTS_MAX	32
>>  #define VIRTBALLOON_OOM_NOTIFY_PRIORITY 80
>>  
>>  #define VIRTIO_BALLOON_FREE_PAGE_ALLOC_FLAG (__GFP_NORETRY | __GFP_NOWARN | \
>> @@ -46,6 +48,7 @@ enum virtio_balloon_vq {
>>  	VIRTIO_BALLOON_VQ_DEFLATE,
>>  	VIRTIO_BALLOON_VQ_STATS,
>>  	VIRTIO_BALLOON_VQ_FREE_PAGE,
>> +	VIRTIO_BALLOON_VQ_HINTING,
>>  	VIRTIO_BALLOON_VQ_MAX
>>  };
>>  
>> @@ -113,6 +116,10 @@ struct virtio_balloon {
>>  
>>  	/* To register a shrinker to shrink memory upon memory pressure */
>>  	struct shrinker shrinker;
>> +
>> +	/* Unused page hinting device */
>> +	struct virtqueue *hinting_vq;
>> +	struct page_hinting_dev_info ph_dev_info;
>>  };
>>  
>>  static struct virtio_device_id id_table[] = {
>> @@ -152,6 +159,22 @@ static void tell_host(struct virtio_balloon *vb, struct virtqueue *vq)
>>  
>>  }
>>  
>> +void virtballoon_page_hinting_react(struct page_hinting_dev_info *ph_dev_info,
>> +				    unsigned int num_hints)
>> +{
>> +	struct virtio_balloon *vb =
>> +		container_of(ph_dev_info, struct virtio_balloon, ph_dev_info);
>> +	struct virtqueue *vq = vb->hinting_vq;
>> +	unsigned int unused;
>> +
>> +	/* We should always be able to add these buffers to an empty queue. */
>
> can be an out of memory condition, and then ...
>
>> +	virtqueue_add_inbuf(vq, ph_dev_info->sg, num_hints, vb, GFP_KERNEL);
>> +	virtqueue_kick(vq);
> ... this will block forever.
>
>> +	/* When host has read buffer, this completes via balloon_ack */
>> +	wait_event(vb->acked, virtqueue_get_buf(vq, &unused));
> However below I suggest limiting capacity which will solve
> this problem for you.
>
>
>
>> +}
>> +
>>  static void set_page_pfns(struct virtio_balloon *vb,
>>  			  __virtio32 pfns[], struct page *page)
>>  {
>> @@ -476,6 +499,7 @@ static int init_vqs(struct virtio_balloon *vb)
>>  	names[VIRTIO_BALLOON_VQ_DEFLATE] = "deflate";
>>  	names[VIRTIO_BALLOON_VQ_STATS] = NULL;
>>  	names[VIRTIO_BALLOON_VQ_FREE_PAGE] = NULL;
>> +	names[VIRTIO_BALLOON_VQ_HINTING] = NULL;
>>  
>>  	if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_STATS_VQ)) {
>>  		names[VIRTIO_BALLOON_VQ_STATS] = "stats";
>> @@ -487,11 +511,19 @@ static int init_vqs(struct virtio_balloon *vb)
>>  		callbacks[VIRTIO_BALLOON_VQ_FREE_PAGE] = NULL;
>>  	}
>>  
>> +	if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_HINTING)) {
>> +		names[VIRTIO_BALLOON_VQ_HINTING] = "hinting_vq";
>> +		callbacks[VIRTIO_BALLOON_VQ_HINTING] = balloon_ack;
>> +	}
>> +
>>  	err = vb->vdev->config->find_vqs(vb->vdev, VIRTIO_BALLOON_VQ_MAX,
>>  					 vqs, callbacks, names, NULL, NULL);
>>  	if (err)
>>  		return err;
>>  
>> +	if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_HINTING))
>> +		vb->hinting_vq = vqs[VIRTIO_BALLOON_VQ_HINTING];
>> +
>>  	vb->inflate_vq = vqs[VIRTIO_BALLOON_VQ_INFLATE];
>>  	vb->deflate_vq = vqs[VIRTIO_BALLOON_VQ_DEFLATE];
>>  	if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_STATS_VQ)) {
>> @@ -924,12 +956,24 @@ static int virtballoon_probe(struct virtio_device *vdev)
>>  		if (err)
>>  			goto out_del_balloon_wq;
>>  	}
>> +
>> +	vb->ph_dev_info.react = virtballoon_page_hinting_react;
>> +	vb->ph_dev_info.capacity = VIRTIO_BALLOON_ARRAY_HINTS_MAX;
> As explained above I think you should limit this by vq size.
> Otherwise virtqueue add buf might fail.
> In fact by struct spec reading you need to limit it
> anyway otherwise it will fail unconditionally.
> In practice on most hypervisors it will typically work ...
>
>> +	if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_HINTING)) {
>> +		err = page_hinting_startup(&vb->ph_dev_info);
>> +		if (err)
>> +			goto out_unregister_shrinker;
>> +	}
>> +
>>  	virtio_device_ready(vdev);
>>  
>>  	if (towards_target(vb))
>>  		virtballoon_changed(vdev);
>>  	return 0;
>>  
>> +out_unregister_shrinker:
>> +	if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_DEFLATE_ON_OOM))
>> +		virtio_balloon_unregister_shrinker(vb);
>>  out_del_balloon_wq:
>>  	if (virtio_has_feature(vdev, VIRTIO_BALLOON_F_FREE_PAGE_HINT))
>>  		destroy_workqueue(vb->balloon_wq);
>> @@ -958,6 +1002,8 @@ static void virtballoon_remove(struct virtio_device *vdev)
>>  {
>>  	struct virtio_balloon *vb = vdev->priv;
>>  
>> +	if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_HINTING))
>> +		page_hinting_shutdown(&vb->ph_dev_info);
>>  	if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_DEFLATE_ON_OOM))
>>  		virtio_balloon_unregister_shrinker(vb);
>>  	spin_lock_irq(&vb->stop_update_lock);
>> @@ -1027,6 +1073,7 @@ static int virtballoon_validate(struct virtio_device *vdev)
>>  	VIRTIO_BALLOON_F_DEFLATE_ON_OOM,
>>  	VIRTIO_BALLOON_F_FREE_PAGE_HINT,
>>  	VIRTIO_BALLOON_F_PAGE_POISON,
>> +	VIRTIO_BALLOON_F_HINTING,
>>  };
>>  
>>  static struct virtio_driver virtio_balloon_driver = {
>> diff --git a/include/uapi/linux/virtio_balloon.h b/include/uapi/linux/virtio_balloon.h
>> index a1966cd7b677..2b0f62814e22 100644
>> --- a/include/uapi/linux/virtio_balloon.h
>> +++ b/include/uapi/linux/virtio_balloon.h
>> @@ -36,6 +36,7 @@
>>  #define VIRTIO_BALLOON_F_DEFLATE_ON_OOM	2 /* Deflate balloon on OOM */
>>  #define VIRTIO_BALLOON_F_FREE_PAGE_HINT	3 /* VQ to report free pages */
>>  #define VIRTIO_BALLOON_F_PAGE_POISON	4 /* Guest is using page poisoning */
>> +#define VIRTIO_BALLOON_F_HINTING	5 /* Page hinting virtqueue */
>>  
>>  /* Size of a PFN in the balloon interface. */
>>  #define VIRTIO_BALLOON_PFN_SHIFT 12
-- 
Thanks
Nitesh

Re: [PATCH v2 0/5] mm / virtio: Provide support for page hinting

[Michael S. Tsirkin]

On Wed, Jul 24, 2019 at 02:40:02PM -0400, Nitesh Narayan Lal wrote:
> 
> On 7/24/19 12:54 PM, 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 page hinting
> >
> > The functionality for this is fairly simple. When enabled it will allocate
> > statistics to track the number of hinted pages in a given free area. When
> > the number of free pages exceeds this value plus a high water value,
> > currently 32,
> Shouldn't we configure this to a lower number such as 16?
> >  it will begin performing page hinting which consists of
> > pulling pages off of free list and placing them into a scatter list. The
> > scatterlist is then given to the page hinting device and it will perform
> > the required action to make the pages "hinted", in the case of
> > virtio-balloon this results in the pages being madvised as MADV_DONTNEED
> > and as such they are forced out of the guest. After this they are placed
> > back on the free list, and an additional bit is added if they are not
> > merged indicating that they are a hinted buddy page instead of a standard
> > buddy page. The cycle then repeats with additional non-hinted pages being
> > pulled until the free areas all consist of hinted pages.
> >
> > I am leaving a number of things hard-coded such as limiting the lowest
> > order processed to PAGEBLOCK_ORDER,
> Have you considered making this option configurable at the compile time?
> >  and have left it up to the guest to
> > determine what the limit is on how many pages it wants to allocate to
> > process the hints.
> It might make sense to set the number of pages to be hinted at a time from the
> hypervisor.
> >
> > My primary testing has just been to verify the memory is being freed after
> > allocation by running memhog 79g on a 80g 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 at most a 2% difference between the base
> > kernel without these patches and the patches with virtio-balloon disabled.
> > With the patches and virtio-balloon enabled with hinting the results
> > largely depend on the host kernel. On a 3.10 RHEL kernel I saw up to a 2%
> > drop in performance as I approached 16 threads,
> I think this is acceptable.
> >  however on the the lastest
> > linux-next kernel I saw roughly a 4% to 5% improvement in performance for
> > all tests with 8 or more threads. 
> Do you mean that with your patches the will-it-scale/page_fault1 numbers were
> better by 4-5% over an unmodified kernel?
> > I believe the difference seen is due to
> > the overhead for faulting pages back into the guest and zeroing of memory.
> It may also make sense to test these patches with netperf to observe how much
> performance drop it is introducing.
> > Patch 4 is a bit on the large side at about 600 lines of change, however
> > I really didn't see a good way to break it up since each piece feeds into
> > the next. So I couldn't add the statistics by themselves as it didn't
> > really make sense to add them without something that will either read or
> > increment/decrement them, or add the Hinted state without something that
> > would set/unset it. As such I just ended up adding the entire thing as
> > one patch. It makes it a bit bigger but avoids the issues in the previous
> > set where I was referencing things before they had been added.
> >
> > Changes from the RFC:
> > https://lore.kernel.org/lkml/20190530215223.13974.22445.stgit@localhost.localdomain/
> > Moved aeration requested flag out of aerator and into zone->flags.
> > Moved bounary 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.
> >
> > Changes from v1:
> > https://lore.kernel.org/lkml/20190619222922.1231.27432.stgit@localhost.localdomain/
> > Dropped "waste page treatment" in favor of "page hinting"
> We may still have to try and find a better name for virtio-balloon side changes.
> As "FREE_PAGE_HINT" and "PAGE_HINTING" are still confusing.

Right. In fact I'm not sure why should these be called hints at all.
VIRTIO_BALLOON_F_FREE_PAGE_HINT is a hint because pages might no
longer be free by the time they are reported.

I think of this one as a free page reporting capability.
I don't really mind how are internal kernel functions called,
but I think for virtio uapi things that's a better name.




> > Renamed files and functions from "aeration" to "page_hinting"
> > Moved from page->lru list to scatterlist
> > Replaced wait on refcnt in shutdown with RCU and cancel_delayed_work_sync
> > Virtio now uses scatterlist directly instead of intermedate array
> > Moved stats out of free_area, now in seperate area and pointed to from zone
> > Merged patch 5 into patch 4 to improve reviewability
> > Updated various code comments throughout
> >
> > ---
> >
> > Alexander Duyck (5):
> >       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 Hinted pages
> >       virtio-balloon: Add support for providing page hints to host
> >
> >
> >  drivers/virtio/Kconfig              |    1 
> >  drivers/virtio/virtio_balloon.c     |   47 ++++++
> >  include/linux/mmzone.h              |  116 ++++++++------
> >  include/linux/page-flags.h          |    8 +
> >  include/linux/page_hinting.h        |  139 ++++++++++++++++
> >  include/uapi/linux/virtio_balloon.h |    1 
> >  mm/Kconfig                          |    5 +
> >  mm/Makefile                         |    1 
> >  mm/internal.h                       |   18 ++
> >  mm/memory_hotplug.c                 |    1 
> >  mm/page_alloc.c                     |  238 ++++++++++++++++++++--------
> >  mm/page_hinting.c                   |  298 +++++++++++++++++++++++++++++++++++
> >  mm/shuffle.c                        |   24 ---
> >  mm/shuffle.h                        |   32 ++++
> >  14 files changed, 796 insertions(+), 133 deletions(-)
> >  create mode 100644 include/linux/page_hinting.h
> >  create mode 100644 mm/page_hinting.c
> >
> > --
> -- 
> Thanks
> Nitesh

Re: [PATCH v2 5/5] virtio-balloon: Add support for providing page hints to host

[Michael S. Tsirkin]

On Wed, Jul 24, 2019 at 03:07:42PM -0400, Nitesh Narayan Lal wrote:
> 
> On 7/24/19 3:02 PM, Michael S. Tsirkin wrote:
> > On Wed, Jul 24, 2019 at 10:05:14AM -0700, Alexander Duyck wrote:
> >> From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> >>
> >> Add support for the page hinting feature provided by virtio-balloon.
> >> Hinting differs from the regular balloon functionality in that is is
> >> much less durable than a standard memory balloon. Instead of creating a
> >> list of pages that cannot be accessed the pages are only inaccessible
> >> while they are being indicated to the virtio interface. Once the
> >> interface has acknowledged them they are placed back into their respective
> >> free lists and are once again accessible by the guest system.
> >>
> >> Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> > Looking at the design, it seems that hinted pages can immediately be
> > reused. I wonder how we can efficiently support this
> > with kvm when poisoning is in effect. Of course we can just
> > ignore the poison. However it seems cleaner to
> > 1. verify page is poisoned with the correct value
> > 2. fill the page with the correct value on fault
> Once VIRTIO_BALLOON_F_PAGE_POISON user side support is available.
> Can't we just use that at the time of initialization?

ATM VIRTIO_BALLOON_F_PAGE_POISON simply avoids freeing the pages at the
moment.

1+2 above are exactly a way to implement VIRTIO_BALLOON_F_PAGE_POISON
such that will still bring performance gains.

> > Requirement 2 requires some kind of madvise that
> > will save the poison e.g. in the VMA.
> >
> > Not a blocker for sure ... 
> >
> >
> >> ---
> >>  drivers/virtio/Kconfig              |    1 +
> >>  drivers/virtio/virtio_balloon.c     |   47 +++++++++++++++++++++++++++++++++++
> >>  include/uapi/linux/virtio_balloon.h |    1 +
> >>  3 files changed, 49 insertions(+)
> >>
> >> diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig
> >> index 078615cf2afc..d45556ae1f81 100644
> >> --- a/drivers/virtio/Kconfig
> >> +++ b/drivers/virtio/Kconfig
> >> @@ -58,6 +58,7 @@ config VIRTIO_BALLOON
> >>  	tristate "Virtio balloon driver"
> >>  	depends on VIRTIO
> >>  	select MEMORY_BALLOON
> >> +	select PAGE_HINTING
> >>  	---help---
> >>  	 This driver supports increasing and decreasing the amount
> >>  	 of memory within a KVM guest.
> >> diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
> >> index 226fbb995fb0..dee9f8f3ad09 100644
> >> --- a/drivers/virtio/virtio_balloon.c
> >> +++ b/drivers/virtio/virtio_balloon.c
> >> @@ -19,6 +19,7 @@
> >>  #include <linux/mount.h>
> >>  #include <linux/magic.h>
> >>  #include <linux/pseudo_fs.h>
> >> +#include <linux/page_hinting.h>
> >>  
> >>  /*
> >>   * Balloon device works in 4K page units.  So each page is pointed to by
> >> @@ -27,6 +28,7 @@
> >>   */
> >>  #define VIRTIO_BALLOON_PAGES_PER_PAGE (unsigned)(PAGE_SIZE >> VIRTIO_BALLOON_PFN_SHIFT)
> >>  #define VIRTIO_BALLOON_ARRAY_PFNS_MAX 256
> >> +#define VIRTIO_BALLOON_ARRAY_HINTS_MAX	32
> >>  #define VIRTBALLOON_OOM_NOTIFY_PRIORITY 80
> >>  
> >>  #define VIRTIO_BALLOON_FREE_PAGE_ALLOC_FLAG (__GFP_NORETRY | __GFP_NOWARN | \
> >> @@ -46,6 +48,7 @@ enum virtio_balloon_vq {
> >>  	VIRTIO_BALLOON_VQ_DEFLATE,
> >>  	VIRTIO_BALLOON_VQ_STATS,
> >>  	VIRTIO_BALLOON_VQ_FREE_PAGE,
> >> +	VIRTIO_BALLOON_VQ_HINTING,
> >>  	VIRTIO_BALLOON_VQ_MAX
> >>  };
> >>  
> >> @@ -113,6 +116,10 @@ struct virtio_balloon {
> >>  
> >>  	/* To register a shrinker to shrink memory upon memory pressure */
> >>  	struct shrinker shrinker;
> >> +
> >> +	/* Unused page hinting device */
> >> +	struct virtqueue *hinting_vq;
> >> +	struct page_hinting_dev_info ph_dev_info;
> >>  };
> >>  
> >>  static struct virtio_device_id id_table[] = {
> >> @@ -152,6 +159,22 @@ static void tell_host(struct virtio_balloon *vb, struct virtqueue *vq)
> >>  
> >>  }
> >>  
> >> +void virtballoon_page_hinting_react(struct page_hinting_dev_info *ph_dev_info,
> >> +				    unsigned int num_hints)
> >> +{
> >> +	struct virtio_balloon *vb =
> >> +		container_of(ph_dev_info, struct virtio_balloon, ph_dev_info);
> >> +	struct virtqueue *vq = vb->hinting_vq;
> >> +	unsigned int unused;
> >> +
> >> +	/* We should always be able to add these buffers to an empty queue. */
> >
> > can be an out of memory condition, and then ...
> >
> >> +	virtqueue_add_inbuf(vq, ph_dev_info->sg, num_hints, vb, GFP_KERNEL);
> >> +	virtqueue_kick(vq);
> > ... this will block forever.
> >
> >> +	/* When host has read buffer, this completes via balloon_ack */
> >> +	wait_event(vb->acked, virtqueue_get_buf(vq, &unused));
> > However below I suggest limiting capacity which will solve
> > this problem for you.
> >
> >
> >
> >> +}
> >> +
> >>  static void set_page_pfns(struct virtio_balloon *vb,
> >>  			  __virtio32 pfns[], struct page *page)
> >>  {
> >> @@ -476,6 +499,7 @@ static int init_vqs(struct virtio_balloon *vb)
> >>  	names[VIRTIO_BALLOON_VQ_DEFLATE] = "deflate";
> >>  	names[VIRTIO_BALLOON_VQ_STATS] = NULL;
> >>  	names[VIRTIO_BALLOON_VQ_FREE_PAGE] = NULL;
> >> +	names[VIRTIO_BALLOON_VQ_HINTING] = NULL;
> >>  
> >>  	if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_STATS_VQ)) {
> >>  		names[VIRTIO_BALLOON_VQ_STATS] = "stats";
> >> @@ -487,11 +511,19 @@ static int init_vqs(struct virtio_balloon *vb)
> >>  		callbacks[VIRTIO_BALLOON_VQ_FREE_PAGE] = NULL;
> >>  	}
> >>  
> >> +	if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_HINTING)) {
> >> +		names[VIRTIO_BALLOON_VQ_HINTING] = "hinting_vq";
> >> +		callbacks[VIRTIO_BALLOON_VQ_HINTING] = balloon_ack;
> >> +	}
> >> +
> >>  	err = vb->vdev->config->find_vqs(vb->vdev, VIRTIO_BALLOON_VQ_MAX,
> >>  					 vqs, callbacks, names, NULL, NULL);
> >>  	if (err)
> >>  		return err;
> >>  
> >> +	if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_HINTING))
> >> +		vb->hinting_vq = vqs[VIRTIO_BALLOON_VQ_HINTING];
> >> +
> >>  	vb->inflate_vq = vqs[VIRTIO_BALLOON_VQ_INFLATE];
> >>  	vb->deflate_vq = vqs[VIRTIO_BALLOON_VQ_DEFLATE];
> >>  	if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_STATS_VQ)) {
> >> @@ -924,12 +956,24 @@ static int virtballoon_probe(struct virtio_device *vdev)
> >>  		if (err)
> >>  			goto out_del_balloon_wq;
> >>  	}
> >> +
> >> +	vb->ph_dev_info.react = virtballoon_page_hinting_react;
> >> +	vb->ph_dev_info.capacity = VIRTIO_BALLOON_ARRAY_HINTS_MAX;
> > As explained above I think you should limit this by vq size.
> > Otherwise virtqueue add buf might fail.
> > In fact by struct spec reading you need to limit it
> > anyway otherwise it will fail unconditionally.
> > In practice on most hypervisors it will typically work ...
> >
> >> +	if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_HINTING)) {
> >> +		err = page_hinting_startup(&vb->ph_dev_info);
> >> +		if (err)
> >> +			goto out_unregister_shrinker;
> >> +	}
> >> +
> >>  	virtio_device_ready(vdev);
> >>  
> >>  	if (towards_target(vb))
> >>  		virtballoon_changed(vdev);
> >>  	return 0;
> >>  
> >> +out_unregister_shrinker:
> >> +	if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_DEFLATE_ON_OOM))
> >> +		virtio_balloon_unregister_shrinker(vb);
> >>  out_del_balloon_wq:
> >>  	if (virtio_has_feature(vdev, VIRTIO_BALLOON_F_FREE_PAGE_HINT))
> >>  		destroy_workqueue(vb->balloon_wq);
> >> @@ -958,6 +1002,8 @@ static void virtballoon_remove(struct virtio_device *vdev)
> >>  {
> >>  	struct virtio_balloon *vb = vdev->priv;
> >>  
> >> +	if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_HINTING))
> >> +		page_hinting_shutdown(&vb->ph_dev_info);
> >>  	if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_DEFLATE_ON_OOM))
> >>  		virtio_balloon_unregister_shrinker(vb);
> >>  	spin_lock_irq(&vb->stop_update_lock);
> >> @@ -1027,6 +1073,7 @@ static int virtballoon_validate(struct virtio_device *vdev)
> >>  	VIRTIO_BALLOON_F_DEFLATE_ON_OOM,
> >>  	VIRTIO_BALLOON_F_FREE_PAGE_HINT,
> >>  	VIRTIO_BALLOON_F_PAGE_POISON,
> >> +	VIRTIO_BALLOON_F_HINTING,
> >>  };
> >>  
> >>  static struct virtio_driver virtio_balloon_driver = {
> >> diff --git a/include/uapi/linux/virtio_balloon.h b/include/uapi/linux/virtio_balloon.h
> >> index a1966cd7b677..2b0f62814e22 100644
> >> --- a/include/uapi/linux/virtio_balloon.h
> >> +++ b/include/uapi/linux/virtio_balloon.h
> >> @@ -36,6 +36,7 @@
> >>  #define VIRTIO_BALLOON_F_DEFLATE_ON_OOM	2 /* Deflate balloon on OOM */
> >>  #define VIRTIO_BALLOON_F_FREE_PAGE_HINT	3 /* VQ to report free pages */
> >>  #define VIRTIO_BALLOON_F_PAGE_POISON	4 /* Guest is using page poisoning */
> >> +#define VIRTIO_BALLOON_F_HINTING	5 /* Page hinting virtqueue */
> >>  
> >>  /* Size of a PFN in the balloon interface. */
> >>  #define VIRTIO_BALLOON_PFN_SHIFT 12
> -- 
> Thanks
> Nitesh

Re: [PATCH v2 0/5] mm / virtio: Provide support for page hinting

[Michael S. Tsirkin]

On Wed, Jul 24, 2019 at 08:41:33PM +0200, David Hildenbrand wrote:
> On 24.07.19 20:40, Nitesh Narayan Lal wrote:
> > 
> > On 7/24/19 12:54 PM, 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 page hinting
> >>
> >> The functionality for this is fairly simple. When enabled it will allocate
> >> statistics to track the number of hinted pages in a given free area. When
> >> the number of free pages exceeds this value plus a high water value,
> >> currently 32,
> > Shouldn't we configure this to a lower number such as 16?
> >>  it will begin performing page hinting which consists of
> >> pulling pages off of free list and placing them into a scatter list. The
> >> scatterlist is then given to the page hinting device and it will perform
> >> the required action to make the pages "hinted", in the case of
> >> virtio-balloon this results in the pages being madvised as MADV_DONTNEED
> >> and as such they are forced out of the guest. After this they are placed
> >> back on the free list, and an additional bit is added if they are not
> >> merged indicating that they are a hinted buddy page instead of a standard
> >> buddy page. The cycle then repeats with additional non-hinted pages being
> >> pulled until the free areas all consist of hinted pages.
> >>
> >> I am leaving a number of things hard-coded such as limiting the lowest
> >> order processed to PAGEBLOCK_ORDER,
> > Have you considered making this option configurable at the compile time?
> >>  and have left it up to the guest to
> >> determine what the limit is on how many pages it wants to allocate to
> >> process the hints.
> > It might make sense to set the number of pages to be hinted at a time from the
> > hypervisor.
> >>
> >> My primary testing has just been to verify the memory is being freed after
> >> allocation by running memhog 79g on a 80g 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 at most a 2% difference between the base
> >> kernel without these patches and the patches with virtio-balloon disabled.
> >> With the patches and virtio-balloon enabled with hinting the results
> >> largely depend on the host kernel. On a 3.10 RHEL kernel I saw up to a 2%
> >> drop in performance as I approached 16 threads,
> > I think this is acceptable.
> >>  however on the the lastest
> >> linux-next kernel I saw roughly a 4% to 5% improvement in performance for
> >> all tests with 8 or more threads. 
> > Do you mean that with your patches the will-it-scale/page_fault1 numbers were
> > better by 4-5% over an unmodified kernel?
> >> I believe the difference seen is due to
> >> the overhead for faulting pages back into the guest and zeroing of memory.
> > It may also make sense to test these patches with netperf to observe how much
> > performance drop it is introducing.
> >> Patch 4 is a bit on the large side at about 600 lines of change, however
> >> I really didn't see a good way to break it up since each piece feeds into
> >> the next. So I couldn't add the statistics by themselves as it didn't
> >> really make sense to add them without something that will either read or
> >> increment/decrement them, or add the Hinted state without something that
> >> would set/unset it. As such I just ended up adding the entire thing as
> >> one patch. It makes it a bit bigger but avoids the issues in the previous
> >> set where I was referencing things before they had been added.
> >>
> >> Changes from the RFC:
> >> https://lore.kernel.org/lkml/20190530215223.13974.22445.stgit@localhost.localdomain/
> >> Moved aeration requested flag out of aerator and into zone->flags.
> >> Moved bounary 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.
> >>
> >> Changes from v1:
> >> https://lore.kernel.org/lkml/20190619222922.1231.27432.stgit@localhost.localdomain/
> >> Dropped "waste page treatment" in favor of "page hinting"
> > We may still have to try and find a better name for virtio-balloon side changes.
> > As "FREE_PAGE_HINT" and "PAGE_HINTING" are still confusing.
> 
> We should have named that free page reporting, but that train already
> has left.

I think VIRTIO_BALLOON_F_FREE_PAGE_HINT is different and arguably
actually does provide hints.

> -- 
> 
> Thanks,
> 
> David / dhildenb

Re: [PATCH v2 0/5] mm / virtio: Provide support for page hinting

[David Hildenbrand]

On 24.07.19 21:31, Michael S. Tsirkin wrote:
> On Wed, Jul 24, 2019 at 08:41:33PM +0200, David Hildenbrand wrote:
>> On 24.07.19 20:40, Nitesh Narayan Lal wrote:
>>>
>>> On 7/24/19 12:54 PM, 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 page hinting
>>>>
>>>> The functionality for this is fairly simple. When enabled it will allocate
>>>> statistics to track the number of hinted pages in a given free area. When
>>>> the number of free pages exceeds this value plus a high water value,
>>>> currently 32,
>>> Shouldn't we configure this to a lower number such as 16?
>>>>  it will begin performing page hinting which consists of
>>>> pulling pages off of free list and placing them into a scatter list. The
>>>> scatterlist is then given to the page hinting device and it will perform
>>>> the required action to make the pages "hinted", in the case of
>>>> virtio-balloon this results in the pages being madvised as MADV_DONTNEED
>>>> and as such they are forced out of the guest. After this they are placed
>>>> back on the free list, and an additional bit is added if they are not
>>>> merged indicating that they are a hinted buddy page instead of a standard
>>>> buddy page. The cycle then repeats with additional non-hinted pages being
>>>> pulled until the free areas all consist of hinted pages.
>>>>
>>>> I am leaving a number of things hard-coded such as limiting the lowest
>>>> order processed to PAGEBLOCK_ORDER,
>>> Have you considered making this option configurable at the compile time?
>>>>  and have left it up to the guest to
>>>> determine what the limit is on how many pages it wants to allocate to
>>>> process the hints.
>>> It might make sense to set the number of pages to be hinted at a time from the
>>> hypervisor.
>>>>
>>>> My primary testing has just been to verify the memory is being freed after
>>>> allocation by running memhog 79g on a 80g 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 at most a 2% difference between the base
>>>> kernel without these patches and the patches with virtio-balloon disabled.
>>>> With the patches and virtio-balloon enabled with hinting the results
>>>> largely depend on the host kernel. On a 3.10 RHEL kernel I saw up to a 2%
>>>> drop in performance as I approached 16 threads,
>>> I think this is acceptable.
>>>>  however on the the lastest
>>>> linux-next kernel I saw roughly a 4% to 5% improvement in performance for
>>>> all tests with 8 or more threads. 
>>> Do you mean that with your patches the will-it-scale/page_fault1 numbers were
>>> better by 4-5% over an unmodified kernel?
>>>> I believe the difference seen is due to
>>>> the overhead for faulting pages back into the guest and zeroing of memory.
>>> It may also make sense to test these patches with netperf to observe how much
>>> performance drop it is introducing.
>>>> Patch 4 is a bit on the large side at about 600 lines of change, however
>>>> I really didn't see a good way to break it up since each piece feeds into
>>>> the next. So I couldn't add the statistics by themselves as it didn't
>>>> really make sense to add them without something that will either read or
>>>> increment/decrement them, or add the Hinted state without something that
>>>> would set/unset it. As such I just ended up adding the entire thing as
>>>> one patch. It makes it a bit bigger but avoids the issues in the previous
>>>> set where I was referencing things before they had been added.
>>>>
>>>> Changes from the RFC:
>>>> https://lore.kernel.org/lkml/20190530215223.13974.22445.stgit@localhost.localdomain/
>>>> Moved aeration requested flag out of aerator and into zone->flags.
>>>> Moved bounary 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.
>>>>
>>>> Changes from v1:
>>>> https://lore.kernel.org/lkml/20190619222922.1231.27432.stgit@localhost.localdomain/
>>>> Dropped "waste page treatment" in favor of "page hinting"
>>> We may still have to try and find a better name for virtio-balloon side changes.
>>> As "FREE_PAGE_HINT" and "PAGE_HINTING" are still confusing.
>>
>> We should have named that free page reporting, but that train already
>> has left.
> 
> I think VIRTIO_BALLOON_F_FREE_PAGE_HINT is different and arguably
> actually does provide hints.

I guess it depends on the point of view (e.g., getting all free pages
feels more like a report). But I could also live with using the term
reporting in this context.

We could go ahead and name it all "page reporting", would also work for me.

-- 

Thanks,

David / dhildenb

Re: [PATCH v2 0/5] mm / virtio: Provide support for page hinting

[Nitesh Narayan Lal]

On 7/24/19 3:47 PM, David Hildenbrand wrote:
> On 24.07.19 21:31, Michael S. Tsirkin wrote:
>> On Wed, Jul 24, 2019 at 08:41:33PM +0200, David Hildenbrand wrote:
>>> On 24.07.19 20:40, Nitesh Narayan Lal wrote:
>>>> On 7/24/19 12:54 PM, 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 page hinting
>>>>>
>>>>> The functionality for this is fairly simple. When enabled it will allocate
>>>>> statistics to track the number of hinted pages in a given free area. When
>>>>> the number of free pages exceeds this value plus a high water value,
>>>>> currently 32,
>>>> Shouldn't we configure this to a lower number such as 16?
>>>>>  it will begin performing page hinting which consists of
>>>>> pulling pages off of free list and placing them into a scatter list. The
>>>>> scatterlist is then given to the page hinting device and it will perform
>>>>> the required action to make the pages "hinted", in the case of
>>>>> virtio-balloon this results in the pages being madvised as MADV_DONTNEED
>>>>> and as such they are forced out of the guest. After this they are placed
>>>>> back on the free list, and an additional bit is added if they are not
>>>>> merged indicating that they are a hinted buddy page instead of a standard
>>>>> buddy page. The cycle then repeats with additional non-hinted pages being
>>>>> pulled until the free areas all consist of hinted pages.
>>>>>
>>>>> I am leaving a number of things hard-coded such as limiting the lowest
>>>>> order processed to PAGEBLOCK_ORDER,
>>>> Have you considered making this option configurable at the compile time?
>>>>>  and have left it up to the guest to
>>>>> determine what the limit is on how many pages it wants to allocate to
>>>>> process the hints.
>>>> It might make sense to set the number of pages to be hinted at a time from the
>>>> hypervisor.
>>>>> My primary testing has just been to verify the memory is being freed after
>>>>> allocation by running memhog 79g on a 80g 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 at most a 2% difference between the base
>>>>> kernel without these patches and the patches with virtio-balloon disabled.
>>>>> With the patches and virtio-balloon enabled with hinting the results
>>>>> largely depend on the host kernel. On a 3.10 RHEL kernel I saw up to a 2%
>>>>> drop in performance as I approached 16 threads,
>>>> I think this is acceptable.
>>>>>  however on the the lastest
>>>>> linux-next kernel I saw roughly a 4% to 5% improvement in performance for
>>>>> all tests with 8 or more threads. 
>>>> Do you mean that with your patches the will-it-scale/page_fault1 numbers were
>>>> better by 4-5% over an unmodified kernel?
>>>>> I believe the difference seen is due to
>>>>> the overhead for faulting pages back into the guest and zeroing of memory.
>>>> It may also make sense to test these patches with netperf to observe how much
>>>> performance drop it is introducing.
>>>>> Patch 4 is a bit on the large side at about 600 lines of change, however
>>>>> I really didn't see a good way to break it up since each piece feeds into
>>>>> the next. So I couldn't add the statistics by themselves as it didn't
>>>>> really make sense to add them without something that will either read or
>>>>> increment/decrement them, or add the Hinted state without something that
>>>>> would set/unset it. As such I just ended up adding the entire thing as
>>>>> one patch. It makes it a bit bigger but avoids the issues in the previous
>>>>> set where I was referencing things before they had been added.
>>>>>
>>>>> Changes from the RFC:
>>>>> https://lore.kernel.org/lkml/20190530215223.13974.22445.stgit@localhost.localdomain/
>>>>> Moved aeration requested flag out of aerator and into zone->flags.
>>>>> Moved bounary 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.
>>>>>
>>>>> Changes from v1:
>>>>> https://lore.kernel.org/lkml/20190619222922.1231.27432.stgit@localhost.localdomain/
>>>>> Dropped "waste page treatment" in favor of "page hinting"
>>>> We may still have to try and find a better name for virtio-balloon side changes.
>>>> As "FREE_PAGE_HINT" and "PAGE_HINTING" are still confusing.
>>> We should have named that free page reporting, but that train already
>>> has left.
>> I think VIRTIO_BALLOON_F_FREE_PAGE_HINT is different and arguably
>> actually does provide hints.
> I guess it depends on the point of view (e.g., getting all free pages
> feels more like a report). But I could also live with using the term
> reporting in this context.
>
> We could go ahead and name it all "page reporting", would also work for me.
I think that should work.
Having two separate names one for the kernel and the other for the virtio
interface will cause unnecessary confusion.
-- 
Thanks
Nitesh

Re: [PATCH v2 QEMU] virtio-balloon: Provide a interface for "bubble hinting"

[Alexander Duyck]

On Wed, 2019-07-24 at 15:02 -0400, Michael S. Tsirkin wrote:
> On Wed, Jul 24, 2019 at 10:12:10AM -0700, Alexander Duyck wrote:
> > From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> > 
> > Add support for what I am referring to as "bubble hinting". Basically the
> > idea is to function very similar to how the balloon works in that we
> > basically end up madvising the page as not being used. However we don't
> > really need to bother with any deflate type logic since the page will be
> > faulted back into the guest when it is read or written to.
> > 
> > This is meant to be a simplification of the existing balloon interface
> > to use for providing hints to what memory needs to be freed. I am assuming
> > this is safe to do as the deflate logic does not actually appear to do very
> > much other than tracking what subpages have been released and which ones
> > haven't.
> > 
> > Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> > ---
> >  hw/virtio/virtio-balloon.c                      |   40 +++++++++++++++++++++++
> >  include/hw/virtio/virtio-balloon.h              |    2 +
> >  include/standard-headers/linux/virtio_balloon.h |    1 +
> >  3 files changed, 42 insertions(+), 1 deletion(-)
> > 
> > diff --git a/hw/virtio/virtio-balloon.c b/hw/virtio/virtio-balloon.c
> > index 2112874055fb..70c0004c0f88 100644
> > --- a/hw/virtio/virtio-balloon.c
> > +++ b/hw/virtio/virtio-balloon.c
> > @@ -328,6 +328,39 @@ static void balloon_stats_set_poll_interval(Object *obj, Visitor *v,
> >      balloon_stats_change_timer(s, 0);
> >  }
> >  
> > +static void virtio_bubble_handle_output(VirtIODevice *vdev, VirtQueue *vq)
> > +{
> > +    VirtQueueElement *elem;
> > +
> > +    while ((elem = virtqueue_pop(vq, sizeof(VirtQueueElement)))) {
> > +    	unsigned int i;
> > +
> > +        for (i = 0; i < elem->in_num; i++) {
> > +            void *addr = elem->in_sg[i].iov_base;
> > +            size_t size = elem->in_sg[i].iov_len;
> > +            ram_addr_t ram_offset;
> > +            size_t rb_page_size;
> > +            RAMBlock *rb;
> > +
> > +            if (qemu_balloon_is_inhibited())
> > +                continue;
> > +
> > +            rb = qemu_ram_block_from_host(addr, false, &ram_offset);
> > +            rb_page_size = qemu_ram_pagesize(rb);
> > +
> > +            /* For now we will simply ignore unaligned memory regions */
> > +            if ((ram_offset | size) & (rb_page_size - 1))
> > +                continue;
> > +
> > +            ram_block_discard_range(rb, ram_offset, size);
> 
> I suspect this needs to do like the migration type of
> hinting and get disabled if page poisoning is in effect.
> Right?

Shouldn't something like that end up getting handled via
qemu_balloon_is_inhibited, or did I miss something there? I assumed cases
like that would end up setting qemu_balloon_is_inhibited to true, if that
isn't the case then I could add some additional conditions. I would do it
in about the same spot as the qemu_balloon_is_inhibited check.

Re: [PATCH v2 0/5] mm / virtio: Provide support for page hinting

[Alexander Duyck]

On Wed, 2019-07-24 at 14:40 -0400, Nitesh Narayan Lal wrote:
> On 7/24/19 12:54 PM, 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 page hinting
> > 
> > The functionality for this is fairly simple. When enabled it will allocate
> > statistics to track the number of hinted pages in a given free area. When
> > the number of free pages exceeds this value plus a high water value,
> > currently 32,
> Shouldn't we configure this to a lower number such as 16?

Yes, we could do 16.

> >  it will begin performing page hinting which consists of
> > pulling pages off of free list and placing them into a scatter list. The
> > scatterlist is then given to the page hinting device and it will perform
> > the required action to make the pages "hinted", in the case of
> > virtio-balloon this results in the pages being madvised as MADV_DONTNEED
> > and as such they are forced out of the guest. After this they are placed
> > back on the free list, and an additional bit is added if they are not
> > merged indicating that they are a hinted buddy page instead of a standard
> > buddy page. The cycle then repeats with additional non-hinted pages being
> > pulled until the free areas all consist of hinted pages.
> > 
> > I am leaving a number of things hard-coded such as limiting the lowest
> > order processed to PAGEBLOCK_ORDER,
> Have you considered making this option configurable at the compile time?

We could. However, PAGEBLOCK_ORDER is already configurable on some
architectures. I didn't see much point in making it configurable in the
case of x86 as there are only really 2 orders that this could be used in
that provided good performance and that MAX_ORDER - 1 and PAGEBLOCK_ORDER.

> >  and have left it up to the guest to
> > determine what the limit is on how many pages it wants to allocate to
> > process the hints.
> It might make sense to set the number of pages to be hinted at a time from the
> hypervisor.

We could do that. Although I would still want some upper limit on that as
I would prefer to keep the high water mark as a static value since it is
used in an inline function. Currently the virtio driver is the one
defining the capacity of pages per request.

> > My primary testing has just been to verify the memory is being freed after
> > allocation by running memhog 79g on a 80g 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 at most a 2% difference between the base
> > kernel without these patches and the patches with virtio-balloon disabled.
> > With the patches and virtio-balloon enabled with hinting the results
> > largely depend on the host kernel. On a 3.10 RHEL kernel I saw up to a 2%
> > drop in performance as I approached 16 threads,
> I think this is acceptable.
> >  however on the the lastest
> > linux-next kernel I saw roughly a 4% to 5% improvement in performance for
> > all tests with 8 or more threads. 
> Do you mean that with your patches the will-it-scale/page_fault1 numbers were
> better by 4-5% over an unmodified kernel?

Yes. That is the odd thing. I am wondering if there was some improvement
in the zeroing of THP pages or something that is somehow improving the
cache performance for the accessing of the pages by the test in the guest.

> > I believe the difference seen is due to
> > the overhead for faulting pages back into the guest and zeroing of memory.
> It may also make sense to test these patches with netperf to observe how much
> performance drop it is introducing.

Do you have some test you were already using? I ask because I am not sure
netperf would generate a large enough memory window size to really trigger
much of a change in terms of hinting. If you have some test in mind I
could probably set it up and run it pretty quick.

> > Patch 4 is a bit on the large side at about 600 lines of change, however
> > I really didn't see a good way to break it up since each piece feeds into
> > the next. So I couldn't add the statistics by themselves as it didn't
> > really make sense to add them without something that will either read or
> > increment/decrement them, or add the Hinted state without something that
> > would set/unset it. As such I just ended up adding the entire thing as
> > one patch. It makes it a bit bigger but avoids the issues in the previous
> > set where I was referencing things before they had been added.
> > 
> > Changes from the RFC:
> > https://lore.kernel.org/lkml/20190530215223.13974.22445.stgit@localhost.localdomain/
> > Moved aeration requested flag out of aerator and into zone->flags.
> > Moved bounary 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.
> > 
> > Changes from v1:
> > https://lore.kernel.org/lkml/20190619222922.1231.27432.stgit@localhost.localdomain/
> > Dropped "waste page treatment" in favor of "page hinting"
> We may still have to try and find a better name for virtio-balloon side changes.
> As "FREE_PAGE_HINT" and "PAGE_HINTING" are still confusing.

We just need to settle on a name. Essentially all this requires is just a
quick find and replace with whatever name we decide on.

Re: [PATCH v2 QEMU] virtio-balloon: Provide a interface for "bubble hinting"

[Nitesh Narayan Lal]

On 7/24/19 4:18 PM, Alexander Duyck wrote:
> On Wed, 2019-07-24 at 15:02 -0400, Michael S. Tsirkin wrote:
>> On Wed, Jul 24, 2019 at 10:12:10AM -0700, Alexander Duyck wrote:
>>> From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
>>>
>>> Add support for what I am referring to as "bubble hinting". Basically the
>>> idea is to function very similar to how the balloon works in that we
>>> basically end up madvising the page as not being used. However we don't
>>> really need to bother with any deflate type logic since the page will be
>>> faulted back into the guest when it is read or written to.
>>>
>>> This is meant to be a simplification of the existing balloon interface
>>> to use for providing hints to what memory needs to be freed. I am assuming
>>> this is safe to do as the deflate logic does not actually appear to do very
>>> much other than tracking what subpages have been released and which ones
>>> haven't.
>>>
>>> Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
>>> ---
>>>  hw/virtio/virtio-balloon.c                      |   40 +++++++++++++++++++++++
>>>  include/hw/virtio/virtio-balloon.h              |    2 +
>>>  include/standard-headers/linux/virtio_balloon.h |    1 +
>>>  3 files changed, 42 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/hw/virtio/virtio-balloon.c b/hw/virtio/virtio-balloon.c
>>> index 2112874055fb..70c0004c0f88 100644
>>> --- a/hw/virtio/virtio-balloon.c
>>> +++ b/hw/virtio/virtio-balloon.c
>>> @@ -328,6 +328,39 @@ static void balloon_stats_set_poll_interval(Object *obj, Visitor *v,
>>>      balloon_stats_change_timer(s, 0);
>>>  }
>>>  
>>> +static void virtio_bubble_handle_output(VirtIODevice *vdev, VirtQueue *vq)
>>> +{
>>> +    VirtQueueElement *elem;
>>> +
>>> +    while ((elem = virtqueue_pop(vq, sizeof(VirtQueueElement)))) {
>>> +    	unsigned int i;
>>> +
>>> +        for (i = 0; i < elem->in_num; i++) {
>>> +            void *addr = elem->in_sg[i].iov_base;
>>> +            size_t size = elem->in_sg[i].iov_len;
>>> +            ram_addr_t ram_offset;
>>> +            size_t rb_page_size;
>>> +            RAMBlock *rb;
>>> +
>>> +            if (qemu_balloon_is_inhibited())
>>> +                continue;
>>> +
>>> +            rb = qemu_ram_block_from_host(addr, false, &ram_offset);
>>> +            rb_page_size = qemu_ram_pagesize(rb);
>>> +
>>> +            /* For now we will simply ignore unaligned memory regions */
>>> +            if ((ram_offset | size) & (rb_page_size - 1))
>>> +                continue;
>>> +
>>> +            ram_block_discard_range(rb, ram_offset, size);
>> I suspect this needs to do like the migration type of
>> hinting and get disabled if page poisoning is in effect.
>> Right?
> Shouldn't something like that end up getting handled via
> qemu_balloon_is_inhibited, or did I miss something there? I assumed cases
> like that would end up setting qemu_balloon_is_inhibited to true, if that
> isn't the case then I could add some additional conditions. I would do it
> in about the same spot as the qemu_balloon_is_inhibited check.
I don't think qemu_balloon_is_inhibited() will take care of the page poisoning
situations.
If I am not wrong we may have to look to extend VIRTIO_BALLOON_F_PAGE_POISON
support as per Michael's suggestion.
>
>
-- 
Thanks
Nitesh

Re: [PATCH v2 5/5] virtio-balloon: Add support for providing page hints to host

[Alexander Duyck]

On Wed, 2019-07-24 at 15:02 -0400, Michael S. Tsirkin wrote:
> On Wed, Jul 24, 2019 at 10:05:14AM -0700, Alexander Duyck wrote:
> > From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> > 
> > Add support for the page hinting feature provided by virtio-balloon.
> > Hinting differs from the regular balloon functionality in that is is
> > much less durable than a standard memory balloon. Instead of creating a
> > list of pages that cannot be accessed the pages are only inaccessible
> > while they are being indicated to the virtio interface. Once the
> > interface has acknowledged them they are placed back into their respective
> > free lists and are once again accessible by the guest system.
> > 
> > Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> 
> Looking at the design, it seems that hinted pages can immediately be
> reused. I wonder how we can efficiently support this
> with kvm when poisoning is in effect. Of course we can just
> ignore the poison. However it seems cleaner to
> 1. verify page is poisoned with the correct value
> 2. fill the page with the correct value on fault
> 
> Requirement 2 requires some kind of madvise that
> will save the poison e.g. in the VMA.
> 
> Not a blocker for sure ... 

As per our discussion in the other patch I agree that we should either
ignore the hint/report if page poisoning is enabled, or page poisoning
should result in us poisoning the page when it is faulted back in. I had
assumed we were doing the latter, I didn't realize that is was just
disabling the free page hinting.

> > ---
> >  drivers/virtio/Kconfig              |    1 +
> >  drivers/virtio/virtio_balloon.c     |   47 +++++++++++++++++++++++++++++++++++
> >  include/uapi/linux/virtio_balloon.h |    1 +
> >  3 files changed, 49 insertions(+)
> > 
> > diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig
> > index 078615cf2afc..d45556ae1f81 100644
> > --- a/drivers/virtio/Kconfig
> > +++ b/drivers/virtio/Kconfig
> > @@ -58,6 +58,7 @@ config VIRTIO_BALLOON
> >  	tristate "Virtio balloon driver"
> >  	depends on VIRTIO
> >  	select MEMORY_BALLOON
> > +	select PAGE_HINTING
> >  	---help---
> >  	 This driver supports increasing and decreasing the amount
> >  	 of memory within a KVM guest.
> > diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
> > index 226fbb995fb0..dee9f8f3ad09 100644
> > --- a/drivers/virtio/virtio_balloon.c
> > +++ b/drivers/virtio/virtio_balloon.c
> > @@ -19,6 +19,7 @@
> >  #include <linux/mount.h>
> >  #include <linux/magic.h>
> >  #include <linux/pseudo_fs.h>
> > +#include <linux/page_hinting.h>
> >  
> >  /*
> >   * Balloon device works in 4K page units.  So each page is pointed to by
> > @@ -27,6 +28,7 @@
> >   */
> >  #define VIRTIO_BALLOON_PAGES_PER_PAGE (unsigned)(PAGE_SIZE >> VIRTIO_BALLOON_PFN_SHIFT)
> >  #define VIRTIO_BALLOON_ARRAY_PFNS_MAX 256
> > +#define VIRTIO_BALLOON_ARRAY_HINTS_MAX	32
> >  #define VIRTBALLOON_OOM_NOTIFY_PRIORITY 80
> >  
> >  #define VIRTIO_BALLOON_FREE_PAGE_ALLOC_FLAG (__GFP_NORETRY | __GFP_NOWARN | \
> > @@ -46,6 +48,7 @@ enum virtio_balloon_vq {
> >  	VIRTIO_BALLOON_VQ_DEFLATE,
> >  	VIRTIO_BALLOON_VQ_STATS,
> >  	VIRTIO_BALLOON_VQ_FREE_PAGE,
> > +	VIRTIO_BALLOON_VQ_HINTING,
> >  	VIRTIO_BALLOON_VQ_MAX
> >  };
> >  
> > @@ -113,6 +116,10 @@ struct virtio_balloon {
> >  
> >  	/* To register a shrinker to shrink memory upon memory pressure */
> >  	struct shrinker shrinker;
> > +
> > +	/* Unused page hinting device */
> > +	struct virtqueue *hinting_vq;
> > +	struct page_hinting_dev_info ph_dev_info;
> >  };
> >  
> >  static struct virtio_device_id id_table[] = {
> > @@ -152,6 +159,22 @@ static void tell_host(struct virtio_balloon *vb, struct virtqueue *vq)
> >  
> >  }
> >  
> > +void virtballoon_page_hinting_react(struct page_hinting_dev_info *ph_dev_info,
> > +				    unsigned int num_hints)
> > +{
> > +	struct virtio_balloon *vb =
> > +		container_of(ph_dev_info, struct virtio_balloon, ph_dev_info);
> > +	struct virtqueue *vq = vb->hinting_vq;
> > +	unsigned int unused;
> > +
> > +	/* We should always be able to add these buffers to an empty queue. */
> 
> can be an out of memory condition, and then ...
> 
> > +	virtqueue_add_inbuf(vq, ph_dev_info->sg, num_hints, vb, GFP_KERNEL);
> > +	virtqueue_kick(vq);
> 
> ... this will block forever.
> 
> > +	/* When host has read buffer, this completes via balloon_ack */
> > +	wait_event(vb->acked, virtqueue_get_buf(vq, &unused));
> 
> However below I suggest limiting capacity which will solve
> this problem for you.

I wasn't aware that virtqueue_add_inbuf actually performed an allocation.

> > +}
> > +
> >  static void set_page_pfns(struct virtio_balloon *vb,
> >  			  __virtio32 pfns[], struct page *page)
> >  {
> > @@ -476,6 +499,7 @@ static int init_vqs(struct virtio_balloon *vb)
> >  	names[VIRTIO_BALLOON_VQ_DEFLATE] = "deflate";
> >  	names[VIRTIO_BALLOON_VQ_STATS] = NULL;
> >  	names[VIRTIO_BALLOON_VQ_FREE_PAGE] = NULL;
> > +	names[VIRTIO_BALLOON_VQ_HINTING] = NULL;
> >  
> >  	if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_STATS_VQ)) {
> >  		names[VIRTIO_BALLOON_VQ_STATS] = "stats";
> > @@ -487,11 +511,19 @@ static int init_vqs(struct virtio_balloon *vb)
> >  		callbacks[VIRTIO_BALLOON_VQ_FREE_PAGE] = NULL;
> >  	}
> >  
> > +	if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_HINTING)) {
> > +		names[VIRTIO_BALLOON_VQ_HINTING] = "hinting_vq";
> > +		callbacks[VIRTIO_BALLOON_VQ_HINTING] = balloon_ack;
> > +	}
> > +
> >  	err = vb->vdev->config->find_vqs(vb->vdev, VIRTIO_BALLOON_VQ_MAX,
> >  					 vqs, callbacks, names, NULL, NULL);
> >  	if (err)
> >  		return err;
> >  
> > +	if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_HINTING))
> > +		vb->hinting_vq = vqs[VIRTIO_BALLOON_VQ_HINTING];
> > +
> >  	vb->inflate_vq = vqs[VIRTIO_BALLOON_VQ_INFLATE];
> >  	vb->deflate_vq = vqs[VIRTIO_BALLOON_VQ_DEFLATE];
> >  	if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_STATS_VQ)) {
> > @@ -924,12 +956,24 @@ static int virtballoon_probe(struct virtio_device *vdev)
> >  		if (err)
> >  			goto out_del_balloon_wq;
> >  	}
> > +
> > +	vb->ph_dev_info.react = virtballoon_page_hinting_react;
> > +	vb->ph_dev_info.capacity = VIRTIO_BALLOON_ARRAY_HINTS_MAX;
> 
> As explained above I think you should limit this by vq size.
> Otherwise virtqueue add buf might fail.
> In fact by struct spec reading you need to limit it
> anyway otherwise it will fail unconditionally.
> In practice on most hypervisors it will typically work ...

So I would just need to query that via the virtqueue_get_vring_size
function correct? I could probably just set capacity to the minimum of the
HINTS_MAX and that value right?

Re: [PATCH v2 0/5] mm / virtio: Provide support for page hinting

[Nitesh Narayan Lal]

On 7/24/19 4:27 PM, Alexander Duyck wrote:
> On Wed, 2019-07-24 at 14:40 -0400, Nitesh Narayan Lal wrote:
>> On 7/24/19 12:54 PM, 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 page hinting
>>>
>>> The functionality for this is fairly simple. When enabled it will allocate
>>> statistics to track the number of hinted pages in a given free area. When
>>> the number of free pages exceeds this value plus a high water value,
>>> currently 32,
>> Shouldn't we configure this to a lower number such as 16?
> Yes, we could do 16.
>
>>>  it will begin performing page hinting which consists of
>>> pulling pages off of free list and placing them into a scatter list. The
>>> scatterlist is then given to the page hinting device and it will perform
>>> the required action to make the pages "hinted", in the case of
>>> virtio-balloon this results in the pages being madvised as MADV_DONTNEED
>>> and as such they are forced out of the guest. After this they are placed
>>> back on the free list, and an additional bit is added if they are not
>>> merged indicating that they are a hinted buddy page instead of a standard
>>> buddy page. The cycle then repeats with additional non-hinted pages being
>>> pulled until the free areas all consist of hinted pages.
>>>
>>> I am leaving a number of things hard-coded such as limiting the lowest
>>> order processed to PAGEBLOCK_ORDER,
>> Have you considered making this option configurable at the compile time?
> We could. However, PAGEBLOCK_ORDER is already configurable on some
> architectures. I didn't see much point in making it configurable in the
> case of x86 as there are only really 2 orders that this could be used in
> that provided good performance and that MAX_ORDER - 1 and PAGEBLOCK_ORDER.
>
>>>  and have left it up to the guest to
>>> determine what the limit is on how many pages it wants to allocate to
>>> process the hints.
>> It might make sense to set the number of pages to be hinted at a time from the
>> hypervisor.
> We could do that. Although I would still want some upper limit on that as
> I would prefer to keep the high water mark as a static value since it is
> used in an inline function. Currently the virtio driver is the one
> defining the capacity of pages per request.
For the upper limit I think we can rely on max vq size. Isn't?
>
>>> My primary testing has just been to verify the memory is being freed after
>>> allocation by running memhog 79g on a 80g 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 at most a 2% difference between the base
>>> kernel without these patches and the patches with virtio-balloon disabled.
>>> With the patches and virtio-balloon enabled with hinting the results
>>> largely depend on the host kernel. On a 3.10 RHEL kernel I saw up to a 2%
>>> drop in performance as I approached 16 threads,
>> I think this is acceptable.
>>>  however on the the lastest
>>> linux-next kernel I saw roughly a 4% to 5% improvement in performance for
>>> all tests with 8 or more threads. 
>> Do you mean that with your patches the will-it-scale/page_fault1 numbers were
>> better by 4-5% over an unmodified kernel?
> Yes. That is the odd thing. I am wondering if there was some improvement
> in the zeroing of THP pages or something that is somehow improving the
> cache performance for the accessing of the pages by the test in the guest.
The values you were observing on an unmodified kernel, were they consistent over
fresh reboot?
Do you have any sort of workload running in the host as that could also impact
the numbers.
>
>>> I believe the difference seen is due to
>>> the overhead for faulting pages back into the guest and zeroing of memory.
>> It may also make sense to test these patches with netperf to observe how much
>> performance drop it is introducing.
> Do you have some test you were already using? I ask because I am not sure
> netperf would generate a large enough memory window size to really trigger
> much of a change in terms of hinting. If you have some test in mind I
> could probably set it up and run it pretty quick.
Earlier I have tried running netperf on a guest with 2 cores, i.e., netserver
pinned to one and netperf running on the other.
You have to specify a really large packet size and run the test for at least
15-30 minutes to actually see some hinting work.
>
>>> Patch 4 is a bit on the large side at about 600 lines of change, however
>>> I really didn't see a good way to break it up since each piece feeds into
>>> the next. So I couldn't add the statistics by themselves as it didn't
>>> really make sense to add them without something that will either read or
>>> increment/decrement them, or add the Hinted state without something that
>>> would set/unset it. As such I just ended up adding the entire thing as
>>> one patch. It makes it a bit bigger but avoids the issues in the previous
>>> set where I was referencing things before they had been added.
>>>
>>> Changes from the RFC:
>>> https://lore.kernel.org/lkml/20190530215223.13974.22445.stgit@localhost.localdomain/
>>> Moved aeration requested flag out of aerator and into zone->flags.
>>> Moved bounary 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.
>>>
>>> Changes from v1:
>>> https://lore.kernel.org/lkml/20190619222922.1231.27432.stgit@localhost.localdomain/
>>> Dropped "waste page treatment" in favor of "page hinting"
>> We may still have to try and find a better name for virtio-balloon side changes.
>> As "FREE_PAGE_HINT" and "PAGE_HINTING" are still confusing.
> We just need to settle on a name. Essentially all this requires is just a
> quick find and replace with whatever name we decide on.
I agree.
-- 
Thanks
Nitesh

Re: [PATCH v2 0/5] mm / virtio: Provide support for page hinting

[Michael S. Tsirkin]

On Wed, Jul 24, 2019 at 01:27:35PM -0700, Alexander Duyck wrote:
> On Wed, 2019-07-24 at 14:40 -0400, Nitesh Narayan Lal wrote:
> > On 7/24/19 12:54 PM, 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 page hinting
> > > 
> > > The functionality for this is fairly simple. When enabled it will allocate
> > > statistics to track the number of hinted pages in a given free area. When
> > > the number of free pages exceeds this value plus a high water value,
> > > currently 32,
> > Shouldn't we configure this to a lower number such as 16?
> 
> Yes, we could do 16.
> 
> > >  it will begin performing page hinting which consists of
> > > pulling pages off of free list and placing them into a scatter list. The
> > > scatterlist is then given to the page hinting device and it will perform
> > > the required action to make the pages "hinted", in the case of
> > > virtio-balloon this results in the pages being madvised as MADV_DONTNEED
> > > and as such they are forced out of the guest. After this they are placed
> > > back on the free list, and an additional bit is added if they are not
> > > merged indicating that they are a hinted buddy page instead of a standard
> > > buddy page. The cycle then repeats with additional non-hinted pages being
> > > pulled until the free areas all consist of hinted pages.
> > > 
> > > I am leaving a number of things hard-coded such as limiting the lowest
> > > order processed to PAGEBLOCK_ORDER,
> > Have you considered making this option configurable at the compile time?
> 
> We could. However, PAGEBLOCK_ORDER is already configurable on some
> architectures. I didn't see much point in making it configurable in the
> case of x86 as there are only really 2 orders that this could be used in
> that provided good performance and that MAX_ORDER - 1 and PAGEBLOCK_ORDER.
> 
> > >  and have left it up to the guest to
> > > determine what the limit is on how many pages it wants to allocate to
> > > process the hints.
> > It might make sense to set the number of pages to be hinted at a time from the
> > hypervisor.
> 
> We could do that. Although I would still want some upper limit on that as
> I would prefer to keep the high water mark as a static value since it is
> used in an inline function. Currently the virtio driver is the one
> defining the capacity of pages per request.
> 
> > > My primary testing has just been to verify the memory is being freed after
> > > allocation by running memhog 79g on a 80g 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 at most a 2% difference between the base
> > > kernel without these patches and the patches with virtio-balloon disabled.
> > > With the patches and virtio-balloon enabled with hinting the results
> > > largely depend on the host kernel. On a 3.10 RHEL kernel I saw up to a 2%
> > > drop in performance as I approached 16 threads,
> > I think this is acceptable.
> > >  however on the the lastest
> > > linux-next kernel I saw roughly a 4% to 5% improvement in performance for
> > > all tests with 8 or more threads. 
> > Do you mean that with your patches the will-it-scale/page_fault1 numbers were
> > better by 4-5% over an unmodified kernel?
> 
> Yes. That is the odd thing. I am wondering if there was some improvement
> in the zeroing of THP pages or something that is somehow improving the
> cache performance for the accessing of the pages by the test in the guest.

Well cache is indexed by the PA on intel, right?  So if you end up never
writing into the pages, reading them will be faster because you will end
up with a zero page. This will be offset by a fault when you finally do
write into the page.

> > > I believe the difference seen is due to
> > > the overhead for faulting pages back into the guest and zeroing of memory.
> > It may also make sense to test these patches with netperf to observe how much
> > performance drop it is introducing.
> 
> Do you have some test you were already using? I ask because I am not sure
> netperf would generate a large enough memory window size to really trigger
> much of a change in terms of hinting. If you have some test in mind I
> could probably set it up and run it pretty quick.
> 
> > > Patch 4 is a bit on the large side at about 600 lines of change, however
> > > I really didn't see a good way to break it up since each piece feeds into
> > > the next. So I couldn't add the statistics by themselves as it didn't
> > > really make sense to add them without something that will either read or
> > > increment/decrement them, or add the Hinted state without something that
> > > would set/unset it. As such I just ended up adding the entire thing as
> > > one patch. It makes it a bit bigger but avoids the issues in the previous
> > > set where I was referencing things before they had been added.
> > > 
> > > Changes from the RFC:
> > > https://lore.kernel.org/lkml/20190530215223.13974.22445.stgit@localhost.localdomain/
> > > Moved aeration requested flag out of aerator and into zone->flags.
> > > Moved bounary 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.
> > > 
> > > Changes from v1:
> > > https://lore.kernel.org/lkml/20190619222922.1231.27432.stgit@localhost.localdomain/
> > > Dropped "waste page treatment" in favor of "page hinting"
> > We may still have to try and find a better name for virtio-balloon side changes.
> > As "FREE_PAGE_HINT" and "PAGE_HINTING" are still confusing.
> 
> We just need to settle on a name. Essentially all this requires is just a
> quick find and replace with whatever name we decide on.

Re: [PATCH v2 QEMU] virtio-balloon: Provide a interface for "bubble hinting"

[Michael S. Tsirkin]

On Wed, Jul 24, 2019 at 04:29:27PM -0400, Nitesh Narayan Lal wrote:
> 
> On 7/24/19 4:18 PM, Alexander Duyck wrote:
> > On Wed, 2019-07-24 at 15:02 -0400, Michael S. Tsirkin wrote:
> >> On Wed, Jul 24, 2019 at 10:12:10AM -0700, Alexander Duyck wrote:
> >>> From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> >>>
> >>> Add support for what I am referring to as "bubble hinting". Basically the
> >>> idea is to function very similar to how the balloon works in that we
> >>> basically end up madvising the page as not being used. However we don't
> >>> really need to bother with any deflate type logic since the page will be
> >>> faulted back into the guest when it is read or written to.
> >>>
> >>> This is meant to be a simplification of the existing balloon interface
> >>> to use for providing hints to what memory needs to be freed. I am assuming
> >>> this is safe to do as the deflate logic does not actually appear to do very
> >>> much other than tracking what subpages have been released and which ones
> >>> haven't.
> >>>
> >>> Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> >>> ---
> >>>  hw/virtio/virtio-balloon.c                      |   40 +++++++++++++++++++++++
> >>>  include/hw/virtio/virtio-balloon.h              |    2 +
> >>>  include/standard-headers/linux/virtio_balloon.h |    1 +
> >>>  3 files changed, 42 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/hw/virtio/virtio-balloon.c b/hw/virtio/virtio-balloon.c
> >>> index 2112874055fb..70c0004c0f88 100644
> >>> --- a/hw/virtio/virtio-balloon.c
> >>> +++ b/hw/virtio/virtio-balloon.c
> >>> @@ -328,6 +328,39 @@ static void balloon_stats_set_poll_interval(Object *obj, Visitor *v,
> >>>      balloon_stats_change_timer(s, 0);
> >>>  }
> >>>  
> >>> +static void virtio_bubble_handle_output(VirtIODevice *vdev, VirtQueue *vq)
> >>> +{
> >>> +    VirtQueueElement *elem;
> >>> +
> >>> +    while ((elem = virtqueue_pop(vq, sizeof(VirtQueueElement)))) {
> >>> +    	unsigned int i;
> >>> +
> >>> +        for (i = 0; i < elem->in_num; i++) {
> >>> +            void *addr = elem->in_sg[i].iov_base;
> >>> +            size_t size = elem->in_sg[i].iov_len;
> >>> +            ram_addr_t ram_offset;
> >>> +            size_t rb_page_size;
> >>> +            RAMBlock *rb;
> >>> +
> >>> +            if (qemu_balloon_is_inhibited())
> >>> +                continue;
> >>> +
> >>> +            rb = qemu_ram_block_from_host(addr, false, &ram_offset);
> >>> +            rb_page_size = qemu_ram_pagesize(rb);
> >>> +
> >>> +            /* For now we will simply ignore unaligned memory regions */
> >>> +            if ((ram_offset | size) & (rb_page_size - 1))
> >>> +                continue;
> >>> +
> >>> +            ram_block_discard_range(rb, ram_offset, size);
> >> I suspect this needs to do like the migration type of
> >> hinting and get disabled if page poisoning is in effect.
> >> Right?
> > Shouldn't something like that end up getting handled via
> > qemu_balloon_is_inhibited, or did I miss something there? I assumed cases
> > like that would end up setting qemu_balloon_is_inhibited to true, if that
> > isn't the case then I could add some additional conditions. I would do it
> > in about the same spot as the qemu_balloon_is_inhibited check.
> I don't think qemu_balloon_is_inhibited() will take care of the page poisoning
> situations.
> If I am not wrong we may have to look to extend VIRTIO_BALLOON_F_PAGE_POISON
> support as per Michael's suggestion.


BTW upstream qemu seems to ignore VIRTIO_BALLOON_F_PAGE_POISON ATM.
Which is probably a bug.
Wei, could you take a look pls?

> >
> >
> -- 
> Thanks
> Nitesh

Re: [PATCH v2 5/5] virtio-balloon: Add support for providing page hints to host

[Michael S. Tsirkin]

On Wed, Jul 24, 2019 at 01:37:47PM -0700, Alexander Duyck wrote:
> On Wed, 2019-07-24 at 15:02 -0400, Michael S. Tsirkin wrote:
> > On Wed, Jul 24, 2019 at 10:05:14AM -0700, Alexander Duyck wrote:
> > > From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> > > 
> > > Add support for the page hinting feature provided by virtio-balloon.
> > > Hinting differs from the regular balloon functionality in that is is
> > > much less durable than a standard memory balloon. Instead of creating a
> > > list of pages that cannot be accessed the pages are only inaccessible
> > > while they are being indicated to the virtio interface. Once the
> > > interface has acknowledged them they are placed back into their respective
> > > free lists and are once again accessible by the guest system.
> > > 
> > > Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> > 
> > Looking at the design, it seems that hinted pages can immediately be
> > reused. I wonder how we can efficiently support this
> > with kvm when poisoning is in effect. Of course we can just
> > ignore the poison. However it seems cleaner to
> > 1. verify page is poisoned with the correct value
> > 2. fill the page with the correct value on fault
> > 
> > Requirement 2 requires some kind of madvise that
> > will save the poison e.g. in the VMA.
> > 
> > Not a blocker for sure ... 
> 
> As per our discussion in the other patch I agree that we should either
> ignore the hint/report if page poisoning is enabled, or page poisoning
> should result in us poisoning the page when it is faulted back in. I had
> assumed we were doing the latter, I didn't realize that is was just
> disabling the free page hinting.

In fact I see that the latest versions of qemu don't seem to do
the later either. Need to fix that ASAP...


> > > ---
> > >  drivers/virtio/Kconfig              |    1 +
> > >  drivers/virtio/virtio_balloon.c     |   47 +++++++++++++++++++++++++++++++++++
> > >  include/uapi/linux/virtio_balloon.h |    1 +
> > >  3 files changed, 49 insertions(+)
> > > 
> > > diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig
> > > index 078615cf2afc..d45556ae1f81 100644
> > > --- a/drivers/virtio/Kconfig
> > > +++ b/drivers/virtio/Kconfig
> > > @@ -58,6 +58,7 @@ config VIRTIO_BALLOON
> > >  	tristate "Virtio balloon driver"
> > >  	depends on VIRTIO
> > >  	select MEMORY_BALLOON
> > > +	select PAGE_HINTING
> > >  	---help---
> > >  	 This driver supports increasing and decreasing the amount
> > >  	 of memory within a KVM guest.
> > > diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
> > > index 226fbb995fb0..dee9f8f3ad09 100644
> > > --- a/drivers/virtio/virtio_balloon.c
> > > +++ b/drivers/virtio/virtio_balloon.c
> > > @@ -19,6 +19,7 @@
> > >  #include <linux/mount.h>
> > >  #include <linux/magic.h>
> > >  #include <linux/pseudo_fs.h>
> > > +#include <linux/page_hinting.h>
> > >  
> > >  /*
> > >   * Balloon device works in 4K page units.  So each page is pointed to by
> > > @@ -27,6 +28,7 @@
> > >   */
> > >  #define VIRTIO_BALLOON_PAGES_PER_PAGE (unsigned)(PAGE_SIZE >> VIRTIO_BALLOON_PFN_SHIFT)
> > >  #define VIRTIO_BALLOON_ARRAY_PFNS_MAX 256
> > > +#define VIRTIO_BALLOON_ARRAY_HINTS_MAX	32
> > >  #define VIRTBALLOON_OOM_NOTIFY_PRIORITY 80
> > >  
> > >  #define VIRTIO_BALLOON_FREE_PAGE_ALLOC_FLAG (__GFP_NORETRY | __GFP_NOWARN | \
> > > @@ -46,6 +48,7 @@ enum virtio_balloon_vq {
> > >  	VIRTIO_BALLOON_VQ_DEFLATE,
> > >  	VIRTIO_BALLOON_VQ_STATS,
> > >  	VIRTIO_BALLOON_VQ_FREE_PAGE,
> > > +	VIRTIO_BALLOON_VQ_HINTING,
> > >  	VIRTIO_BALLOON_VQ_MAX
> > >  };
> > >  
> > > @@ -113,6 +116,10 @@ struct virtio_balloon {
> > >  
> > >  	/* To register a shrinker to shrink memory upon memory pressure */
> > >  	struct shrinker shrinker;
> > > +
> > > +	/* Unused page hinting device */
> > > +	struct virtqueue *hinting_vq;
> > > +	struct page_hinting_dev_info ph_dev_info;
> > >  };
> > >  
> > >  static struct virtio_device_id id_table[] = {
> > > @@ -152,6 +159,22 @@ static void tell_host(struct virtio_balloon *vb, struct virtqueue *vq)
> > >  
> > >  }
> > >  
> > > +void virtballoon_page_hinting_react(struct page_hinting_dev_info *ph_dev_info,
> > > +				    unsigned int num_hints)
> > > +{
> > > +	struct virtio_balloon *vb =
> > > +		container_of(ph_dev_info, struct virtio_balloon, ph_dev_info);
> > > +	struct virtqueue *vq = vb->hinting_vq;
> > > +	unsigned int unused;
> > > +
> > > +	/* We should always be able to add these buffers to an empty queue. */
> > 
> > can be an out of memory condition, and then ...
> > 
> > > +	virtqueue_add_inbuf(vq, ph_dev_info->sg, num_hints, vb, GFP_KERNEL);
> > > +	virtqueue_kick(vq);
> > 
> > ... this will block forever.
> > 
> > > +	/* When host has read buffer, this completes via balloon_ack */
> > > +	wait_event(vb->acked, virtqueue_get_buf(vq, &unused));
> > 
> > However below I suggest limiting capacity which will solve
> > this problem for you.
> 
> I wasn't aware that virtqueue_add_inbuf actually performed an allocation.
> 
> > > +}
> > > +
> > >  static void set_page_pfns(struct virtio_balloon *vb,
> > >  			  __virtio32 pfns[], struct page *page)
> > >  {
> > > @@ -476,6 +499,7 @@ static int init_vqs(struct virtio_balloon *vb)
> > >  	names[VIRTIO_BALLOON_VQ_DEFLATE] = "deflate";
> > >  	names[VIRTIO_BALLOON_VQ_STATS] = NULL;
> > >  	names[VIRTIO_BALLOON_VQ_FREE_PAGE] = NULL;
> > > +	names[VIRTIO_BALLOON_VQ_HINTING] = NULL;
> > >  
> > >  	if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_STATS_VQ)) {
> > >  		names[VIRTIO_BALLOON_VQ_STATS] = "stats";
> > > @@ -487,11 +511,19 @@ static int init_vqs(struct virtio_balloon *vb)
> > >  		callbacks[VIRTIO_BALLOON_VQ_FREE_PAGE] = NULL;
> > >  	}
> > >  
> > > +	if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_HINTING)) {
> > > +		names[VIRTIO_BALLOON_VQ_HINTING] = "hinting_vq";
> > > +		callbacks[VIRTIO_BALLOON_VQ_HINTING] = balloon_ack;
> > > +	}
> > > +
> > >  	err = vb->vdev->config->find_vqs(vb->vdev, VIRTIO_BALLOON_VQ_MAX,
> > >  					 vqs, callbacks, names, NULL, NULL);
> > >  	if (err)
> > >  		return err;
> > >  
> > > +	if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_HINTING))
> > > +		vb->hinting_vq = vqs[VIRTIO_BALLOON_VQ_HINTING];
> > > +
> > >  	vb->inflate_vq = vqs[VIRTIO_BALLOON_VQ_INFLATE];
> > >  	vb->deflate_vq = vqs[VIRTIO_BALLOON_VQ_DEFLATE];
> > >  	if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_STATS_VQ)) {
> > > @@ -924,12 +956,24 @@ static int virtballoon_probe(struct virtio_device *vdev)
> > >  		if (err)
> > >  			goto out_del_balloon_wq;
> > >  	}
> > > +
> > > +	vb->ph_dev_info.react = virtballoon_page_hinting_react;
> > > +	vb->ph_dev_info.capacity = VIRTIO_BALLOON_ARRAY_HINTS_MAX;
> > 
> > As explained above I think you should limit this by vq size.
> > Otherwise virtqueue add buf might fail.
> > In fact by struct spec reading you need to limit it
> > anyway otherwise it will fail unconditionally.
> > In practice on most hypervisors it will typically work ...
> 
> So I would just need to query that via the virtqueue_get_vring_size
> function correct? I could probably just set capacity to the minimum of the
> HINTS_MAX and that value right?
> 
> 

Re: [PATCH v2 QEMU] virtio-balloon: Provide a interface for "bubble hinting"

[Michael S. Tsirkin]

On Wed, Jul 24, 2019 at 01:18:00PM -0700, Alexander Duyck wrote:
> On Wed, 2019-07-24 at 15:02 -0400, Michael S. Tsirkin wrote:
> > On Wed, Jul 24, 2019 at 10:12:10AM -0700, Alexander Duyck wrote:
> > > From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> > > 
> > > Add support for what I am referring to as "bubble hinting". Basically the
> > > idea is to function very similar to how the balloon works in that we
> > > basically end up madvising the page as not being used. However we don't
> > > really need to bother with any deflate type logic since the page will be
> > > faulted back into the guest when it is read or written to.
> > > 
> > > This is meant to be a simplification of the existing balloon interface
> > > to use for providing hints to what memory needs to be freed. I am assuming
> > > this is safe to do as the deflate logic does not actually appear to do very
> > > much other than tracking what subpages have been released and which ones
> > > haven't.
> > > 
> > > Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> > > ---
> > >  hw/virtio/virtio-balloon.c                      |   40 +++++++++++++++++++++++
> > >  include/hw/virtio/virtio-balloon.h              |    2 +
> > >  include/standard-headers/linux/virtio_balloon.h |    1 +
> > >  3 files changed, 42 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/hw/virtio/virtio-balloon.c b/hw/virtio/virtio-balloon.c
> > > index 2112874055fb..70c0004c0f88 100644
> > > --- a/hw/virtio/virtio-balloon.c
> > > +++ b/hw/virtio/virtio-balloon.c
> > > @@ -328,6 +328,39 @@ static void balloon_stats_set_poll_interval(Object *obj, Visitor *v,
> > >      balloon_stats_change_timer(s, 0);
> > >  }
> > >  
> > > +static void virtio_bubble_handle_output(VirtIODevice *vdev, VirtQueue *vq)
> > > +{
> > > +    VirtQueueElement *elem;
> > > +
> > > +    while ((elem = virtqueue_pop(vq, sizeof(VirtQueueElement)))) {
> > > +    	unsigned int i;
> > > +
> > > +        for (i = 0; i < elem->in_num; i++) {
> > > +            void *addr = elem->in_sg[i].iov_base;
> > > +            size_t size = elem->in_sg[i].iov_len;
> > > +            ram_addr_t ram_offset;
> > > +            size_t rb_page_size;
> > > +            RAMBlock *rb;
> > > +
> > > +            if (qemu_balloon_is_inhibited())
> > > +                continue;
> > > +
> > > +            rb = qemu_ram_block_from_host(addr, false, &ram_offset);
> > > +            rb_page_size = qemu_ram_pagesize(rb);
> > > +
> > > +            /* For now we will simply ignore unaligned memory regions */
> > > +            if ((ram_offset | size) & (rb_page_size - 1))
> > > +                continue;
> > > +
> > > +            ram_block_discard_range(rb, ram_offset, size);
> > 
> > I suspect this needs to do like the migration type of
> > hinting and get disabled if page poisoning is in effect.
> > Right?
> 
> Shouldn't something like that end up getting handled via
> qemu_balloon_is_inhibited, or did I miss something there? I assumed cases
> like that would end up setting qemu_balloon_is_inhibited to true, if that
> isn't the case then I could add some additional conditions. I would do it
> in about the same spot as the qemu_balloon_is_inhibited check.

Well qemu_balloon_is_inhibited is for the regular ballooning,
mostly a work-around for limitations is host linux iommu
APIs when it's used with VFIO.

-- 
MST

Re: [PATCH v2 0/5] mm / virtio: Provide support for page hinting

[Alexander Duyck]

On Wed, 2019-07-24 at 16:38 -0400, Nitesh Narayan Lal wrote:
> On 7/24/19 4:27 PM, Alexander Duyck wrote:
> > On Wed, 2019-07-24 at 14:40 -0400, Nitesh Narayan Lal wrote:
> > > On 7/24/19 12:54 PM, 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 page hinting
> > > > 
> > > > The functionality for this is fairly simple. When enabled it will allocate
> > > > statistics to track the number of hinted pages in a given free area. When
> > > > the number of free pages exceeds this value plus a high water value,
> > > > currently 32,
> > > Shouldn't we configure this to a lower number such as 16?
> > Yes, we could do 16.
> > 
> > > >  it will begin performing page hinting which consists of
> > > > pulling pages off of free list and placing them into a scatter list. The
> > > > scatterlist is then given to the page hinting device and it will perform
> > > > the required action to make the pages "hinted", in the case of
> > > > virtio-balloon this results in the pages being madvised as MADV_DONTNEED
> > > > and as such they are forced out of the guest. After this they are placed
> > > > back on the free list, and an additional bit is added if they are not
> > > > merged indicating that they are a hinted buddy page instead of a standard
> > > > buddy page. The cycle then repeats with additional non-hinted pages being
> > > > pulled until the free areas all consist of hinted pages.
> > > > 
> > > > I am leaving a number of things hard-coded such as limiting the lowest
> > > > order processed to PAGEBLOCK_ORDER,
> > > Have you considered making this option configurable at the compile time?
> > We could. However, PAGEBLOCK_ORDER is already configurable on some
> > architectures. I didn't see much point in making it configurable in the
> > case of x86 as there are only really 2 orders that this could be used in
> > that provided good performance and that MAX_ORDER - 1 and PAGEBLOCK_ORDER.
> > 
> > > >  and have left it up to the guest to
> > > > determine what the limit is on how many pages it wants to allocate to
> > > > process the hints.
> > > It might make sense to set the number of pages to be hinted at a time from the
> > > hypervisor.
> > We could do that. Although I would still want some upper limit on that as
> > I would prefer to keep the high water mark as a static value since it is
> > used in an inline function. Currently the virtio driver is the one
> > defining the capacity of pages per request.
> For the upper limit I think we can rely on max vq size. Isn't?

I would still want to limit how many pages could be pulled. Otherwise we
have the risk of a hypervisor that allocates a vq size of 1024 or
something like that and with 4M pages that could essentially OOM a 4G
guest.

That is why I figure what we probably should do is base the upper limit of
either 16 or 32 so that we only have at most something like 64M or 128M of
memory being held by the driver while it is being "reported". If we leave
spare room in the ring so be it, better that then triggering unneeded OOM
conditions.

> > > > My primary testing has just been to verify the memory is being freed after
> > > > allocation by running memhog 79g on a 80g 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 at most a 2% difference between the base
> > > > kernel without these patches and the patches with virtio-balloon disabled.
> > > > With the patches and virtio-balloon enabled with hinting the results
> > > > largely depend on the host kernel. On a 3.10 RHEL kernel I saw up to a 2%
> > > > drop in performance as I approached 16 threads,
> > > I think this is acceptable.
> > > >  however on the the lastest
> > > > linux-next kernel I saw roughly a 4% to 5% improvement in performance for
> > > > all tests with 8 or more threads. 
> > > Do you mean that with your patches the will-it-scale/page_fault1 numbers were
> > > better by 4-5% over an unmodified kernel?
> > Yes. That is the odd thing. I am wondering if there was some improvement
> > in the zeroing of THP pages or something that is somehow improving the
> > cache performance for the accessing of the pages by the test in the guest.
> The values you were observing on an unmodified kernel, were they consistent over
> fresh reboot?
> Do you have any sort of workload running in the host as that could also impact
> the numbers.

The host was an unmodified linux-next kernel. What I was doing is I would
reboot, load the guest run one kernel, swap the kernel in the guest and
just reboot the guest, run the next kernel, and then switch back to the
first kernel to make certain there wasn't anything that changed between
the runs.

I still need to do more research though. I'm still suspecting it has
something to do with the page zeroing on faults though as that was what
was showing up on a perf top when we hit about 8 or more threads active in
the guest.

> > > > I believe the difference seen is due to
> > > > the overhead for faulting pages back into the guest and zeroing of memory.
> > > It may also make sense to test these patches with netperf to observe how much
> > > performance drop it is introducing.
> > Do you have some test you were already using? I ask because I am not sure
> > netperf would generate a large enough memory window size to really trigger
> > much of a change in terms of hinting. If you have some test in mind I
> > could probably set it up and run it pretty quick.
> Earlier I have tried running netperf on a guest with 2 cores, i.e., netserver
> pinned to one and netperf running on the other.
> You have to specify a really large packet size and run the test for at least
> 15-30 minutes to actually see some hinting work.

I can take a look. I am not expecting much though.

> > > > Patch 4 is a bit on the large side at about 600 lines of change, however
> > > > I really didn't see a good way to break it up since each piece feeds into
> > > > the next. So I couldn't add the statistics by themselves as it didn't
> > > > really make sense to add them without something that will either read or
> > > > increment/decrement them, or add the Hinted state without something that
> > > > would set/unset it. As such I just ended up adding the entire thing as
> > > > one patch. It makes it a bit bigger but avoids the issues in the previous
> > > > set where I was referencing things before they had been added.
> > > > 
> > > > Changes from the RFC:
> > > > https://lore.kernel.org/lkml/20190530215223.13974.22445.stgit@localhost.localdomain/
> > > > Moved aeration requested flag out of aerator and into zone->flags.
> > > > Moved bounary 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.
> > > > 
> > > > Changes from v1:
> > > > https://lore.kernel.org/lkml/20190619222922.1231.27432.stgit@localhost.localdomain/
> > > > Dropped "waste page treatment" in favor of "page hinting"
> > > We may still have to try and find a better name for virtio-balloon side changes.
> > > As "FREE_PAGE_HINT" and "PAGE_HINTING" are still confusing.
> > We just need to settle on a name. Essentially all this requires is just a
> > quick find and replace with whatever name we decide on.
> I agree.

I will probably look at seeing if I can keep the kernel feature as free
page hinting and just make the virtio feature page reporting. It should be
pretty straight forward as I could just replace the mentions of react with
report and only have to tweak a few bits of patch 5.

Re: [PATCH v2 QEMU] virtio-balloon: Provide a interface for "bubble hinting"

[Alexander Duyck]

On Wed, 2019-07-24 at 16:46 -0400, Michael S. Tsirkin wrote:
> On Wed, Jul 24, 2019 at 01:18:00PM -0700, Alexander Duyck wrote:
> > On Wed, 2019-07-24 at 15:02 -0400, Michael S. Tsirkin wrote:
> > > On Wed, Jul 24, 2019 at 10:12:10AM -0700, Alexander Duyck wrote:
> > > > From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> > > > 
> > > > Add support for what I am referring to as "bubble hinting". Basically the
> > > > idea is to function very similar to how the balloon works in that we
> > > > basically end up madvising the page as not being used. However we don't
> > > > really need to bother with any deflate type logic since the page will be
> > > > faulted back into the guest when it is read or written to.
> > > > 
> > > > This is meant to be a simplification of the existing balloon interface
> > > > to use for providing hints to what memory needs to be freed. I am assuming
> > > > this is safe to do as the deflate logic does not actually appear to do very
> > > > much other than tracking what subpages have been released and which ones
> > > > haven't.
> > > > 
> > > > Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> > > > ---
> > > >  hw/virtio/virtio-balloon.c                      |   40 +++++++++++++++++++++++
> > > >  include/hw/virtio/virtio-balloon.h              |    2 +
> > > >  include/standard-headers/linux/virtio_balloon.h |    1 +
> > > >  3 files changed, 42 insertions(+), 1 deletion(-)
> > > > 
> > > > diff --git a/hw/virtio/virtio-balloon.c b/hw/virtio/virtio-balloon.c
> > > > index 2112874055fb..70c0004c0f88 100644
> > > > --- a/hw/virtio/virtio-balloon.c
> > > > +++ b/hw/virtio/virtio-balloon.c
> > > > @@ -328,6 +328,39 @@ static void balloon_stats_set_poll_interval(Object *obj, Visitor *v,
> > > >      balloon_stats_change_timer(s, 0);
> > > >  }
> > > >  
> > > > +static void virtio_bubble_handle_output(VirtIODevice *vdev, VirtQueue *vq)
> > > > +{
> > > > +    VirtQueueElement *elem;
> > > > +
> > > > +    while ((elem = virtqueue_pop(vq, sizeof(VirtQueueElement)))) {
> > > > +    	unsigned int i;
> > > > +
> > > > +        for (i = 0; i < elem->in_num; i++) {
> > > > +            void *addr = elem->in_sg[i].iov_base;
> > > > +            size_t size = elem->in_sg[i].iov_len;
> > > > +            ram_addr_t ram_offset;
> > > > +            size_t rb_page_size;
> > > > +            RAMBlock *rb;
> > > > +
> > > > +            if (qemu_balloon_is_inhibited())
> > > > +                continue;
> > > > +
> > > > +            rb = qemu_ram_block_from_host(addr, false, &ram_offset);
> > > > +            rb_page_size = qemu_ram_pagesize(rb);
> > > > +
> > > > +            /* For now we will simply ignore unaligned memory regions */
> > > > +            if ((ram_offset | size) & (rb_page_size - 1))
> > > > +                continue;
> > > > +
> > > > +            ram_block_discard_range(rb, ram_offset, size);
> > > 
> > > I suspect this needs to do like the migration type of
> > > hinting and get disabled if page poisoning is in effect.
> > > Right?
> > 
> > Shouldn't something like that end up getting handled via
> > qemu_balloon_is_inhibited, or did I miss something there? I assumed cases
> > like that would end up setting qemu_balloon_is_inhibited to true, if that
> > isn't the case then I could add some additional conditions. I would do it
> > in about the same spot as the qemu_balloon_is_inhibited check.
> 
> Well qemu_balloon_is_inhibited is for the regular ballooning,
> mostly a work-around for limitations is host linux iommu
> APIs when it's used with VFIO.

I understood that. However it also addresses the shared memory case as
well if I recall correctly. Basically any case where us discarding the
page could cause issues we should be causing that function to return true.

Re: [PATCH v2 0/5] mm / virtio: Provide support for page hinting

[Michael S. Tsirkin]

On Wed, Jul 24, 2019 at 09:47:24PM +0200, David Hildenbrand wrote:
> On 24.07.19 21:31, Michael S. Tsirkin wrote:
> > On Wed, Jul 24, 2019 at 08:41:33PM +0200, David Hildenbrand wrote:
> >> On 24.07.19 20:40, Nitesh Narayan Lal wrote:
> >>>
> >>> On 7/24/19 12:54 PM, 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 page hinting
> >>>>
> >>>> The functionality for this is fairly simple. When enabled it will allocate
> >>>> statistics to track the number of hinted pages in a given free area. When
> >>>> the number of free pages exceeds this value plus a high water value,
> >>>> currently 32,
> >>> Shouldn't we configure this to a lower number such as 16?
> >>>>  it will begin performing page hinting which consists of
> >>>> pulling pages off of free list and placing them into a scatter list. The
> >>>> scatterlist is then given to the page hinting device and it will perform
> >>>> the required action to make the pages "hinted", in the case of
> >>>> virtio-balloon this results in the pages being madvised as MADV_DONTNEED
> >>>> and as such they are forced out of the guest. After this they are placed
> >>>> back on the free list, and an additional bit is added if they are not
> >>>> merged indicating that they are a hinted buddy page instead of a standard
> >>>> buddy page. The cycle then repeats with additional non-hinted pages being
> >>>> pulled until the free areas all consist of hinted pages.
> >>>>
> >>>> I am leaving a number of things hard-coded such as limiting the lowest
> >>>> order processed to PAGEBLOCK_ORDER,
> >>> Have you considered making this option configurable at the compile time?
> >>>>  and have left it up to the guest to
> >>>> determine what the limit is on how many pages it wants to allocate to
> >>>> process the hints.
> >>> It might make sense to set the number of pages to be hinted at a time from the
> >>> hypervisor.
> >>>>
> >>>> My primary testing has just been to verify the memory is being freed after
> >>>> allocation by running memhog 79g on a 80g 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 at most a 2% difference between the base
> >>>> kernel without these patches and the patches with virtio-balloon disabled.
> >>>> With the patches and virtio-balloon enabled with hinting the results
> >>>> largely depend on the host kernel. On a 3.10 RHEL kernel I saw up to a 2%
> >>>> drop in performance as I approached 16 threads,
> >>> I think this is acceptable.
> >>>>  however on the the lastest
> >>>> linux-next kernel I saw roughly a 4% to 5% improvement in performance for
> >>>> all tests with 8 or more threads. 
> >>> Do you mean that with your patches the will-it-scale/page_fault1 numbers were
> >>> better by 4-5% over an unmodified kernel?
> >>>> I believe the difference seen is due to
> >>>> the overhead for faulting pages back into the guest and zeroing of memory.
> >>> It may also make sense to test these patches with netperf to observe how much
> >>> performance drop it is introducing.
> >>>> Patch 4 is a bit on the large side at about 600 lines of change, however
> >>>> I really didn't see a good way to break it up since each piece feeds into
> >>>> the next. So I couldn't add the statistics by themselves as it didn't
> >>>> really make sense to add them without something that will either read or
> >>>> increment/decrement them, or add the Hinted state without something that
> >>>> would set/unset it. As such I just ended up adding the entire thing as
> >>>> one patch. It makes it a bit bigger but avoids the issues in the previous
> >>>> set where I was referencing things before they had been added.
> >>>>
> >>>> Changes from the RFC:
> >>>> https://lore.kernel.org/lkml/20190530215223.13974.22445.stgit@localhost.localdomain/
> >>>> Moved aeration requested flag out of aerator and into zone->flags.
> >>>> Moved bounary 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.
> >>>>
> >>>> Changes from v1:
> >>>> https://lore.kernel.org/lkml/20190619222922.1231.27432.stgit@localhost.localdomain/
> >>>> Dropped "waste page treatment" in favor of "page hinting"
> >>> We may still have to try and find a better name for virtio-balloon side changes.
> >>> As "FREE_PAGE_HINT" and "PAGE_HINTING" are still confusing.
> >>
> >> We should have named that free page reporting, but that train already
> >> has left.
> > 
> > I think VIRTIO_BALLOON_F_FREE_PAGE_HINT is different and arguably
> > actually does provide hints.
> 
> I guess it depends on the point of view (e.g., getting all free pages
> feels more like a report). But I could also live with using the term
> reporting in this context.
> 
> We could go ahead and name it all "page reporting", would also work for me.

So there are actually three differences between the machanisms:
1. VIRTIO_BALLOON_F_FREE_PAGE_HINT sometimes reports pages which might no
   longer be on the free list (with subtle limitations which sometimes
   still allow hypervisor to discard the pages)
2. VIRTIO_BALLOON_F_FREE_PAGE_HINT starts reporting when requested by
   host
3. VIRTIO_BALLOON_F_FREE_PAGE_HINT is not incremental: each request
   by host reports all free memory

By comparison, the proposed patches:
- always report only actually free pages
- report at a random time
- report incrementally


> -- 
> 
> Thanks,
> 
> David / dhildenb

Re: [PATCH v2 QEMU] virtio-balloon: Provide a interface for "bubble hinting"

[Michael S. Tsirkin]

On Wed, Jul 24, 2019 at 10:12:10AM -0700, Alexander Duyck wrote:
> From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> 
> Add support for what I am referring to as "bubble hinting". Basically the
> idea is to function very similar to how the balloon works in that we
> basically end up madvising the page as not being used. However we don't
> really need to bother with any deflate type logic since the page will be
> faulted back into the guest when it is read or written to.
> 
> This is meant to be a simplification of the existing balloon interface
> to use for providing hints to what memory needs to be freed. I am assuming
> this is safe to do as the deflate logic does not actually appear to do very
> much other than tracking what subpages have been released and which ones
> haven't.
> 
> Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>

BTW I wonder about migration here.  When we migrate we lose all hints
right?  Well destination could be smarter, detect that page is full of
0s and just map a zero page. Then we don't need a hint as such - but I
don't think it's done like that ATM.


I also wonder about interaction with deflate.  ATM deflate will add
pages to the free list, then balloon will come right back and report
them as free.


> ---
>  hw/virtio/virtio-balloon.c                      |   40 +++++++++++++++++++++++
>  include/hw/virtio/virtio-balloon.h              |    2 +
>  include/standard-headers/linux/virtio_balloon.h |    1 +
>  3 files changed, 42 insertions(+), 1 deletion(-)
> 
> diff --git a/hw/virtio/virtio-balloon.c b/hw/virtio/virtio-balloon.c
> index 2112874055fb..70c0004c0f88 100644
> --- a/hw/virtio/virtio-balloon.c
> +++ b/hw/virtio/virtio-balloon.c
> @@ -328,6 +328,39 @@ static void balloon_stats_set_poll_interval(Object *obj, Visitor *v,
>      balloon_stats_change_timer(s, 0);
>  }
>  
> +static void virtio_bubble_handle_output(VirtIODevice *vdev, VirtQueue *vq)
> +{
> +    VirtQueueElement *elem;
> +
> +    while ((elem = virtqueue_pop(vq, sizeof(VirtQueueElement)))) {
> +    	unsigned int i;
> +
> +        for (i = 0; i < elem->in_num; i++) {
> +            void *addr = elem->in_sg[i].iov_base;
> +            size_t size = elem->in_sg[i].iov_len;
> +            ram_addr_t ram_offset;
> +            size_t rb_page_size;
> +            RAMBlock *rb;
> +
> +            if (qemu_balloon_is_inhibited())
> +                continue;
> +
> +            rb = qemu_ram_block_from_host(addr, false, &ram_offset);
> +            rb_page_size = qemu_ram_pagesize(rb);
> +
> +            /* For now we will simply ignore unaligned memory regions */
> +            if ((ram_offset | size) & (rb_page_size - 1))
> +                continue;
> +
> +            ram_block_discard_range(rb, ram_offset, size);
> +        }
> +
> +        virtqueue_push(vq, elem, 0);
> +        virtio_notify(vdev, vq);
> +        g_free(elem);
> +    }
> +}
> +
>  static void virtio_balloon_handle_output(VirtIODevice *vdev, VirtQueue *vq)
>  {
>      VirtIOBalloon *s = VIRTIO_BALLOON(vdev);
> @@ -782,6 +815,11 @@ static void virtio_balloon_device_realize(DeviceState *dev, Error **errp)
>      s->svq = virtio_add_queue(vdev, 128, virtio_balloon_receive_stats);
>  
>      if (virtio_has_feature(s->host_features,
> +                           VIRTIO_BALLOON_F_HINTING)) {
> +        s->hvq = virtio_add_queue(vdev, 128, virtio_bubble_handle_output);
> +    }
> +
> +    if (virtio_has_feature(s->host_features,
>                             VIRTIO_BALLOON_F_FREE_PAGE_HINT)) {
>          s->free_page_vq = virtio_add_queue(vdev, VIRTQUEUE_MAX_SIZE,
>                                             virtio_balloon_handle_free_page_vq);
> @@ -897,6 +935,8 @@ static Property virtio_balloon_properties[] = {
>                      VIRTIO_BALLOON_F_DEFLATE_ON_OOM, false),
>      DEFINE_PROP_BIT("free-page-hint", VirtIOBalloon, host_features,
>                      VIRTIO_BALLOON_F_FREE_PAGE_HINT, false),
> +    DEFINE_PROP_BIT("guest-page-hinting", VirtIOBalloon, host_features,
> +                    VIRTIO_BALLOON_F_HINTING, true),
>      DEFINE_PROP_LINK("iothread", VirtIOBalloon, iothread, TYPE_IOTHREAD,
>                       IOThread *),
>      DEFINE_PROP_END_OF_LIST(),
> diff --git a/include/hw/virtio/virtio-balloon.h b/include/hw/virtio/virtio-balloon.h
> index 1afafb12f6bc..a58b24fdf29d 100644
> --- a/include/hw/virtio/virtio-balloon.h
> +++ b/include/hw/virtio/virtio-balloon.h
> @@ -44,7 +44,7 @@ enum virtio_balloon_free_page_report_status {
>  
>  typedef struct VirtIOBalloon {
>      VirtIODevice parent_obj;
> -    VirtQueue *ivq, *dvq, *svq, *free_page_vq;
> +    VirtQueue *ivq, *dvq, *svq, *free_page_vq, *hvq;
>      uint32_t free_page_report_status;
>      uint32_t num_pages;
>      uint32_t actual;
> diff --git a/include/standard-headers/linux/virtio_balloon.h b/include/standard-headers/linux/virtio_balloon.h
> index 9375ca2a70de..f9e3e8256261 100644
> --- a/include/standard-headers/linux/virtio_balloon.h
> +++ b/include/standard-headers/linux/virtio_balloon.h
> @@ -36,6 +36,7 @@
>  #define VIRTIO_BALLOON_F_DEFLATE_ON_OOM	2 /* Deflate balloon on OOM */
>  #define VIRTIO_BALLOON_F_FREE_PAGE_HINT	3 /* VQ to report free pages */
>  #define VIRTIO_BALLOON_F_PAGE_POISON	4 /* Guest is using page poisoning */
> +#define VIRTIO_BALLOON_F_HINTING	5 /* Page hinting virtqueue */
>  
>  /* Size of a PFN in the balloon interface. */
>  #define VIRTIO_BALLOON_PFN_SHIFT 12

Re: [PATCH v2 QEMU] virtio-balloon: Provide a interface for "bubble hinting"

[Alexander Duyck]

On Wed, 2019-07-24 at 17:38 -0400, Michael S. Tsirkin wrote:
> On Wed, Jul 24, 2019 at 10:12:10AM -0700, Alexander Duyck wrote:
> > From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> > 
> > Add support for what I am referring to as "bubble hinting". Basically the
> > idea is to function very similar to how the balloon works in that we
> > basically end up madvising the page as not being used. However we don't
> > really need to bother with any deflate type logic since the page will be
> > faulted back into the guest when it is read or written to.
> > 
> > This is meant to be a simplification of the existing balloon interface
> > to use for providing hints to what memory needs to be freed. I am assuming
> > this is safe to do as the deflate logic does not actually appear to do very
> > much other than tracking what subpages have been released and which ones
> > haven't.
> > 
> > Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> 
> BTW I wonder about migration here.  When we migrate we lose all hints
> right?  Well destination could be smarter, detect that page is full of
> 0s and just map a zero page. Then we don't need a hint as such - but I
> don't think it's done like that ATM.

I was wondering about that a bit myself. If you migrate with a balloon
active what currently happens with the pages in the balloon? Do you
actually migrate them, or do you ignore them and just assume a zero page?
I'm just reusing the ram_block_discard_range logic that was being used for
the balloon inflation so I would assume the behavior would be the same.

> I also wonder about interaction with deflate.  ATM deflate will add
> pages to the free list, then balloon will come right back and report
> them as free.

I don't know how likely it is that somebody who is getting the free page
reporting is likely to want to also use the balloon to take up memory.
However hinting on a page that came out of deflate might make sense when
you consider that the balloon operates on 4K pages and the hints are on 2M
pages. You are likely going to lose track of it all anyway as you have to
work to merge the 4K pages up to the higher order page.

Re: [PATCH v2 QEMU] virtio-balloon: Provide a interface for "bubble hinting"

[Michael S. Tsirkin]

On Wed, Jul 24, 2019 at 03:03:56PM -0700, Alexander Duyck wrote:
> On Wed, 2019-07-24 at 17:38 -0400, Michael S. Tsirkin wrote:
> > On Wed, Jul 24, 2019 at 10:12:10AM -0700, Alexander Duyck wrote:
> > > From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> > > 
> > > Add support for what I am referring to as "bubble hinting". Basically the
> > > idea is to function very similar to how the balloon works in that we
> > > basically end up madvising the page as not being used. However we don't
> > > really need to bother with any deflate type logic since the page will be
> > > faulted back into the guest when it is read or written to.
> > > 
> > > This is meant to be a simplification of the existing balloon interface
> > > to use for providing hints to what memory needs to be freed. I am assuming
> > > this is safe to do as the deflate logic does not actually appear to do very
> > > much other than tracking what subpages have been released and which ones
> > > haven't.
> > > 
> > > Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> > 
> > BTW I wonder about migration here.  When we migrate we lose all hints
> > right?  Well destination could be smarter, detect that page is full of
> > 0s and just map a zero page. Then we don't need a hint as such - but I
> > don't think it's done like that ATM.
> 
> I was wondering about that a bit myself. If you migrate with a balloon
> active what currently happens with the pages in the balloon? Do you
> actually migrate them, or do you ignore them and just assume a zero page?

Ignore and assume zero page.

> I'm just reusing the ram_block_discard_range logic that was being used for
> the balloon inflation so I would assume the behavior would be the same.
> 
> > I also wonder about interaction with deflate.  ATM deflate will add
> > pages to the free list, then balloon will come right back and report
> > them as free.
> 
> I don't know how likely it is that somebody who is getting the free page
> reporting is likely to want to also use the balloon to take up memory.

Why not?

> However hinting on a page that came out of deflate might make sense when
> you consider that the balloon operates on 4K pages and the hints are on 2M
> pages. You are likely going to lose track of it all anyway as you have to
> work to merge the 4K pages up to the higher order page.

Right - we need to fix inflate/deflate anyway.
When we do, we can do whatever :)

-- 
MST

Re: [PATCH v2 QEMU] virtio-balloon: Provide a interface for "bubble hinting"

[Alexander Duyck]

On Wed, 2019-07-24 at 18:08 -0400, Michael S. Tsirkin wrote:
> On Wed, Jul 24, 2019 at 03:03:56PM -0700, Alexander Duyck wrote:
> > On Wed, 2019-07-24 at 17:38 -0400, Michael S. Tsirkin wrote:
> > > On Wed, Jul 24, 2019 at 10:12:10AM -0700, Alexander Duyck wrote:
> > > > From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> > > > 
> > > > Add support for what I am referring to as "bubble hinting". Basically the
> > > > idea is to function very similar to how the balloon works in that we
> > > > basically end up madvising the page as not being used. However we don't
> > > > really need to bother with any deflate type logic since the page will be
> > > > faulted back into the guest when it is read or written to.
> > > > 
> > > > This is meant to be a simplification of the existing balloon interface
> > > > to use for providing hints to what memory needs to be freed. I am assuming
> > > > this is safe to do as the deflate logic does not actually appear to do very
> > > > much other than tracking what subpages have been released and which ones
> > > > haven't.
> > > > 
> > > > Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> > > 
> > > BTW I wonder about migration here.  When we migrate we lose all hints
> > > right?  Well destination could be smarter, detect that page is full of
> > > 0s and just map a zero page. Then we don't need a hint as such - but I
> > > don't think it's done like that ATM.
> > 
> > I was wondering about that a bit myself. If you migrate with a balloon
> > active what currently happens with the pages in the balloon? Do you
> > actually migrate them, or do you ignore them and just assume a zero page?
> 
> Ignore and assume zero page.
> 
> > I'm just reusing the ram_block_discard_range logic that was being used for
> > the balloon inflation so I would assume the behavior would be the same.
> > 
> > > I also wonder about interaction with deflate.  ATM deflate will add
> > > pages to the free list, then balloon will come right back and report
> > > them as free.
> > 
> > I don't know how likely it is that somebody who is getting the free page
> > reporting is likely to want to also use the balloon to take up memory.
> 
> Why not?

The two functions are essentially doing the same thing. The only real
difference is enforcement. If the balloon takes the pages the guest cannot
get them back. I suppose there might be some advantage if you are wanting
for force shrink a guest but that would be about it.

> > However hinting on a page that came out of deflate might make sense when
> > you consider that the balloon operates on 4K pages and the hints are on 2M
> > pages. You are likely going to lose track of it all anyway as you have to
> > work to merge the 4K pages up to the higher order page.
> 
> Right - we need to fix inflate/deflate anyway.
> When we do, we can do whatever :)

One thing we could probably look at for the future would be to more
closely merge the balloon and this reporting logic. Ideally the balloon
would grab pages that were already hinted in order to enforce a certain
size limit on the guest, and then when it gave the pages back they would
retain their hinted status if possible.

The only problem is that right now both of those require that
hinting/reporting be active for the zone being accessed since we otherwise
don't have pointers to the pages at the head of the "hinted" list.

Re: [PATCH v2 QEMU] virtio-balloon: Provide a interface for "bubble hinting"

[Michael S. Tsirkin]

On Wed, Jul 24, 2019 at 03:27:37PM -0700, Alexander Duyck wrote:
> On Wed, 2019-07-24 at 18:08 -0400, Michael S. Tsirkin wrote:
> > On Wed, Jul 24, 2019 at 03:03:56PM -0700, Alexander Duyck wrote:
> > > On Wed, 2019-07-24 at 17:38 -0400, Michael S. Tsirkin wrote:
> > > > On Wed, Jul 24, 2019 at 10:12:10AM -0700, Alexander Duyck wrote:
> > > > > From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> > > > > 
> > > > > Add support for what I am referring to as "bubble hinting". Basically the
> > > > > idea is to function very similar to how the balloon works in that we
> > > > > basically end up madvising the page as not being used. However we don't
> > > > > really need to bother with any deflate type logic since the page will be
> > > > > faulted back into the guest when it is read or written to.
> > > > > 
> > > > > This is meant to be a simplification of the existing balloon interface
> > > > > to use for providing hints to what memory needs to be freed. I am assuming
> > > > > this is safe to do as the deflate logic does not actually appear to do very
> > > > > much other than tracking what subpages have been released and which ones
> > > > > haven't.
> > > > > 
> > > > > Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> > > > 
> > > > BTW I wonder about migration here.  When we migrate we lose all hints
> > > > right?  Well destination could be smarter, detect that page is full of
> > > > 0s and just map a zero page. Then we don't need a hint as such - but I
> > > > don't think it's done like that ATM.
> > > 
> > > I was wondering about that a bit myself. If you migrate with a balloon
> > > active what currently happens with the pages in the balloon? Do you
> > > actually migrate them, or do you ignore them and just assume a zero page?
> > 
> > Ignore and assume zero page.
> > 
> > > I'm just reusing the ram_block_discard_range logic that was being used for
> > > the balloon inflation so I would assume the behavior would be the same.
> > > 
> > > > I also wonder about interaction with deflate.  ATM deflate will add
> > > > pages to the free list, then balloon will come right back and report
> > > > them as free.
> > > 
> > > I don't know how likely it is that somebody who is getting the free page
> > > reporting is likely to want to also use the balloon to take up memory.
> > 
> > Why not?
> 
> The two functions are essentially doing the same thing. The only real
> difference is enforcement. If the balloon takes the pages the guest cannot
> get them back. I suppose there might be some advantage if you are wanting
> for force shrink a guest but that would be about it.

Yea, that's a common use of the balloon ATM. Helps partition
the host so guests don't conflict. OTOH deflate on oom thing
probably will never be used with hinting.

> > > However hinting on a page that came out of deflate might make sense when
> > > you consider that the balloon operates on 4K pages and the hints are on 2M
> > > pages. You are likely going to lose track of it all anyway as you have to
> > > work to merge the 4K pages up to the higher order page.
> > 
> > Right - we need to fix inflate/deflate anyway.
> > When we do, we can do whatever :)
> 
> One thing we could probably look at for the future would be to more
> closely merge the balloon and this reporting logic. Ideally the balloon
> would grab pages that were already hinted in order to enforce a certain
> size limit on the guest, and then when it gave the pages back they would
> retain their hinted status if possible.
> 
> The only problem is that right now both of those require that
> hinting/reporting be active for the zone being accessed since we otherwise
> don't have pointers to the pages at the head of the "hinted" list.

I guess I was talking about reworking host/guest ABI, you were
talking about the internals. So both need to change :)

Re: [PATCH v2 4/5] mm: Introduce Hinted pages

[David Hildenbrand]

On 24.07.19 19:03, Alexander Duyck wrote:
> From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> 
> In order to pave the way for free page hinting in virtualized environments
> we will need a way to get pages out of the free lists and identify those
> pages after they have been returned. To accomplish this, this patch adds
> the concept of a Hinted Buddy, which is essentially meant to just be the
> Offline page type used in conjunction with the Buddy page type.
> 
> It adds a set of pointers we shall call "boundary" which represents the
> upper boundary between the unhinted and hinted pages. The general idea is
> that in order for a page to cross from one side of the boundary to the
> other it will need to go through the hinting process. Ultimately a
> free_list has been fully processed when the boundary has been moved from
> the tail all they way up to occupying the first entry in the list.
> 
> Doing this we should be able to make certain that we keep the hinted
> pages as one contiguous block in each free list. This will allow us to
> efficiently manipulate the free lists whenever we need to go in and start
> sending hints to the hypervisor that there are new pages that have been
> freed and are no longer in use.
> 
> An added advantage to this approach is that we should be reducing the
> overall memory footprint of the guest as it will be more likely to recycle
> warm pages versus trying to allocate the hinted pages that were likely
> evicted from the guest memory.
> 
> Since we will only be hinting one zone at a time we keep the boundary
> limited to being defined for just the zone we are currently placing hinted
> pages into. Doing this we can keep the number of additional pointers needed
> quite small. To flag that the boundaries are in place we use a single bit
> in the zone to indicate that hinting and the boundaries are active.
> 
> The determination of when to start hinting is based on the tracking of the
> number of free pages in a given area versus the number of hinted pages in
> that area. We keep track of the number of hinted pages per free_area in a
> separate zone specific area. We do this to avoid modifying the free_area
> structure as this can lead to false sharing for the highest order with the
> zone lock which leads to a noticeable performance degradation.
> 
> Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> ---
>  include/linux/mmzone.h       |   40 +++++-
>  include/linux/page-flags.h   |    8 +
>  include/linux/page_hinting.h |  139 ++++++++++++++++++++
>  mm/Kconfig                   |    5 +
>  mm/Makefile                  |    1 
>  mm/memory_hotplug.c          |    1 
>  mm/page_alloc.c              |  136 ++++++++++++++++++-
>  mm/page_hinting.c            |  298 ++++++++++++++++++++++++++++++++++++++++++
>  8 files changed, 620 insertions(+), 8 deletions(-)
>  create mode 100644 include/linux/page_hinting.h
>  create mode 100644 mm/page_hinting.c
> 
> diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
> index f0c68b6b6154..42bdebb20484 100644
> --- a/include/linux/mmzone.h
> +++ b/include/linux/mmzone.h
> @@ -460,6 +460,14 @@ struct zone {
>  	seqlock_t		span_seqlock;
>  #endif
>  
> +#ifdef CONFIG_PAGE_HINTING
> +	/*
> +	 * Pointer to hinted page tracking statistics array. The size of
> +	 * the array is MAX_ORDER - PAGE_HINTING_MIN_ORDER. NULL when
> +	 * page hinting is not present.
> +	 */
> +	unsigned long		*hinted_pages;
> +#endif
>  	int initialized;
>  
>  	/* Write-intensive fields used from the page allocator */
> @@ -535,6 +543,14 @@ enum zone_flags {
>  	ZONE_BOOSTED_WATERMARK,		/* zone recently boosted watermarks.
>  					 * Cleared when kswapd is woken.
>  					 */
> +	ZONE_PAGE_HINTING_REQUESTED,	/* zone enabled page hinting and has
> +					 * requested flushing the data out of
> +					 * higher order pages.
> +					 */
> +	ZONE_PAGE_HINTING_ACTIVE,	/* zone enabled page hinting and is
> +					 * activly flushing the data out of
> +					 * higher order pages.
> +					 */
>  };
>  
>  static inline unsigned long zone_managed_pages(struct zone *zone)
> @@ -755,6 +771,8 @@ static inline bool pgdat_is_empty(pg_data_t *pgdat)
>  	return !pgdat->node_start_pfn && !pgdat->node_spanned_pages;
>  }
>  
> +#include <linux/page_hinting.h>
> +
>  /* Used for pages not on another list */
>  static inline void add_to_free_list(struct page *page, struct zone *zone,
>  				    unsigned int order, int migratetype)
> @@ -769,10 +787,16 @@ static inline void add_to_free_list(struct page *page, struct zone *zone,
>  static inline void add_to_free_list_tail(struct page *page, struct zone *zone,
>  					 unsigned int order, int migratetype)
>  {
> -	struct free_area *area = &zone->free_area[order];
> +	struct list_head *tail = get_unhinted_tail(zone, order, migratetype);
>  
> -	list_add_tail(&page->lru, &area->free_list[migratetype]);
> -	area->nr_free++;
> +	/*
> +	 * To prevent the unhinted pages from being interleaved with the
> +	 * hinted ones while we are actively processing pages we will use
> +	 * the head of the hinted pages to determine the tail of the free
> +	 * list.
> +	 */
> +	list_add_tail(&page->lru, tail);
> +	zone->free_area[order].nr_free++;
>  }
>  
>  /* Used for pages which are on another list */
> @@ -781,12 +805,22 @@ static inline void move_to_free_list(struct page *page, struct zone *zone,
>  {
>  	struct free_area *area = &zone->free_area[order];
>  
> +	/*
> +	 * Clear Hinted flag, if present, to avoid placing hinted pages
> +	 * at the top of the free_list. It is cheaper to just process this
> +	 * page again, then have to walk around a page that is already hinted.
> +	 */
> +	clear_page_hinted(page, zone);
> +
>  	list_move(&page->lru, &area->free_list[migratetype]);
>  }
>  
>  static inline void del_page_from_free_list(struct page *page, struct zone *zone,
>  					   unsigned int order)
>  {
> +	/* Clear Hinted flag, if present, before clearing the Buddy flag */
> +	clear_page_hinted(page, zone);
> +
>  	list_del(&page->lru);
>  	__ClearPageBuddy(page);
>  	set_page_private(page, 0);
> diff --git a/include/linux/page-flags.h b/include/linux/page-flags.h
> index b848517da64c..b753dbf673cb 100644
> --- a/include/linux/page-flags.h
> +++ b/include/linux/page-flags.h
> @@ -745,6 +745,14 @@ static inline int page_has_type(struct page *page)
>  PAGE_TYPE_OPS(Offline, offline)
>  
>  /*
> + * PageHinted() is an alias for Offline, however it is not meant to be an
> + * exclusive value. It should be combined with PageBuddy() when seen as it
> + * is meant to indicate that the page has been scrubbed while waiting in
> + * the buddy system.
> + */
> +PAGE_TYPE_OPS(Hinted, offline)


CCing Matthew

I am still not sure if I like the idea of having two page types at a time.

1. Once we run out of page type bits (which can happen easily looking at
it getting more and more user - e.g., maybe for vmmap pages soon), we
might want to convert again back to a value-based, not bit-based type
detection. This will certainly make this switch harder.

2. It will complicate the kexec/kdump handling. I assume it can be fixed
some way - e.g., making the elf interface aware of the exact notion of
page type bits compared to mapcount values we have right now (e.g.,
PAGE_BUDDY_MAPCOUNT_VALUE). Not addressed in this series yet.


Can't we reuse one of the traditional page flags for that, not used
along with buddy pages? E.g., PG_dirty: Pages that were not hinted yet
are dirty.

Matthew, what's your take?

-- 

Thanks,

David / dhildenb

Re: [PATCH v2 QEMU] virtio-balloon: Provide a interface for "bubble hinting"

[Nitesh Narayan Lal]

On 7/24/19 6:03 PM, Alexander Duyck wrote:
> On Wed, 2019-07-24 at 17:38 -0400, Michael S. Tsirkin wrote:
>> On Wed, Jul 24, 2019 at 10:12:10AM -0700, Alexander Duyck wrote:
>>> From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
>>>
>>> Add support for what I am referring to as "bubble hinting". Basically the
>>> idea is to function very similar to how the balloon works in that we
>>> basically end up madvising the page as not being used. However we don't
>>> really need to bother with any deflate type logic since the page will be
>>> faulted back into the guest when it is read or written to.
>>>
>>> This is meant to be a simplification of the existing balloon interface
>>> to use for providing hints to what memory needs to be freed. I am assuming
>>> this is safe to do as the deflate logic does not actually appear to do very
>>> much other than tracking what subpages have been released and which ones
>>> haven't.
>>>
>>> Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
>> BTW I wonder about migration here.  When we migrate we lose all hints
>> right?  Well destination could be smarter, detect that page is full of
>> 0s and just map a zero page. Then we don't need a hint as such - but I
>> don't think it's done like that ATM.
> I was wondering about that a bit myself. If you migrate with a balloon
> active what currently happens with the pages in the balloon? Do you
> actually migrate them, or do you ignore them and just assume a zero page?
> I'm just reusing the ram_block_discard_range logic that was being used for
> the balloon inflation so I would assume the behavior would be the same.
I agree, however, I think it is worth investigating to see if enabling hinting
adds some sort of overhead specifically in this kind of scenarios. What do you
think?
>> I also wonder about interaction with deflate.  ATM deflate will add
>> pages to the free list, then balloon will come right back and report
>> them as free.
> I don't know how likely it is that somebody who is getting the free page
> reporting is likely to want to also use the balloon to take up memory.
I think it is possible. There are two possibilities:
1. User has a workload running, which is allocating and freeing the pages and at
the same time, user deflates.
If these new pages get used by this workload, we don't have to worry as you are
already handling that by not hinting the free pages immediately.
2. Guest is idle and the user adds up some memory, for this situation what you
have explained below does seems reasonable.
> However hinting on a page that came out of deflate might make sense when
> you consider that the balloon operates on 4K pages and the hints are on 2M
> pages. You are likely going to lose track of it all anyway as you have to
> work to merge the 4K pages up to the higher order page.
>
-- 
Thanks
Nitesh

Re: [PATCH v2 4/5] mm: Introduce Hinted pages

[Nitesh Narayan Lal]

On 7/25/19 4:53 AM, David Hildenbrand wrote:
> On 24.07.19 19:03, Alexander Duyck wrote:
>> From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
>>
>> In order to pave the way for free page hinting in virtualized environments
>> we will need a way to get pages out of the free lists and identify those
>> pages after they have been returned. To accomplish this, this patch adds
>> the concept of a Hinted Buddy, which is essentially meant to just be the
>> Offline page type used in conjunction with the Buddy page type.
>>
>> It adds a set of pointers we shall call "boundary" which represents the
>> upper boundary between the unhinted and hinted pages. The general idea is
>> that in order for a page to cross from one side of the boundary to the
>> other it will need to go through the hinting process. Ultimately a
>> free_list has been fully processed when the boundary has been moved from
>> the tail all they way up to occupying the first entry in the list.
>>
>> Doing this we should be able to make certain that we keep the hinted
>> pages as one contiguous block in each free list. This will allow us to
>> efficiently manipulate the free lists whenever we need to go in and start
>> sending hints to the hypervisor that there are new pages that have been
>> freed and are no longer in use.
>>
>> An added advantage to this approach is that we should be reducing the
>> overall memory footprint of the guest as it will be more likely to recycle
>> warm pages versus trying to allocate the hinted pages that were likely
>> evicted from the guest memory.
>>
>> Since we will only be hinting one zone at a time we keep the boundary
>> limited to being defined for just the zone we are currently placing hinted
>> pages into. Doing this we can keep the number of additional pointers needed
>> quite small. To flag that the boundaries are in place we use a single bit
>> in the zone to indicate that hinting and the boundaries are active.
>>
>> The determination of when to start hinting is based on the tracking of the
>> number of free pages in a given area versus the number of hinted pages in
>> that area. We keep track of the number of hinted pages per free_area in a
>> separate zone specific area. We do this to avoid modifying the free_area
>> structure as this can lead to false sharing for the highest order with the
>> zone lock which leads to a noticeable performance degradation.
>>
>> Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
>> ---
>>  include/linux/mmzone.h       |   40 +++++-
>>  include/linux/page-flags.h   |    8 +
>>  include/linux/page_hinting.h |  139 ++++++++++++++++++++
>>  mm/Kconfig                   |    5 +
>>  mm/Makefile                  |    1 
>>  mm/memory_hotplug.c          |    1 
>>  mm/page_alloc.c              |  136 ++++++++++++++++++-
>>  mm/page_hinting.c            |  298 ++++++++++++++++++++++++++++++++++++++++++
>>  8 files changed, 620 insertions(+), 8 deletions(-)
>>  create mode 100644 include/linux/page_hinting.h
>>  create mode 100644 mm/page_hinting.c
>>
>> diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
>> index f0c68b6b6154..42bdebb20484 100644
>> --- a/include/linux/mmzone.h
>> +++ b/include/linux/mmzone.h
>> @@ -460,6 +460,14 @@ struct zone {
>>  	seqlock_t		span_seqlock;
>>  #endif
>>  
>> +#ifdef CONFIG_PAGE_HINTING
>> +	/*
>> +	 * Pointer to hinted page tracking statistics array. The size of
>> +	 * the array is MAX_ORDER - PAGE_HINTING_MIN_ORDER. NULL when
>> +	 * page hinting is not present.
>> +	 */
>> +	unsigned long		*hinted_pages;
>> +#endif
>>  	int initialized;
>>  
>>  	/* Write-intensive fields used from the page allocator */
>> @@ -535,6 +543,14 @@ enum zone_flags {
>>  	ZONE_BOOSTED_WATERMARK,		/* zone recently boosted watermarks.
>>  					 * Cleared when kswapd is woken.
>>  					 */
>> +	ZONE_PAGE_HINTING_REQUESTED,	/* zone enabled page hinting and has
>> +					 * requested flushing the data out of
>> +					 * higher order pages.
>> +					 */
>> +	ZONE_PAGE_HINTING_ACTIVE,	/* zone enabled page hinting and is
>> +					 * activly flushing the data out of
>> +					 * higher order pages.
>> +					 */
>>  };
>>  
>>  static inline unsigned long zone_managed_pages(struct zone *zone)
>> @@ -755,6 +771,8 @@ static inline bool pgdat_is_empty(pg_data_t *pgdat)
>>  	return !pgdat->node_start_pfn && !pgdat->node_spanned_pages;
>>  }
>>  
>> +#include <linux/page_hinting.h>
>> +
>>  /* Used for pages not on another list */
>>  static inline void add_to_free_list(struct page *page, struct zone *zone,
>>  				    unsigned int order, int migratetype)
>> @@ -769,10 +787,16 @@ static inline void add_to_free_list(struct page *page, struct zone *zone,
>>  static inline void add_to_free_list_tail(struct page *page, struct zone *zone,
>>  					 unsigned int order, int migratetype)
>>  {
>> -	struct free_area *area = &zone->free_area[order];
>> +	struct list_head *tail = get_unhinted_tail(zone, order, migratetype);
>>  
>> -	list_add_tail(&page->lru, &area->free_list[migratetype]);
>> -	area->nr_free++;
>> +	/*
>> +	 * To prevent the unhinted pages from being interleaved with the
>> +	 * hinted ones while we are actively processing pages we will use
>> +	 * the head of the hinted pages to determine the tail of the free
>> +	 * list.
>> +	 */
>> +	list_add_tail(&page->lru, tail);
>> +	zone->free_area[order].nr_free++;
>>  }
>>  
>>  /* Used for pages which are on another list */
>> @@ -781,12 +805,22 @@ static inline void move_to_free_list(struct page *page, struct zone *zone,
>>  {
>>  	struct free_area *area = &zone->free_area[order];
>>  
>> +	/*
>> +	 * Clear Hinted flag, if present, to avoid placing hinted pages
>> +	 * at the top of the free_list. It is cheaper to just process this
>> +	 * page again, then have to walk around a page that is already hinted.
>> +	 */
>> +	clear_page_hinted(page, zone);
>> +
>>  	list_move(&page->lru, &area->free_list[migratetype]);
>>  }
>>  
>>  static inline void del_page_from_free_list(struct page *page, struct zone *zone,
>>  					   unsigned int order)
>>  {
>> +	/* Clear Hinted flag, if present, before clearing the Buddy flag */
>> +	clear_page_hinted(page, zone);
>> +
>>  	list_del(&page->lru);
>>  	__ClearPageBuddy(page);
>>  	set_page_private(page, 0);
>> diff --git a/include/linux/page-flags.h b/include/linux/page-flags.h
>> index b848517da64c..b753dbf673cb 100644
>> --- a/include/linux/page-flags.h
>> +++ b/include/linux/page-flags.h
>> @@ -745,6 +745,14 @@ static inline int page_has_type(struct page *page)
>>  PAGE_TYPE_OPS(Offline, offline)
>>  
>>  /*
>> + * PageHinted() is an alias for Offline, however it is not meant to be an
>> + * exclusive value. It should be combined with PageBuddy() when seen as it
>> + * is meant to indicate that the page has been scrubbed while waiting in
>> + * the buddy system.
>> + */
>> +PAGE_TYPE_OPS(Hinted, offline)
>
> CCing Matthew
>
> I am still not sure if I like the idea of having two page types at a time.
>
> 1. Once we run out of page type bits (which can happen easily looking at
> it getting more and more user - e.g., maybe for vmmap pages soon), we
> might want to convert again back to a value-based, not bit-based type
> detection. This will certainly make this switch harder.
>
> 2. It will complicate the kexec/kdump handling. I assume it can be fixed
> some way - e.g., making the elf interface aware of the exact notion of
> page type bits compared to mapcount values we have right now (e.g.,
> PAGE_BUDDY_MAPCOUNT_VALUE). Not addressed in this series yet.
>
>
> Can't we reuse one of the traditional page flags for that, not used
> along with buddy pages? E.g., PG_dirty: Pages that were not hinted yet
> are dirty.

Will it not conflict with the regular use case of PG_dirty bit somehow?


> Matthew, what's your take?
>
-- 
Thanks
Nitesh

Re: [PATCH v2 4/5] mm: Introduce Hinted pages

[David Hildenbrand]

On 25.07.19 13:46, Nitesh Narayan Lal wrote:
> 
> On 7/25/19 4:53 AM, David Hildenbrand wrote:
>> On 24.07.19 19:03, Alexander Duyck wrote:
>>> From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
>>>
>>> In order to pave the way for free page hinting in virtualized environments
>>> we will need a way to get pages out of the free lists and identify those
>>> pages after they have been returned. To accomplish this, this patch adds
>>> the concept of a Hinted Buddy, which is essentially meant to just be the
>>> Offline page type used in conjunction with the Buddy page type.
>>>
>>> It adds a set of pointers we shall call "boundary" which represents the
>>> upper boundary between the unhinted and hinted pages. The general idea is
>>> that in order for a page to cross from one side of the boundary to the
>>> other it will need to go through the hinting process. Ultimately a
>>> free_list has been fully processed when the boundary has been moved from
>>> the tail all they way up to occupying the first entry in the list.
>>>
>>> Doing this we should be able to make certain that we keep the hinted
>>> pages as one contiguous block in each free list. This will allow us to
>>> efficiently manipulate the free lists whenever we need to go in and start
>>> sending hints to the hypervisor that there are new pages that have been
>>> freed and are no longer in use.
>>>
>>> An added advantage to this approach is that we should be reducing the
>>> overall memory footprint of the guest as it will be more likely to recycle
>>> warm pages versus trying to allocate the hinted pages that were likely
>>> evicted from the guest memory.
>>>
>>> Since we will only be hinting one zone at a time we keep the boundary
>>> limited to being defined for just the zone we are currently placing hinted
>>> pages into. Doing this we can keep the number of additional pointers needed
>>> quite small. To flag that the boundaries are in place we use a single bit
>>> in the zone to indicate that hinting and the boundaries are active.
>>>
>>> The determination of when to start hinting is based on the tracking of the
>>> number of free pages in a given area versus the number of hinted pages in
>>> that area. We keep track of the number of hinted pages per free_area in a
>>> separate zone specific area. We do this to avoid modifying the free_area
>>> structure as this can lead to false sharing for the highest order with the
>>> zone lock which leads to a noticeable performance degradation.
>>>
>>> Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
>>> ---
>>>  include/linux/mmzone.h       |   40 +++++-
>>>  include/linux/page-flags.h   |    8 +
>>>  include/linux/page_hinting.h |  139 ++++++++++++++++++++
>>>  mm/Kconfig                   |    5 +
>>>  mm/Makefile                  |    1 
>>>  mm/memory_hotplug.c          |    1 
>>>  mm/page_alloc.c              |  136 ++++++++++++++++++-
>>>  mm/page_hinting.c            |  298 ++++++++++++++++++++++++++++++++++++++++++
>>>  8 files changed, 620 insertions(+), 8 deletions(-)
>>>  create mode 100644 include/linux/page_hinting.h
>>>  create mode 100644 mm/page_hinting.c
>>>
>>> diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
>>> index f0c68b6b6154..42bdebb20484 100644
>>> --- a/include/linux/mmzone.h
>>> +++ b/include/linux/mmzone.h
>>> @@ -460,6 +460,14 @@ struct zone {
>>>  	seqlock_t		span_seqlock;
>>>  #endif
>>>  
>>> +#ifdef CONFIG_PAGE_HINTING
>>> +	/*
>>> +	 * Pointer to hinted page tracking statistics array. The size of
>>> +	 * the array is MAX_ORDER - PAGE_HINTING_MIN_ORDER. NULL when
>>> +	 * page hinting is not present.
>>> +	 */
>>> +	unsigned long		*hinted_pages;
>>> +#endif
>>>  	int initialized;
>>>  
>>>  	/* Write-intensive fields used from the page allocator */
>>> @@ -535,6 +543,14 @@ enum zone_flags {
>>>  	ZONE_BOOSTED_WATERMARK,		/* zone recently boosted watermarks.
>>>  					 * Cleared when kswapd is woken.
>>>  					 */
>>> +	ZONE_PAGE_HINTING_REQUESTED,	/* zone enabled page hinting and has
>>> +					 * requested flushing the data out of
>>> +					 * higher order pages.
>>> +					 */
>>> +	ZONE_PAGE_HINTING_ACTIVE,	/* zone enabled page hinting and is
>>> +					 * activly flushing the data out of
>>> +					 * higher order pages.
>>> +					 */
>>>  };
>>>  
>>>  static inline unsigned long zone_managed_pages(struct zone *zone)
>>> @@ -755,6 +771,8 @@ static inline bool pgdat_is_empty(pg_data_t *pgdat)
>>>  	return !pgdat->node_start_pfn && !pgdat->node_spanned_pages;
>>>  }
>>>  
>>> +#include <linux/page_hinting.h>
>>> +
>>>  /* Used for pages not on another list */
>>>  static inline void add_to_free_list(struct page *page, struct zone *zone,
>>>  				    unsigned int order, int migratetype)
>>> @@ -769,10 +787,16 @@ static inline void add_to_free_list(struct page *page, struct zone *zone,
>>>  static inline void add_to_free_list_tail(struct page *page, struct zone *zone,
>>>  					 unsigned int order, int migratetype)
>>>  {
>>> -	struct free_area *area = &zone->free_area[order];
>>> +	struct list_head *tail = get_unhinted_tail(zone, order, migratetype);
>>>  
>>> -	list_add_tail(&page->lru, &area->free_list[migratetype]);
>>> -	area->nr_free++;
>>> +	/*
>>> +	 * To prevent the unhinted pages from being interleaved with the
>>> +	 * hinted ones while we are actively processing pages we will use
>>> +	 * the head of the hinted pages to determine the tail of the free
>>> +	 * list.
>>> +	 */
>>> +	list_add_tail(&page->lru, tail);
>>> +	zone->free_area[order].nr_free++;
>>>  }
>>>  
>>>  /* Used for pages which are on another list */
>>> @@ -781,12 +805,22 @@ static inline void move_to_free_list(struct page *page, struct zone *zone,
>>>  {
>>>  	struct free_area *area = &zone->free_area[order];
>>>  
>>> +	/*
>>> +	 * Clear Hinted flag, if present, to avoid placing hinted pages
>>> +	 * at the top of the free_list. It is cheaper to just process this
>>> +	 * page again, then have to walk around a page that is already hinted.
>>> +	 */
>>> +	clear_page_hinted(page, zone);
>>> +
>>>  	list_move(&page->lru, &area->free_list[migratetype]);
>>>  }
>>>  
>>>  static inline void del_page_from_free_list(struct page *page, struct zone *zone,
>>>  					   unsigned int order)
>>>  {
>>> +	/* Clear Hinted flag, if present, before clearing the Buddy flag */
>>> +	clear_page_hinted(page, zone);
>>> +
>>>  	list_del(&page->lru);
>>>  	__ClearPageBuddy(page);
>>>  	set_page_private(page, 0);
>>> diff --git a/include/linux/page-flags.h b/include/linux/page-flags.h
>>> index b848517da64c..b753dbf673cb 100644
>>> --- a/include/linux/page-flags.h
>>> +++ b/include/linux/page-flags.h
>>> @@ -745,6 +745,14 @@ static inline int page_has_type(struct page *page)
>>>  PAGE_TYPE_OPS(Offline, offline)
>>>  
>>>  /*
>>> + * PageHinted() is an alias for Offline, however it is not meant to be an
>>> + * exclusive value. It should be combined with PageBuddy() when seen as it
>>> + * is meant to indicate that the page has been scrubbed while waiting in
>>> + * the buddy system.
>>> + */
>>> +PAGE_TYPE_OPS(Hinted, offline)
>>
>> CCing Matthew
>>
>> I am still not sure if I like the idea of having two page types at a time.
>>
>> 1. Once we run out of page type bits (which can happen easily looking at
>> it getting more and more user - e.g., maybe for vmmap pages soon), we
>> might want to convert again back to a value-based, not bit-based type
>> detection. This will certainly make this switch harder.
>>
>> 2. It will complicate the kexec/kdump handling. I assume it can be fixed
>> some way - e.g., making the elf interface aware of the exact notion of
>> page type bits compared to mapcount values we have right now (e.g.,
>> PAGE_BUDDY_MAPCOUNT_VALUE). Not addressed in this series yet.
>>
>>
>> Can't we reuse one of the traditional page flags for that, not used
>> along with buddy pages? E.g., PG_dirty: Pages that were not hinted yet
>> are dirty.
> 
> Will it not conflict with the regular use case of PG_dirty bit somehow?

AFAIK it is primarily used for pagecache pages only, so never with pages
in the buddy. Unfortunately, page-flags.h lacks proper documentation.

-- 

Thanks,

David / dhildenb

Re: [PATCH v2 QEMU] virtio-balloon: Provide a interface for "bubble hinting"

[Nitesh Narayan Lal]

On 7/24/19 4:18 PM, Alexander Duyck wrote:
> On Wed, 2019-07-24 at 15:02 -0400, Michael S. Tsirkin wrote:
>> On Wed, Jul 24, 2019 at 10:12:10AM -0700, Alexander Duyck wrote:
>>> From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
>>>
>>> Add support for what I am referring to as "bubble hinting". Basically the
>>> idea is to function very similar to how the balloon works in that we
>>> basically end up madvising the page as not being used. However we don't
>>> really need to bother with any deflate type logic since the page will be
>>> faulted back into the guest when it is read or written to.
>>>
>>> This is meant to be a simplification of the existing balloon interface
>>> to use for providing hints to what memory needs to be freed. I am assuming
>>> this is safe to do as the deflate logic does not actually appear to do very
>>> much other than tracking what subpages have been released and which ones
>>> haven't.
>>>
>>> Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
>>> ---
>>>  hw/virtio/virtio-balloon.c                      |   40 +++++++++++++++++++++++
>>>  include/hw/virtio/virtio-balloon.h              |    2 +
>>>  include/standard-headers/linux/virtio_balloon.h |    1 +
>>>  3 files changed, 42 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/hw/virtio/virtio-balloon.c b/hw/virtio/virtio-balloon.c
>>> index 2112874055fb..70c0004c0f88 100644
>>> --- a/hw/virtio/virtio-balloon.c
>>> +++ b/hw/virtio/virtio-balloon.c
>>> @@ -328,6 +328,39 @@ static void balloon_stats_set_poll_interval(Object *obj, Visitor *v,
>>>      balloon_stats_change_timer(s, 0);
>>>  }
>>>  
>>> +static void virtio_bubble_handle_output(VirtIODevice *vdev, VirtQueue *vq)
>>> +{
>>> +    VirtQueueElement *elem;
>>> +
>>> +    while ((elem = virtqueue_pop(vq, sizeof(VirtQueueElement)))) {
>>> +    	unsigned int i;
>>> +
>>> +        for (i = 0; i < elem->in_num; i++) {
>>> +            void *addr = elem->in_sg[i].iov_base;
>>> +            size_t size = elem->in_sg[i].iov_len;
>>> +            ram_addr_t ram_offset;
>>> +            size_t rb_page_size;
>>> +            RAMBlock *rb;
>>> +
>>> +            if (qemu_balloon_is_inhibited())
>>> +                continue;
>>> +
>>> +            rb = qemu_ram_block_from_host(addr, false, &ram_offset);
>>> +            rb_page_size = qemu_ram_pagesize(rb);
>>> +
>>> +            /* For now we will simply ignore unaligned memory regions */
>>> +            if ((ram_offset | size) & (rb_page_size - 1))
>>> +                continue;
>>> +
>>> +            ram_block_discard_range(rb, ram_offset, size);
>> I suspect this needs to do like the migration type of
>> hinting and get disabled if page poisoning is in effect.
>> Right?
> Shouldn't something like that end up getting handled via
> qemu_balloon_is_inhibited, or did I miss something there? I assumed cases
> like that would end up setting qemu_balloon_is_inhibited to true, if that
> isn't the case then I could add some additional conditions. I would do it
> in about the same spot as the qemu_balloon_is_inhibited check.


Just wondering if you have tried running these patches in an environment with
directly assigned devices? Ideally, I would expect qemu_balloon_is_inhibited()
to take care of it.


>
>
-- 
Thanks
Nitesh

Re: [PATCH v2 0/5] mm / virtio: Provide support for page hinting

[Nitesh Narayan Lal]

On 7/24/19 5:00 PM, Alexander Duyck wrote:
> On Wed, 2019-07-24 at 16:38 -0400, Nitesh Narayan Lal wrote:
>> On 7/24/19 4:27 PM, Alexander Duyck wrote:
>>> On Wed, 2019-07-24 at 14:40 -0400, Nitesh Narayan Lal wrote:
>>>> On 7/24/19 12:54 PM, 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 page hinting
>>>>>
>>>>> The functionality for this is fairly simple. When enabled it will allocate
>>>>> statistics to track the number of hinted pages in a given free area. When
>>>>> the number of free pages exceeds this value plus a high water value,
>>>>> currently 32,
>>>> Shouldn't we configure this to a lower number such as 16?
>>> Yes, we could do 16.
>>>
>>>>>  it will begin performing page hinting which consists of
>>>>> pulling pages off of free list and placing them into a scatter list. The
>>>>> scatterlist is then given to the page hinting device and it will perform
>>>>> the required action to make the pages "hinted", in the case of
>>>>> virtio-balloon this results in the pages being madvised as MADV_DONTNEED
>>>>> and as such they are forced out of the guest. After this they are placed
>>>>> back on the free list, and an additional bit is added if they are not
>>>>> merged indicating that they are a hinted buddy page instead of a standard
>>>>> buddy page. The cycle then repeats with additional non-hinted pages being
>>>>> pulled until the free areas all consist of hinted pages.
>>>>>
>>>>> I am leaving a number of things hard-coded such as limiting the lowest
>>>>> order processed to PAGEBLOCK_ORDER,
>>>> Have you considered making this option configurable at the compile time?
>>> We could. However, PAGEBLOCK_ORDER is already configurable on some
>>> architectures. I didn't see much point in making it configurable in the
>>> case of x86 as there are only really 2 orders that this could be used in
>>> that provided good performance and that MAX_ORDER - 1 and PAGEBLOCK_ORDER.
>>>
>>>>>  and have left it up to the guest to
>>>>> determine what the limit is on how many pages it wants to allocate to
>>>>> process the hints.
>>>> It might make sense to set the number of pages to be hinted at a time from the
>>>> hypervisor.
>>> We could do that. Although I would still want some upper limit on that as
>>> I would prefer to keep the high water mark as a static value since it is
>>> used in an inline function. Currently the virtio driver is the one
>>> defining the capacity of pages per request.
>> For the upper limit I think we can rely on max vq size. Isn't?
> I would still want to limit how many pages could be pulled. Otherwise we
> have the risk of a hypervisor that allocates a vq size of 1024 or
> something like that and with 4M pages that could essentially OOM a 4G
> guest.
>
> That is why I figure what we probably should do is base the upper limit of
> either 16 or 32 so that we only have at most something like 64M or 128M of
> memory being held by the driver while it is being "reported". If we leave
> spare room in the ring so be it, better that then triggering unneeded OOM
> conditions.
>
>>>>> My primary testing has just been to verify the memory is being freed after
>>>>> allocation by running memhog 79g on a 80g 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 at most a 2% difference between the base
>>>>> kernel without these patches and the patches with virtio-balloon disabled.
>>>>> With the patches and virtio-balloon enabled with hinting the results
>>>>> largely depend on the host kernel. On a 3.10 RHEL kernel I saw up to a 2%
>>>>> drop in performance as I approached 16 threads,
>>>> I think this is acceptable.
>>>>>  however on the the lastest
>>>>> linux-next kernel I saw roughly a 4% to 5% improvement in performance for
>>>>> all tests with 8 or more threads. 
>>>> Do you mean that with your patches the will-it-scale/page_fault1 numbers were
>>>> better by 4-5% over an unmodified kernel?
>>> Yes. That is the odd thing. I am wondering if there was some improvement
>>> in the zeroing of THP pages or something that is somehow improving the
>>> cache performance for the accessing of the pages by the test in the guest.
>> The values you were observing on an unmodified kernel, were they consistent over
>> fresh reboot?
>> Do you have any sort of workload running in the host as that could also impact
>> the numbers.
> The host was an unmodified linux-next kernel. What I was doing is I would
> reboot, load the guest run one kernel, swap the kernel in the guest and
> just reboot the guest, run the next kernel, and then switch back to the
> first kernel to make certain there wasn't anything that changed between
> the runs.


As long as the host kernel and environment remain the same for the guest kernel
with hinting patches and without hinting patches. We should be fine in comparing
the two? We would expect the will-it-scale/page_fault1 number in these two cases
to be close to one another.


>
> I still need to do more research though. I'm still suspecting it has
> something to do with the page zeroing on faults though as that was what
> was showing up on a perf top when we hit about 8 or more threads active in
> the guest.
>>>>> I believe the difference seen is due to
>>>>> the overhead for faulting pages back into the guest and zeroing of memory.
>>>> It may also make sense to test these patches with netperf to observe how much
>>>> performance drop it is introducing.
>>> Do you have some test you were already using? I ask because I am not sure
>>> netperf would generate a large enough memory window size to really trigger
>>> much of a change in terms of hinting. If you have some test in mind I
>>> could probably set it up and run it pretty quick.
>> Earlier I have tried running netperf on a guest with 2 cores, i.e., netserver
>> pinned to one and netperf running on the other.
>> You have to specify a really large packet size and run the test for at least
>> 15-30 minutes to actually see some hinting work.
> I can take a look. I am not expecting much though.
>
>>>>> Patch 4 is a bit on the large side at about 600 lines of change, however
>>>>> I really didn't see a good way to break it up since each piece feeds into
>>>>> the next. So I couldn't add the statistics by themselves as it didn't
>>>>> really make sense to add them without something that will either read or
>>>>> increment/decrement them, or add the Hinted state without something that
>>>>> would set/unset it. As such I just ended up adding the entire thing as
>>>>> one patch. It makes it a bit bigger but avoids the issues in the previous
>>>>> set where I was referencing things before they had been added.
>>>>>
>>>>> Changes from the RFC:
>>>>> https://lore.kernel.org/lkml/20190530215223.13974.22445.stgit@localhost.localdomain/
>>>>> Moved aeration requested flag out of aerator and into zone->flags.
>>>>> Moved bounary 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.
>>>>>
>>>>> Changes from v1:
>>>>> https://lore.kernel.org/lkml/20190619222922.1231.27432.stgit@localhost.localdomain/
>>>>> Dropped "waste page treatment" in favor of "page hinting"
>>>> We may still have to try and find a better name for virtio-balloon side changes.
>>>> As "FREE_PAGE_HINT" and "PAGE_HINTING" are still confusing.
>>> We just need to settle on a name. Essentially all this requires is just a
>>> quick find and replace with whatever name we decide on.
>> I agree.
> I will probably look at seeing if I can keep the kernel feature as free
> page hinting and just make the virtio feature page reporting. It should be
> pretty straight forward as I could just replace the mentions of react with
> report and only have to tweak a few bits of patch 5.


I still think that we should stick with the same name for the kernel and the
virtio. But as you said this is not a blocker and the just requires a quick find
and replace.


>
-- 
Thanks
Nitesh

Re: [PATCH v2 5/5] virtio-balloon: Add support for providing page hints to host

[Nitesh Narayan Lal]

On 7/24/19 3:02 PM, Michael S. Tsirkin wrote:
> On Wed, Jul 24, 2019 at 10:05:14AM -0700, Alexander Duyck wrote:
>> From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
>>
>> Add support for the page hinting feature provided by virtio-balloon.
>> Hinting differs from the regular balloon functionality in that is is
>> much less durable than a standard memory balloon. Instead of creating a
>> list of pages that cannot be accessed the pages are only inaccessible
>> while they are being indicated to the virtio interface. Once the
>> interface has acknowledged them they are placed back into their respective
>> free lists and are once again accessible by the guest system.
>>
>> Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> Looking at the design, it seems that hinted pages can immediately be
> reused. I wonder how we can efficiently support this
> with kvm when poisoning is in effect. Of course we can just
> ignore the poison. However it seems cleaner to
> 1. verify page is poisoned with the correct value
> 2. fill the page with the correct value on fault
>
> Requirement 2 requires some kind of madvise that
> will save the poison e.g. in the VMA.
>
> Not a blocker for sure ... 
>
>
>> ---
>>  drivers/virtio/Kconfig              |    1 +
>>  drivers/virtio/virtio_balloon.c     |   47 +++++++++++++++++++++++++++++++++++
>>  include/uapi/linux/virtio_balloon.h |    1 +
>>  3 files changed, 49 insertions(+)
>>
>> diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig
>> index 078615cf2afc..d45556ae1f81 100644
>> --- a/drivers/virtio/Kconfig
>> +++ b/drivers/virtio/Kconfig
>> @@ -58,6 +58,7 @@ config VIRTIO_BALLOON
>>  	tristate "Virtio balloon driver"
>>  	depends on VIRTIO
>>  	select MEMORY_BALLOON
>> +	select PAGE_HINTING
>>  	---help---
>>  	 This driver supports increasing and decreasing the amount
>>  	 of memory within a KVM guest.
>> diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
>> index 226fbb995fb0..dee9f8f3ad09 100644
>> --- a/drivers/virtio/virtio_balloon.c
>> +++ b/drivers/virtio/virtio_balloon.c
>> @@ -19,6 +19,7 @@
>>  #include <linux/mount.h>
>>  #include <linux/magic.h>
>>  #include <linux/pseudo_fs.h>
>> +#include <linux/page_hinting.h>
>>  
>>  /*
>>   * Balloon device works in 4K page units.  So each page is pointed to by
>> @@ -27,6 +28,7 @@
>>   */
>>  #define VIRTIO_BALLOON_PAGES_PER_PAGE (unsigned)(PAGE_SIZE >> VIRTIO_BALLOON_PFN_SHIFT)
>>  #define VIRTIO_BALLOON_ARRAY_PFNS_MAX 256
>> +#define VIRTIO_BALLOON_ARRAY_HINTS_MAX	32
>>  #define VIRTBALLOON_OOM_NOTIFY_PRIORITY 80
>>  
>>  #define VIRTIO_BALLOON_FREE_PAGE_ALLOC_FLAG (__GFP_NORETRY | __GFP_NOWARN | \
>> @@ -46,6 +48,7 @@ enum virtio_balloon_vq {
>>  	VIRTIO_BALLOON_VQ_DEFLATE,
>>  	VIRTIO_BALLOON_VQ_STATS,
>>  	VIRTIO_BALLOON_VQ_FREE_PAGE,
>> +	VIRTIO_BALLOON_VQ_HINTING,
>>  	VIRTIO_BALLOON_VQ_MAX
>>  };
>>  
>> @@ -113,6 +116,10 @@ struct virtio_balloon {
>>  
>>  	/* To register a shrinker to shrink memory upon memory pressure */
>>  	struct shrinker shrinker;
>> +
>> +	/* Unused page hinting device */
>> +	struct virtqueue *hinting_vq;
>> +	struct page_hinting_dev_info ph_dev_info;
>>  };
>>  
>>  static struct virtio_device_id id_table[] = {
>> @@ -152,6 +159,22 @@ static void tell_host(struct virtio_balloon *vb, struct virtqueue *vq)
>>  
>>  }
>>  
>> +void virtballoon_page_hinting_react(struct page_hinting_dev_info *ph_dev_info,
>> +				    unsigned int num_hints)
>> +{
>> +	struct virtio_balloon *vb =
>> +		container_of(ph_dev_info, struct virtio_balloon, ph_dev_info);
>> +	struct virtqueue *vq = vb->hinting_vq;
>> +	unsigned int unused;
>> +
>> +	/* We should always be able to add these buffers to an empty queue. */
>
> can be an out of memory condition, and then ...

Do we need an error check here?

For situations where this fails we should disable hinting completely, maybe?


>
>> +	virtqueue_add_inbuf(vq, ph_dev_info->sg, num_hints, vb, GFP_KERNEL);
>> +	virtqueue_kick(vq);
> ... this will block forever.
>
>> +	/* When host has read buffer, this completes via balloon_ack */
>> +	wait_event(vb->acked, virtqueue_get_buf(vq, &unused));
> However below I suggest limiting capacity which will solve
> this problem for you.
>
>
>
>> +}
>> +
>>  static void set_page_pfns(struct virtio_balloon *vb,
>>  			  __virtio32 pfns[], struct page *page)
>>  {
>> @@ -476,6 +499,7 @@ static int init_vqs(struct virtio_balloon *vb)
>>  	names[VIRTIO_BALLOON_VQ_DEFLATE] = "deflate";
>>  	names[VIRTIO_BALLOON_VQ_STATS] = NULL;
>>  	names[VIRTIO_BALLOON_VQ_FREE_PAGE] = NULL;
>> +	names[VIRTIO_BALLOON_VQ_HINTING] = NULL;
>>  
>>  	if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_STATS_VQ)) {
>>  		names[VIRTIO_BALLOON_VQ_STATS] = "stats";
>> @@ -487,11 +511,19 @@ static int init_vqs(struct virtio_balloon *vb)
>>  		callbacks[VIRTIO_BALLOON_VQ_FREE_PAGE] = NULL;
>>  	}
>>  
>> +	if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_HINTING)) {
>> +		names[VIRTIO_BALLOON_VQ_HINTING] = "hinting_vq";
>> +		callbacks[VIRTIO_BALLOON_VQ_HINTING] = balloon_ack;
>> +	}
>> +
>>  	err = vb->vdev->config->find_vqs(vb->vdev, VIRTIO_BALLOON_VQ_MAX,
>>  					 vqs, callbacks, names, NULL, NULL);
>>  	if (err)
>>  		return err;
>>  
>> +	if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_HINTING))
>> +		vb->hinting_vq = vqs[VIRTIO_BALLOON_VQ_HINTING];
>> +
>>  	vb->inflate_vq = vqs[VIRTIO_BALLOON_VQ_INFLATE];
>>  	vb->deflate_vq = vqs[VIRTIO_BALLOON_VQ_DEFLATE];
>>  	if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_STATS_VQ)) {
>> @@ -924,12 +956,24 @@ static int virtballoon_probe(struct virtio_device *vdev)
>>  		if (err)
>>  			goto out_del_balloon_wq;
>>  	}
>> +
>> +	vb->ph_dev_info.react = virtballoon_page_hinting_react;
>> +	vb->ph_dev_info.capacity = VIRTIO_BALLOON_ARRAY_HINTS_MAX;
> As explained above I think you should limit this by vq size.
> Otherwise virtqueue add buf might fail.
> In fact by struct spec reading you need to limit it
> anyway otherwise it will fail unconditionally.
> In practice on most hypervisors it will typically work ...
>
>> +	if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_HINTING)) {
>> +		err = page_hinting_startup(&vb->ph_dev_info);
>> +		if (err)
>> +			goto out_unregister_shrinker;
>> +	}
>> +
>>  	virtio_device_ready(vdev);
>>  
>>  	if (towards_target(vb))
>>  		virtballoon_changed(vdev);
>>  	return 0;
>>  
>> +out_unregister_shrinker:
>> +	if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_DEFLATE_ON_OOM))
>> +		virtio_balloon_unregister_shrinker(vb);
>>  out_del_balloon_wq:
>>  	if (virtio_has_feature(vdev, VIRTIO_BALLOON_F_FREE_PAGE_HINT))
>>  		destroy_workqueue(vb->balloon_wq);
>> @@ -958,6 +1002,8 @@ static void virtballoon_remove(struct virtio_device *vdev)
>>  {
>>  	struct virtio_balloon *vb = vdev->priv;
>>  
>> +	if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_HINTING))
>> +		page_hinting_shutdown(&vb->ph_dev_info);
>>  	if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_DEFLATE_ON_OOM))
>>  		virtio_balloon_unregister_shrinker(vb);
>>  	spin_lock_irq(&vb->stop_update_lock);
>> @@ -1027,6 +1073,7 @@ static int virtballoon_validate(struct virtio_device *vdev)
>>  	VIRTIO_BALLOON_F_DEFLATE_ON_OOM,
>>  	VIRTIO_BALLOON_F_FREE_PAGE_HINT,
>>  	VIRTIO_BALLOON_F_PAGE_POISON,
>> +	VIRTIO_BALLOON_F_HINTING,
>>  };
>>  
>>  static struct virtio_driver virtio_balloon_driver = {
>> diff --git a/include/uapi/linux/virtio_balloon.h b/include/uapi/linux/virtio_balloon.h
>> index a1966cd7b677..2b0f62814e22 100644
>> --- a/include/uapi/linux/virtio_balloon.h
>> +++ b/include/uapi/linux/virtio_balloon.h
>> @@ -36,6 +36,7 @@
>>  #define VIRTIO_BALLOON_F_DEFLATE_ON_OOM	2 /* Deflate balloon on OOM */
>>  #define VIRTIO_BALLOON_F_FREE_PAGE_HINT	3 /* VQ to report free pages */
>>  #define VIRTIO_BALLOON_F_PAGE_POISON	4 /* Guest is using page poisoning */
>> +#define VIRTIO_BALLOON_F_HINTING	5 /* Page hinting virtqueue */
>>  
>>  /* Size of a PFN in the balloon interface. */
>>  #define VIRTIO_BALLOON_PFN_SHIFT 12
-- 
Thanks
Nitesh

Re: [PATCH v2 5/5] virtio-balloon: Add support for providing page hints to host

[Michael S. Tsirkin]

On Thu, Jul 25, 2019 at 10:44:01AM -0400, Nitesh Narayan Lal wrote:
> 
> On 7/24/19 3:02 PM, Michael S. Tsirkin wrote:
> > On Wed, Jul 24, 2019 at 10:05:14AM -0700, Alexander Duyck wrote:
> >> From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> >>
> >> Add support for the page hinting feature provided by virtio-balloon.
> >> Hinting differs from the regular balloon functionality in that is is
> >> much less durable than a standard memory balloon. Instead of creating a
> >> list of pages that cannot be accessed the pages are only inaccessible
> >> while they are being indicated to the virtio interface. Once the
> >> interface has acknowledged them they are placed back into their respective
> >> free lists and are once again accessible by the guest system.
> >>
> >> Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> > Looking at the design, it seems that hinted pages can immediately be
> > reused. I wonder how we can efficiently support this
> > with kvm when poisoning is in effect. Of course we can just
> > ignore the poison. However it seems cleaner to
> > 1. verify page is poisoned with the correct value
> > 2. fill the page with the correct value on fault
> >
> > Requirement 2 requires some kind of madvise that
> > will save the poison e.g. in the VMA.
> >
> > Not a blocker for sure ... 
> >
> >
> >> ---
> >>  drivers/virtio/Kconfig              |    1 +
> >>  drivers/virtio/virtio_balloon.c     |   47 +++++++++++++++++++++++++++++++++++
> >>  include/uapi/linux/virtio_balloon.h |    1 +
> >>  3 files changed, 49 insertions(+)
> >>
> >> diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig
> >> index 078615cf2afc..d45556ae1f81 100644
> >> --- a/drivers/virtio/Kconfig
> >> +++ b/drivers/virtio/Kconfig
> >> @@ -58,6 +58,7 @@ config VIRTIO_BALLOON
> >>  	tristate "Virtio balloon driver"
> >>  	depends on VIRTIO
> >>  	select MEMORY_BALLOON
> >> +	select PAGE_HINTING
> >>  	---help---
> >>  	 This driver supports increasing and decreasing the amount
> >>  	 of memory within a KVM guest.
> >> diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
> >> index 226fbb995fb0..dee9f8f3ad09 100644
> >> --- a/drivers/virtio/virtio_balloon.c
> >> +++ b/drivers/virtio/virtio_balloon.c
> >> @@ -19,6 +19,7 @@
> >>  #include <linux/mount.h>
> >>  #include <linux/magic.h>
> >>  #include <linux/pseudo_fs.h>
> >> +#include <linux/page_hinting.h>
> >>  
> >>  /*
> >>   * Balloon device works in 4K page units.  So each page is pointed to by
> >> @@ -27,6 +28,7 @@
> >>   */
> >>  #define VIRTIO_BALLOON_PAGES_PER_PAGE (unsigned)(PAGE_SIZE >> VIRTIO_BALLOON_PFN_SHIFT)
> >>  #define VIRTIO_BALLOON_ARRAY_PFNS_MAX 256
> >> +#define VIRTIO_BALLOON_ARRAY_HINTS_MAX	32
> >>  #define VIRTBALLOON_OOM_NOTIFY_PRIORITY 80
> >>  
> >>  #define VIRTIO_BALLOON_FREE_PAGE_ALLOC_FLAG (__GFP_NORETRY | __GFP_NOWARN | \
> >> @@ -46,6 +48,7 @@ enum virtio_balloon_vq {
> >>  	VIRTIO_BALLOON_VQ_DEFLATE,
> >>  	VIRTIO_BALLOON_VQ_STATS,
> >>  	VIRTIO_BALLOON_VQ_FREE_PAGE,
> >> +	VIRTIO_BALLOON_VQ_HINTING,
> >>  	VIRTIO_BALLOON_VQ_MAX
> >>  };
> >>  
> >> @@ -113,6 +116,10 @@ struct virtio_balloon {
> >>  
> >>  	/* To register a shrinker to shrink memory upon memory pressure */
> >>  	struct shrinker shrinker;
> >> +
> >> +	/* Unused page hinting device */
> >> +	struct virtqueue *hinting_vq;
> >> +	struct page_hinting_dev_info ph_dev_info;
> >>  };
> >>  
> >>  static struct virtio_device_id id_table[] = {
> >> @@ -152,6 +159,22 @@ static void tell_host(struct virtio_balloon *vb, struct virtqueue *vq)
> >>  
> >>  }
> >>  
> >> +void virtballoon_page_hinting_react(struct page_hinting_dev_info *ph_dev_info,
> >> +				    unsigned int num_hints)
> >> +{
> >> +	struct virtio_balloon *vb =
> >> +		container_of(ph_dev_info, struct virtio_balloon, ph_dev_info);
> >> +	struct virtqueue *vq = vb->hinting_vq;
> >> +	unsigned int unused;
> >> +
> >> +	/* We should always be able to add these buffers to an empty queue. */
> >
> > can be an out of memory condition, and then ...
> 
> Do we need an error check here?
> 
> For situations where this fails we should disable hinting completely, maybe?

I would just limit this to vq size, then you know it won't fail.

> 
> >
> >> +	virtqueue_add_inbuf(vq, ph_dev_info->sg, num_hints, vb, GFP_KERNEL);
> >> +	virtqueue_kick(vq);
> > ... this will block forever.
> >
> >> +	/* When host has read buffer, this completes via balloon_ack */
> >> +	wait_event(vb->acked, virtqueue_get_buf(vq, &unused));
> > However below I suggest limiting capacity which will solve
> > this problem for you.
> >
> >
> >
> >> +}
> >> +
> >>  static void set_page_pfns(struct virtio_balloon *vb,
> >>  			  __virtio32 pfns[], struct page *page)
> >>  {
> >> @@ -476,6 +499,7 @@ static int init_vqs(struct virtio_balloon *vb)
> >>  	names[VIRTIO_BALLOON_VQ_DEFLATE] = "deflate";
> >>  	names[VIRTIO_BALLOON_VQ_STATS] = NULL;
> >>  	names[VIRTIO_BALLOON_VQ_FREE_PAGE] = NULL;
> >> +	names[VIRTIO_BALLOON_VQ_HINTING] = NULL;
> >>  
> >>  	if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_STATS_VQ)) {
> >>  		names[VIRTIO_BALLOON_VQ_STATS] = "stats";
> >> @@ -487,11 +511,19 @@ static int init_vqs(struct virtio_balloon *vb)
> >>  		callbacks[VIRTIO_BALLOON_VQ_FREE_PAGE] = NULL;
> >>  	}
> >>  
> >> +	if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_HINTING)) {
> >> +		names[VIRTIO_BALLOON_VQ_HINTING] = "hinting_vq";
> >> +		callbacks[VIRTIO_BALLOON_VQ_HINTING] = balloon_ack;
> >> +	}
> >> +
> >>  	err = vb->vdev->config->find_vqs(vb->vdev, VIRTIO_BALLOON_VQ_MAX,
> >>  					 vqs, callbacks, names, NULL, NULL);
> >>  	if (err)
> >>  		return err;
> >>  
> >> +	if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_HINTING))
> >> +		vb->hinting_vq = vqs[VIRTIO_BALLOON_VQ_HINTING];
> >> +
> >>  	vb->inflate_vq = vqs[VIRTIO_BALLOON_VQ_INFLATE];
> >>  	vb->deflate_vq = vqs[VIRTIO_BALLOON_VQ_DEFLATE];
> >>  	if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_STATS_VQ)) {
> >> @@ -924,12 +956,24 @@ static int virtballoon_probe(struct virtio_device *vdev)
> >>  		if (err)
> >>  			goto out_del_balloon_wq;
> >>  	}
> >> +
> >> +	vb->ph_dev_info.react = virtballoon_page_hinting_react;
> >> +	vb->ph_dev_info.capacity = VIRTIO_BALLOON_ARRAY_HINTS_MAX;
> > As explained above I think you should limit this by vq size.
> > Otherwise virtqueue add buf might fail.
> > In fact by struct spec reading you need to limit it
> > anyway otherwise it will fail unconditionally.
> > In practice on most hypervisors it will typically work ...
> >
> >> +	if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_HINTING)) {
> >> +		err = page_hinting_startup(&vb->ph_dev_info);
> >> +		if (err)
> >> +			goto out_unregister_shrinker;
> >> +	}
> >> +
> >>  	virtio_device_ready(vdev);
> >>  
> >>  	if (towards_target(vb))
> >>  		virtballoon_changed(vdev);
> >>  	return 0;
> >>  
> >> +out_unregister_shrinker:
> >> +	if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_DEFLATE_ON_OOM))
> >> +		virtio_balloon_unregister_shrinker(vb);
> >>  out_del_balloon_wq:
> >>  	if (virtio_has_feature(vdev, VIRTIO_BALLOON_F_FREE_PAGE_HINT))
> >>  		destroy_workqueue(vb->balloon_wq);
> >> @@ -958,6 +1002,8 @@ static void virtballoon_remove(struct virtio_device *vdev)
> >>  {
> >>  	struct virtio_balloon *vb = vdev->priv;
> >>  
> >> +	if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_HINTING))
> >> +		page_hinting_shutdown(&vb->ph_dev_info);
> >>  	if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_DEFLATE_ON_OOM))
> >>  		virtio_balloon_unregister_shrinker(vb);
> >>  	spin_lock_irq(&vb->stop_update_lock);
> >> @@ -1027,6 +1073,7 @@ static int virtballoon_validate(struct virtio_device *vdev)
> >>  	VIRTIO_BALLOON_F_DEFLATE_ON_OOM,
> >>  	VIRTIO_BALLOON_F_FREE_PAGE_HINT,
> >>  	VIRTIO_BALLOON_F_PAGE_POISON,
> >> +	VIRTIO_BALLOON_F_HINTING,
> >>  };
> >>  
> >>  static struct virtio_driver virtio_balloon_driver = {
> >> diff --git a/include/uapi/linux/virtio_balloon.h b/include/uapi/linux/virtio_balloon.h
> >> index a1966cd7b677..2b0f62814e22 100644
> >> --- a/include/uapi/linux/virtio_balloon.h
> >> +++ b/include/uapi/linux/virtio_balloon.h
> >> @@ -36,6 +36,7 @@
> >>  #define VIRTIO_BALLOON_F_DEFLATE_ON_OOM	2 /* Deflate balloon on OOM */
> >>  #define VIRTIO_BALLOON_F_FREE_PAGE_HINT	3 /* VQ to report free pages */
> >>  #define VIRTIO_BALLOON_F_PAGE_POISON	4 /* Guest is using page poisoning */
> >> +#define VIRTIO_BALLOON_F_HINTING	5 /* Page hinting virtqueue */
> >>  
> >>  /* Size of a PFN in the balloon interface. */
> >>  #define VIRTIO_BALLOON_PFN_SHIFT 12
> -- 
> Thanks
> Nitesh

Re: [PATCH v2 5/5] virtio-balloon: Add support for providing page hints to host

[Alexander Duyck]

On Thu, 2019-07-25 at 10:44 -0400, Nitesh Narayan Lal wrote:
> On 7/24/19 3:02 PM, Michael S. Tsirkin wrote:
> > On Wed, Jul 24, 2019 at 10:05:14AM -0700, Alexander Duyck wrote:
> > > From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> > > 
> > > Add support for the page hinting feature provided by virtio-balloon.
> > > Hinting differs from the regular balloon functionality in that is is
> > > much less durable than a standard memory balloon. Instead of creating a
> > > list of pages that cannot be accessed the pages are only inaccessible
> > > while they are being indicated to the virtio interface. Once the
> > > interface has acknowledged them they are placed back into their respective
> > > free lists and are once again accessible by the guest system.
> > > 
> > > Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> > Looking at the design, it seems that hinted pages can immediately be
> > reused. I wonder how we can efficiently support this
> > with kvm when poisoning is in effect. Of course we can just
> > ignore the poison. However it seems cleaner to
> > 1. verify page is poisoned with the correct value
> > 2. fill the page with the correct value on fault
> > 
> > Requirement 2 requires some kind of madvise that
> > will save the poison e.g. in the VMA.
> > 
> > Not a blocker for sure ... 
> > 
> > 
> > > ---
> > >  drivers/virtio/Kconfig              |    1 +
> > >  drivers/virtio/virtio_balloon.c     |   47 +++++++++++++++++++++++++++++++++++
> > >  include/uapi/linux/virtio_balloon.h |    1 +
> > >  3 files changed, 49 insertions(+)
> > > 
> > > diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig
> > > index 078615cf2afc..d45556ae1f81 100644
> > > --- a/drivers/virtio/Kconfig
> > > +++ b/drivers/virtio/Kconfig
> > > @@ -58,6 +58,7 @@ config VIRTIO_BALLOON
> > >  	tristate "Virtio balloon driver"
> > >  	depends on VIRTIO
> > >  	select MEMORY_BALLOON
> > > +	select PAGE_HINTING
> > >  	---help---
> > >  	 This driver supports increasing and decreasing the amount
> > >  	 of memory within a KVM guest.
> > > diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
> > > index 226fbb995fb0..dee9f8f3ad09 100644
> > > --- a/drivers/virtio/virtio_balloon.c
> > > +++ b/drivers/virtio/virtio_balloon.c
> > > @@ -19,6 +19,7 @@
> > >  #include <linux/mount.h>
> > >  #include <linux/magic.h>
> > >  #include <linux/pseudo_fs.h>
> > > +#include <linux/page_hinting.h>
> > >  
> > >  /*
> > >   * Balloon device works in 4K page units.  So each page is pointed to by
> > > @@ -27,6 +28,7 @@
> > >   */
> > >  #define VIRTIO_BALLOON_PAGES_PER_PAGE (unsigned)(PAGE_SIZE >> VIRTIO_BALLOON_PFN_SHIFT)
> > >  #define VIRTIO_BALLOON_ARRAY_PFNS_MAX 256
> > > +#define VIRTIO_BALLOON_ARRAY_HINTS_MAX	32
> > >  #define VIRTBALLOON_OOM_NOTIFY_PRIORITY 80
> > >  
> > >  #define VIRTIO_BALLOON_FREE_PAGE_ALLOC_FLAG (__GFP_NORETRY | __GFP_NOWARN | \
> > > @@ -46,6 +48,7 @@ enum virtio_balloon_vq {
> > >  	VIRTIO_BALLOON_VQ_DEFLATE,
> > >  	VIRTIO_BALLOON_VQ_STATS,
> > >  	VIRTIO_BALLOON_VQ_FREE_PAGE,
> > > +	VIRTIO_BALLOON_VQ_HINTING,
> > >  	VIRTIO_BALLOON_VQ_MAX
> > >  };
> > >  
> > > @@ -113,6 +116,10 @@ struct virtio_balloon {
> > >  
> > >  	/* To register a shrinker to shrink memory upon memory pressure */
> > >  	struct shrinker shrinker;
> > > +
> > > +	/* Unused page hinting device */
> > > +	struct virtqueue *hinting_vq;
> > > +	struct page_hinting_dev_info ph_dev_info;
> > >  };
> > >  
> > >  static struct virtio_device_id id_table[] = {
> > > @@ -152,6 +159,22 @@ static void tell_host(struct virtio_balloon *vb, struct virtqueue *vq)
> > >  
> > >  }
> > >  
> > > +void virtballoon_page_hinting_react(struct page_hinting_dev_info *ph_dev_info,
> > > +				    unsigned int num_hints)
> > > +{
> > > +	struct virtio_balloon *vb =
> > > +		container_of(ph_dev_info, struct virtio_balloon, ph_dev_info);
> > > +	struct virtqueue *vq = vb->hinting_vq;
> > > +	unsigned int unused;
> > > +
> > > +	/* We should always be able to add these buffers to an empty queue. */
> > 
> > can be an out of memory condition, and then ...
> 
> Do we need an error check here?
> 
> For situations where this fails we should disable hinting completely, maybe?

No. Instead I will just limit the capacity to no more than the vq size.
Doing that should allow us to avoid the out of memory issue here if I am
understanding things correctly.

I'm assuming the allocation being referred to is alloc_indirect_split(),
if so then it looks like it can fail and then we just fall back to using
the vring.desc directly which will work for my purposes as long as I limit
the capacity of the scatterlist to no more than the size of the vring.

Re: [PATCH v2 QEMU] virtio-balloon: Provide a interface for "bubble hinting"

[Alexander Duyck]

On Thu, 2019-07-25 at 07:57 -0400, Nitesh Narayan Lal wrote:
> On 7/24/19 4:18 PM, Alexander Duyck wrote:
> > On Wed, 2019-07-24 at 15:02 -0400, Michael S. Tsirkin wrote:
> > > On Wed, Jul 24, 2019 at 10:12:10AM -0700, Alexander Duyck wrote:
> > > > From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> > > > 
> > > > Add support for what I am referring to as "bubble hinting". Basically the
> > > > idea is to function very similar to how the balloon works in that we
> > > > basically end up madvising the page as not being used. However we don't
> > > > really need to bother with any deflate type logic since the page will be
> > > > faulted back into the guest when it is read or written to.
> > > > 
> > > > This is meant to be a simplification of the existing balloon interface
> > > > to use for providing hints to what memory needs to be freed. I am assuming
> > > > this is safe to do as the deflate logic does not actually appear to do very
> > > > much other than tracking what subpages have been released and which ones
> > > > haven't.
> > > > 
> > > > Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> > > > ---
> > > >  hw/virtio/virtio-balloon.c                      |   40 +++++++++++++++++++++++
> > > >  include/hw/virtio/virtio-balloon.h              |    2 +
> > > >  include/standard-headers/linux/virtio_balloon.h |    1 +
> > > >  3 files changed, 42 insertions(+), 1 deletion(-)
> > > > 
> > > > diff --git a/hw/virtio/virtio-balloon.c b/hw/virtio/virtio-balloon.c
> > > > index 2112874055fb..70c0004c0f88 100644
> > > > --- a/hw/virtio/virtio-balloon.c
> > > > +++ b/hw/virtio/virtio-balloon.c
> > > > @@ -328,6 +328,39 @@ static void balloon_stats_set_poll_interval(Object *obj, Visitor *v,
> > > >      balloon_stats_change_timer(s, 0);
> > > >  }
> > > >  
> > > > +static void virtio_bubble_handle_output(VirtIODevice *vdev, VirtQueue *vq)
> > > > +{
> > > > +    VirtQueueElement *elem;
> > > > +
> > > > +    while ((elem = virtqueue_pop(vq, sizeof(VirtQueueElement)))) {
> > > > +    	unsigned int i;
> > > > +
> > > > +        for (i = 0; i < elem->in_num; i++) {
> > > > +            void *addr = elem->in_sg[i].iov_base;
> > > > +            size_t size = elem->in_sg[i].iov_len;
> > > > +            ram_addr_t ram_offset;
> > > > +            size_t rb_page_size;
> > > > +            RAMBlock *rb;
> > > > +
> > > > +            if (qemu_balloon_is_inhibited())
> > > > +                continue;
> > > > +
> > > > +            rb = qemu_ram_block_from_host(addr, false, &ram_offset);
> > > > +            rb_page_size = qemu_ram_pagesize(rb);
> > > > +
> > > > +            /* For now we will simply ignore unaligned memory regions */
> > > > +            if ((ram_offset | size) & (rb_page_size - 1))
> > > > +                continue;
> > > > +
> > > > +            ram_block_discard_range(rb, ram_offset, size);
> > > I suspect this needs to do like the migration type of
> > > hinting and get disabled if page poisoning is in effect.
> > > Right?
> > Shouldn't something like that end up getting handled via
> > qemu_balloon_is_inhibited, or did I miss something there? I assumed cases
> > like that would end up setting qemu_balloon_is_inhibited to true, if that
> > isn't the case then I could add some additional conditions. I would do it
> > in about the same spot as the qemu_balloon_is_inhibited check.
> 
> Just wondering if you have tried running these patches in an environment with
> directly assigned devices? Ideally, I would expect qemu_balloon_is_inhibited()
> to take care of it.

Yes, I have run that as a test to actually benchmark the effect of things
without the madvise bits since it essentially disables the hinting in the
hypervisor but not the guest.

Re: [PATCH v2 5/5] virtio-balloon: Add support for providing page hints to host

[Michael S. Tsirkin]

On Thu, Jul 25, 2019 at 07:56:15AM -0700, Alexander Duyck wrote:
> On Thu, 2019-07-25 at 10:44 -0400, Nitesh Narayan Lal wrote:
> > On 7/24/19 3:02 PM, Michael S. Tsirkin wrote:
> > > On Wed, Jul 24, 2019 at 10:05:14AM -0700, Alexander Duyck wrote:
> > > > From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> > > > 
> > > > Add support for the page hinting feature provided by virtio-balloon.
> > > > Hinting differs from the regular balloon functionality in that is is
> > > > much less durable than a standard memory balloon. Instead of creating a
> > > > list of pages that cannot be accessed the pages are only inaccessible
> > > > while they are being indicated to the virtio interface. Once the
> > > > interface has acknowledged them they are placed back into their respective
> > > > free lists and are once again accessible by the guest system.
> > > > 
> > > > Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> > > Looking at the design, it seems that hinted pages can immediately be
> > > reused. I wonder how we can efficiently support this
> > > with kvm when poisoning is in effect. Of course we can just
> > > ignore the poison. However it seems cleaner to
> > > 1. verify page is poisoned with the correct value
> > > 2. fill the page with the correct value on fault
> > > 
> > > Requirement 2 requires some kind of madvise that
> > > will save the poison e.g. in the VMA.
> > > 
> > > Not a blocker for sure ... 
> > > 
> > > 
> > > > ---
> > > >  drivers/virtio/Kconfig              |    1 +
> > > >  drivers/virtio/virtio_balloon.c     |   47 +++++++++++++++++++++++++++++++++++
> > > >  include/uapi/linux/virtio_balloon.h |    1 +
> > > >  3 files changed, 49 insertions(+)
> > > > 
> > > > diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig
> > > > index 078615cf2afc..d45556ae1f81 100644
> > > > --- a/drivers/virtio/Kconfig
> > > > +++ b/drivers/virtio/Kconfig
> > > > @@ -58,6 +58,7 @@ config VIRTIO_BALLOON
> > > >  	tristate "Virtio balloon driver"
> > > >  	depends on VIRTIO
> > > >  	select MEMORY_BALLOON
> > > > +	select PAGE_HINTING
> > > >  	---help---
> > > >  	 This driver supports increasing and decreasing the amount
> > > >  	 of memory within a KVM guest.
> > > > diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
> > > > index 226fbb995fb0..dee9f8f3ad09 100644
> > > > --- a/drivers/virtio/virtio_balloon.c
> > > > +++ b/drivers/virtio/virtio_balloon.c
> > > > @@ -19,6 +19,7 @@
> > > >  #include <linux/mount.h>
> > > >  #include <linux/magic.h>
> > > >  #include <linux/pseudo_fs.h>
> > > > +#include <linux/page_hinting.h>
> > > >  
> > > >  /*
> > > >   * Balloon device works in 4K page units.  So each page is pointed to by
> > > > @@ -27,6 +28,7 @@
> > > >   */
> > > >  #define VIRTIO_BALLOON_PAGES_PER_PAGE (unsigned)(PAGE_SIZE >> VIRTIO_BALLOON_PFN_SHIFT)
> > > >  #define VIRTIO_BALLOON_ARRAY_PFNS_MAX 256
> > > > +#define VIRTIO_BALLOON_ARRAY_HINTS_MAX	32
> > > >  #define VIRTBALLOON_OOM_NOTIFY_PRIORITY 80
> > > >  
> > > >  #define VIRTIO_BALLOON_FREE_PAGE_ALLOC_FLAG (__GFP_NORETRY | __GFP_NOWARN | \
> > > > @@ -46,6 +48,7 @@ enum virtio_balloon_vq {
> > > >  	VIRTIO_BALLOON_VQ_DEFLATE,
> > > >  	VIRTIO_BALLOON_VQ_STATS,
> > > >  	VIRTIO_BALLOON_VQ_FREE_PAGE,
> > > > +	VIRTIO_BALLOON_VQ_HINTING,
> > > >  	VIRTIO_BALLOON_VQ_MAX
> > > >  };
> > > >  
> > > > @@ -113,6 +116,10 @@ struct virtio_balloon {
> > > >  
> > > >  	/* To register a shrinker to shrink memory upon memory pressure */
> > > >  	struct shrinker shrinker;
> > > > +
> > > > +	/* Unused page hinting device */
> > > > +	struct virtqueue *hinting_vq;
> > > > +	struct page_hinting_dev_info ph_dev_info;
> > > >  };
> > > >  
> > > >  static struct virtio_device_id id_table[] = {
> > > > @@ -152,6 +159,22 @@ static void tell_host(struct virtio_balloon *vb, struct virtqueue *vq)
> > > >  
> > > >  }
> > > >  
> > > > +void virtballoon_page_hinting_react(struct page_hinting_dev_info *ph_dev_info,
> > > > +				    unsigned int num_hints)
> > > > +{
> > > > +	struct virtio_balloon *vb =
> > > > +		container_of(ph_dev_info, struct virtio_balloon, ph_dev_info);
> > > > +	struct virtqueue *vq = vb->hinting_vq;
> > > > +	unsigned int unused;
> > > > +
> > > > +	/* We should always be able to add these buffers to an empty queue. */
> > > 
> > > can be an out of memory condition, and then ...
> > 
> > Do we need an error check here?
> > 
> > For situations where this fails we should disable hinting completely, maybe?
> 
> No. Instead I will just limit the capacity to no more than the vq size.
> Doing that should allow us to avoid the out of memory issue here if I am
> understanding things correctly.
> 
> I'm assuming the allocation being referred to is alloc_indirect_split(),
> if so then it looks like it can fail and then we just fall back to using
> the vring.desc directly which will work for my purposes as long as I limit
> the capacity of the scatterlist to no more than the size of the vring.
> 


Right. And maybe tweak the GFP mask - no reason to try to
allocate memory aggressively with just 1 element in flight.

> 

Re: [PATCH v2 QEMU] virtio-balloon: Provide a interface for "bubble hinting"

[Alexander Duyck]

On Thu, 2019-07-25 at 07:35 -0400, Nitesh Narayan Lal wrote:
> On 7/24/19 6:03 PM, Alexander Duyck wrote:
> > On Wed, 2019-07-24 at 17:38 -0400, Michael S. Tsirkin wrote:
> > > On Wed, Jul 24, 2019 at 10:12:10AM -0700, Alexander Duyck wrote:
> > > > From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> > > > 
> > > > Add support for what I am referring to as "bubble hinting". Basically the
> > > > idea is to function very similar to how the balloon works in that we
> > > > basically end up madvising the page as not being used. However we don't
> > > > really need to bother with any deflate type logic since the page will be
> > > > faulted back into the guest when it is read or written to.
> > > > 
> > > > This is meant to be a simplification of the existing balloon interface
> > > > to use for providing hints to what memory needs to be freed. I am assuming
> > > > this is safe to do as the deflate logic does not actually appear to do very
> > > > much other than tracking what subpages have been released and which ones
> > > > haven't.
> > > > 
> > > > Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> > > BTW I wonder about migration here.  When we migrate we lose all hints
> > > right?  Well destination could be smarter, detect that page is full of
> > > 0s and just map a zero page. Then we don't need a hint as such - but I
> > > don't think it's done like that ATM.
> > I was wondering about that a bit myself. If you migrate with a balloon
> > active what currently happens with the pages in the balloon? Do you
> > actually migrate them, or do you ignore them and just assume a zero page?
> > I'm just reusing the ram_block_discard_range logic that was being used for
> > the balloon inflation so I would assume the behavior would be the same.
> I agree, however, I think it is worth investigating to see if enabling hinting
> adds some sort of overhead specifically in this kind of scenarios. What do you
> think?

I suspect that the hinting/reporting would probably improve migration
times based on the fact that from the sound of things it would just be
migrated as a zero page.

I don't have a good setup for testing migration though and I am not that
familiar with trying to do a live migration. That is one of the reasons
why I didn't want to stray too far from the existing balloon code as that
has already been tested with migration so I would assume as long as I am
doing almost the exact same thing to hint the pages away it should behave
exactly the same.

> > > I also wonder about interaction with deflate.  ATM deflate will add
> > > pages to the free list, then balloon will come right back and report
> > > them as free.
> > I don't know how likely it is that somebody who is getting the free page
> > reporting is likely to want to also use the balloon to take up memory.
> I think it is possible. There are two possibilities:
> 1. User has a workload running, which is allocating and freeing the pages and at
> the same time, user deflates.
> If these new pages get used by this workload, we don't have to worry as you are
> already handling that by not hinting the free pages immediately.
> 2. Guest is idle and the user adds up some memory, for this situation what you
> have explained below does seems reasonable.

Us hinting on pages that are freed up via deflate wouldn't be too big of a
deal. I would think that is something we could look at addressing as more
of a follow-on if we ever needed to since it would just add more
complexity.

Really what I would like to see is the balloon itself get updated first to
perhaps work with variable sized pages first so that we could then have
pages come directly out of the balloon and go back into the freelist as
hinted, or visa-versa where hinted pages could be pulled directly into the
balloon without needing to notify the host.

Re: [PATCH v2 QEMU] virtio-balloon: Provide a interface for "bubble hinting"

[Michael S. Tsirkin]

On Thu, Jul 25, 2019 at 08:05:30AM -0700, Alexander Duyck wrote:
> On Thu, 2019-07-25 at 07:35 -0400, Nitesh Narayan Lal wrote:
> > On 7/24/19 6:03 PM, Alexander Duyck wrote:
> > > On Wed, 2019-07-24 at 17:38 -0400, Michael S. Tsirkin wrote:
> > > > On Wed, Jul 24, 2019 at 10:12:10AM -0700, Alexander Duyck wrote:
> > > > > From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> > > > > 
> > > > > Add support for what I am referring to as "bubble hinting". Basically the
> > > > > idea is to function very similar to how the balloon works in that we
> > > > > basically end up madvising the page as not being used. However we don't
> > > > > really need to bother with any deflate type logic since the page will be
> > > > > faulted back into the guest when it is read or written to.
> > > > > 
> > > > > This is meant to be a simplification of the existing balloon interface
> > > > > to use for providing hints to what memory needs to be freed. I am assuming
> > > > > this is safe to do as the deflate logic does not actually appear to do very
> > > > > much other than tracking what subpages have been released and which ones
> > > > > haven't.
> > > > > 
> > > > > Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> > > > BTW I wonder about migration here.  When we migrate we lose all hints
> > > > right?  Well destination could be smarter, detect that page is full of
> > > > 0s and just map a zero page. Then we don't need a hint as such - but I
> > > > don't think it's done like that ATM.
> > > I was wondering about that a bit myself. If you migrate with a balloon
> > > active what currently happens with the pages in the balloon? Do you
> > > actually migrate them, or do you ignore them and just assume a zero page?
> > > I'm just reusing the ram_block_discard_range logic that was being used for
> > > the balloon inflation so I would assume the behavior would be the same.
> > I agree, however, I think it is worth investigating to see if enabling hinting
> > adds some sort of overhead specifically in this kind of scenarios. What do you
> > think?
> 
> I suspect that the hinting/reporting would probably improve migration
> times based on the fact that from the sound of things it would just be
> migrated as a zero page.
> 
> I don't have a good setup for testing migration though and I am not that
> familiar with trying to do a live migration. That is one of the reasons
> why I didn't want to stray too far from the existing balloon code as that
> has already been tested with migration so I would assume as long as I am
> doing almost the exact same thing to hint the pages away it should behave
> exactly the same.
> 
> > > > I also wonder about interaction with deflate.  ATM deflate will add
> > > > pages to the free list, then balloon will come right back and report
> > > > them as free.
> > > I don't know how likely it is that somebody who is getting the free page
> > > reporting is likely to want to also use the balloon to take up memory.
> > I think it is possible. There are two possibilities:
> > 1. User has a workload running, which is allocating and freeing the pages and at
> > the same time, user deflates.
> > If these new pages get used by this workload, we don't have to worry as you are
> > already handling that by not hinting the free pages immediately.
> > 2. Guest is idle and the user adds up some memory, for this situation what you
> > have explained below does seems reasonable.
> 
> Us hinting on pages that are freed up via deflate wouldn't be too big of a
> deal. I would think that is something we could look at addressing as more
> of a follow-on if we ever needed to since it would just add more
> complexity.
> 
> Really what I would like to see is the balloon itself get updated first to
> perhaps work with variable sized pages first so that we could then have
> pages come directly out of the balloon and go back into the freelist as
> hinted, or visa-versa where hinted pages could be pulled directly into the
> balloon without needing to notify the host.

Right, I agree. At this point the main thing I worry about is that
the interfaces only support one reporter, since a page flag is used.
So if we ever rewrite existing hinting to use the new mm
infrastructure then we can't e.g. enable both types of hinting.

FWIW Nitesh's RFC does not have this limitation.

I intend to think about this over the weekend.

-- 
MST

Re: [PATCH v2 4/5] mm: Introduce Hinted pages

[Alexander Duyck]

On Thu, Jul 25, 2019 at 1:53 AM David Hildenbrand <david@redhat.com> wrote:
>
> On 24.07.19 19:03, Alexander Duyck wrote:
> > From: Alexander Duyck <alexander.h.duyck@linux.intel.com>

<snip>

> >  /*
> > + * PageHinted() is an alias for Offline, however it is not meant to be an
> > + * exclusive value. It should be combined with PageBuddy() when seen as it
> > + * is meant to indicate that the page has been scrubbed while waiting in
> > + * the buddy system.
> > + */
> > +PAGE_TYPE_OPS(Hinted, offline)
>
>
> CCing Matthew
>
> I am still not sure if I like the idea of having two page types at a time.
>
> 1. Once we run out of page type bits (which can happen easily looking at
> it getting more and more user - e.g., maybe for vmmap pages soon), we
> might want to convert again back to a value-based, not bit-based type
> detection. This will certainly make this switch harder.

Shouldn't we wait to cross that bridge until we get there? It wouldn't
take much to look at either defining the buddy as 2 types for such a
case, or if needed we could then look at the option of moving over to
another bit.

> 2. It will complicate the kexec/kdump handling. I assume it can be fixed
> some way - e.g., making the elf interface aware of the exact notion of
> page type bits compared to mapcount values we have right now (e.g.,
> PAGE_BUDDY_MAPCOUNT_VALUE). Not addressed in this series yet.

It does, but not by much. We were already exposing both the buddy and
offline values. The cahnge could probably be in the executable that
are accessing the interface to allow the combination of buddy and
offline. That is one of the advantages of using the "offline" value to
also mean hinted since then "hinted" is just a combination of the two
known values.

> Can't we reuse one of the traditional page flags for that, not used
> along with buddy pages? E.g., PG_dirty: Pages that were not hinted yet
> are dirty.

Reusing something like the dirty bit would just be confusing in my
opinion. In addition it looks like Xen has also re-purposed PG_dirty
already for another purpose.

If anything I could probably look at seeing if the PG_private flags
are available when a page is in the buddy allocator which I suspect
they probably are since the only users I currently see appear to be
SLOB and compound pages. Either that or maybe something like PG_head
might make sense since once we start allocating them we are popping
the head off of the boundary list.

Re: [PATCH v2 QEMU] virtio-balloon: Provide a interface for "bubble hinting"

[Alexander Duyck]

On Thu, 2019-07-25 at 11:16 -0400, Michael S. Tsirkin wrote:
> On Thu, Jul 25, 2019 at 08:05:30AM -0700, Alexander Duyck wrote:
> > On Thu, 2019-07-25 at 07:35 -0400, Nitesh Narayan Lal wrote:
> > > On 7/24/19 6:03 PM, Alexander Duyck wrote:
> > > > On Wed, 2019-07-24 at 17:38 -0400, Michael S. Tsirkin wrote:
> > > > > On Wed, Jul 24, 2019 at 10:12:10AM -0700, Alexander Duyck wrote:
> > > > > > From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> > > > > > 
> > > > > > Add support for what I am referring to as "bubble hinting". Basically the
> > > > > > idea is to function very similar to how the balloon works in that we
> > > > > > basically end up madvising the page as not being used. However we don't
> > > > > > really need to bother with any deflate type logic since the page will be
> > > > > > faulted back into the guest when it is read or written to.
> > > > > > 
> > > > > > This is meant to be a simplification of the existing balloon interface
> > > > > > to use for providing hints to what memory needs to be freed. I am assuming
> > > > > > this is safe to do as the deflate logic does not actually appear to do very
> > > > > > much other than tracking what subpages have been released and which ones
> > > > > > haven't.
> > > > > > 
> > > > > > Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> > > > > BTW I wonder about migration here.  When we migrate we lose all hints
> > > > > right?  Well destination could be smarter, detect that page is full of
> > > > > 0s and just map a zero page. Then we don't need a hint as such - but I
> > > > > don't think it's done like that ATM.
> > > > I was wondering about that a bit myself. If you migrate with a balloon
> > > > active what currently happens with the pages in the balloon? Do you
> > > > actually migrate them, or do you ignore them and just assume a zero page?
> > > > I'm just reusing the ram_block_discard_range logic that was being used for
> > > > the balloon inflation so I would assume the behavior would be the same.
> > > I agree, however, I think it is worth investigating to see if enabling hinting
> > > adds some sort of overhead specifically in this kind of scenarios. What do you
> > > think?
> > 
> > I suspect that the hinting/reporting would probably improve migration
> > times based on the fact that from the sound of things it would just be
> > migrated as a zero page.
> > 
> > I don't have a good setup for testing migration though and I am not that
> > familiar with trying to do a live migration. That is one of the reasons
> > why I didn't want to stray too far from the existing balloon code as that
> > has already been tested with migration so I would assume as long as I am
> > doing almost the exact same thing to hint the pages away it should behave
> > exactly the same.
> > 
> > > > > I also wonder about interaction with deflate.  ATM deflate will add
> > > > > pages to the free list, then balloon will come right back and report
> > > > > them as free.
> > > > I don't know how likely it is that somebody who is getting the free page
> > > > reporting is likely to want to also use the balloon to take up memory.
> > > I think it is possible. There are two possibilities:
> > > 1. User has a workload running, which is allocating and freeing the pages and at
> > > the same time, user deflates.
> > > If these new pages get used by this workload, we don't have to worry as you are
> > > already handling that by not hinting the free pages immediately.
> > > 2. Guest is idle and the user adds up some memory, for this situation what you
> > > have explained below does seems reasonable.
> > 
> > Us hinting on pages that are freed up via deflate wouldn't be too big of a
> > deal. I would think that is something we could look at addressing as more
> > of a follow-on if we ever needed to since it would just add more
> > complexity.
> > 
> > Really what I would like to see is the balloon itself get updated first to
> > perhaps work with variable sized pages first so that we could then have
> > pages come directly out of the balloon and go back into the freelist as
> > hinted, or visa-versa where hinted pages could be pulled directly into the
> > balloon without needing to notify the host.
> 
> Right, I agree. At this point the main thing I worry about is that
> the interfaces only support one reporter, since a page flag is used.
> So if we ever rewrite existing hinting to use the new mm
> infrastructure then we can't e.g. enable both types of hinting.

Does it make sense to have multiple types of hinting active at the same
time though? That kind of seems wasteful to me. Ideally we should be able
to provide the hints and have them feed whatever is supposed to be using
them. So for example I could probably look at also clearing the bitmaps
when migration is in process.

Also, I am wonder if the free page hints would be redundant with the form
of page hinting/reporting that I have since we should be migrating a much
smaller footprint anyway if the pages have been madvised away before we
even start the migration.

> FWIW Nitesh's RFC does not have this limitation.

Yes, but there are also limitations to his approach. For example the fact
that the bitmap it maintains is back to being a hint rather then being
very exact. As a result you could end up walking the bitmap for a while
clearing bits without ever finding a free page.

> I intend to think about this over the weekend.

Sounds good. I'll try to get the stuff you have pointed out so far
addressed and hopefully have v3 ready to go next week.

Thanks.

- Alex

Re: [PATCH v2 4/5] mm: Introduce Hinted pages

[David Hildenbrand]

On 25.07.19 17:59, Alexander Duyck wrote:
> On Thu, Jul 25, 2019 at 1:53 AM David Hildenbrand <david@redhat.com> wrote:
>>
>> On 24.07.19 19:03, Alexander Duyck wrote:
>>> From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> 
> <snip>
> 
>>>  /*
>>> + * PageHinted() is an alias for Offline, however it is not meant to be an
>>> + * exclusive value. It should be combined with PageBuddy() when seen as it
>>> + * is meant to indicate that the page has been scrubbed while waiting in
>>> + * the buddy system.
>>> + */
>>> +PAGE_TYPE_OPS(Hinted, offline)
>>
>>
>> CCing Matthew
>>
>> I am still not sure if I like the idea of having two page types at a time.
>>
>> 1. Once we run out of page type bits (which can happen easily looking at
>> it getting more and more user - e.g., maybe for vmmap pages soon), we
>> might want to convert again back to a value-based, not bit-based type
>> detection. This will certainly make this switch harder.
> 
> Shouldn't we wait to cross that bridge until we get there? It wouldn't
> take much to look at either defining the buddy as 2 types for such a
> case, or if needed we could then look at the option of moving over to
> another bit.

I'd rather clarify this now. I am not yet convinced that having multiple
page types at a is a good idea.

> 
>> 2. It will complicate the kexec/kdump handling. I assume it can be fixed
>> some way - e.g., making the elf interface aware of the exact notion of
>> page type bits compared to mapcount values we have right now (e.g.,
>> PAGE_BUDDY_MAPCOUNT_VALUE). Not addressed in this series yet.
> 
> It does, but not by much. We were already exposing both the buddy and
> offline values. The cahnge could probably be in the executable that
> are accessing the interface to allow the combination of buddy and
> offline.

We are exposing mapcount values, not bit values. So you would

> That is one of the advantages of using the "offline" value to
> also mean hinted since then "hinted" is just a combination of the two
> known values.

We are exposing mapcount values right now, not individual bits. Either
expose the bits manually (and thereby the whole page type scheme) or a
new mapcount value PAGE_BUDDY_OFFLINE_MAPCOUNT_VALUE.

> 
>> Can't we reuse one of the traditional page flags for that, not used
>> along with buddy pages? E.g., PG_dirty: Pages that were not hinted yet
>> are dirty.
> 
> Reusing something like the dirty bit would just be confusing in my
> opinion. In addition it looks like Xen has also re-purposed PG_dirty
> already for another purpose.

You brought up waste page management. A dirty bit for unprocessed pages
fits perfectly in this context. Regarding XEN, as long as it's not used
along with buddy pages, no issue.

FWIW, I don't even thing PG_offline matches to what you are using it
here for. The pages are not logically offline. They were simply buddy
pages that were hinted. (I'd even prefer a separate page type for that
instead - if we cannot simply reuse one of the other flags)

"Offline pages" that are not actually offline in the context of the
buddy is way more confusing.

> 
> If anything I could probably look at seeing if the PG_private flags
> are available when a page is in the buddy allocator which I suspect
> they probably are since the only users I currently see appear to be
> SLOB and compound pages. Either that or maybe something like PG_head
> might make sense since once we start allocating them we are popping
> the head off of the boundary list.

Would also be fine with me.

-- 

Thanks,

David / dhildenb

Re: [PATCH v2 QEMU] virtio-balloon: Provide a interface for "bubble hinting"

[Michael S. Tsirkin]

On Thu, Jul 25, 2019 at 09:16:21AM -0700, Alexander Duyck wrote:
> On Thu, 2019-07-25 at 11:16 -0400, Michael S. Tsirkin wrote:
> > On Thu, Jul 25, 2019 at 08:05:30AM -0700, Alexander Duyck wrote:
> > > On Thu, 2019-07-25 at 07:35 -0400, Nitesh Narayan Lal wrote:
> > > > On 7/24/19 6:03 PM, Alexander Duyck wrote:
> > > > > On Wed, 2019-07-24 at 17:38 -0400, Michael S. Tsirkin wrote:
> > > > > > On Wed, Jul 24, 2019 at 10:12:10AM -0700, Alexander Duyck wrote:
> > > > > > > From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> > > > > > > 
> > > > > > > Add support for what I am referring to as "bubble hinting". Basically the
> > > > > > > idea is to function very similar to how the balloon works in that we
> > > > > > > basically end up madvising the page as not being used. However we don't
> > > > > > > really need to bother with any deflate type logic since the page will be
> > > > > > > faulted back into the guest when it is read or written to.
> > > > > > > 
> > > > > > > This is meant to be a simplification of the existing balloon interface
> > > > > > > to use for providing hints to what memory needs to be freed. I am assuming
> > > > > > > this is safe to do as the deflate logic does not actually appear to do very
> > > > > > > much other than tracking what subpages have been released and which ones
> > > > > > > haven't.
> > > > > > > 
> > > > > > > Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> > > > > > BTW I wonder about migration here.  When we migrate we lose all hints
> > > > > > right?  Well destination could be smarter, detect that page is full of
> > > > > > 0s and just map a zero page. Then we don't need a hint as such - but I
> > > > > > don't think it's done like that ATM.
> > > > > I was wondering about that a bit myself. If you migrate with a balloon
> > > > > active what currently happens with the pages in the balloon? Do you
> > > > > actually migrate them, or do you ignore them and just assume a zero page?
> > > > > I'm just reusing the ram_block_discard_range logic that was being used for
> > > > > the balloon inflation so I would assume the behavior would be the same.
> > > > I agree, however, I think it is worth investigating to see if enabling hinting
> > > > adds some sort of overhead specifically in this kind of scenarios. What do you
> > > > think?
> > > 
> > > I suspect that the hinting/reporting would probably improve migration
> > > times based on the fact that from the sound of things it would just be
> > > migrated as a zero page.
> > > 
> > > I don't have a good setup for testing migration though and I am not that
> > > familiar with trying to do a live migration. That is one of the reasons
> > > why I didn't want to stray too far from the existing balloon code as that
> > > has already been tested with migration so I would assume as long as I am
> > > doing almost the exact same thing to hint the pages away it should behave
> > > exactly the same.
> > > 
> > > > > > I also wonder about interaction with deflate.  ATM deflate will add
> > > > > > pages to the free list, then balloon will come right back and report
> > > > > > them as free.
> > > > > I don't know how likely it is that somebody who is getting the free page
> > > > > reporting is likely to want to also use the balloon to take up memory.
> > > > I think it is possible. There are two possibilities:
> > > > 1. User has a workload running, which is allocating and freeing the pages and at
> > > > the same time, user deflates.
> > > > If these new pages get used by this workload, we don't have to worry as you are
> > > > already handling that by not hinting the free pages immediately.
> > > > 2. Guest is idle and the user adds up some memory, for this situation what you
> > > > have explained below does seems reasonable.
> > > 
> > > Us hinting on pages that are freed up via deflate wouldn't be too big of a
> > > deal. I would think that is something we could look at addressing as more
> > > of a follow-on if we ever needed to since it would just add more
> > > complexity.
> > > 
> > > Really what I would like to see is the balloon itself get updated first to
> > > perhaps work with variable sized pages first so that we could then have
> > > pages come directly out of the balloon and go back into the freelist as
> > > hinted, or visa-versa where hinted pages could be pulled directly into the
> > > balloon without needing to notify the host.
> > 
> > Right, I agree. At this point the main thing I worry about is that
> > the interfaces only support one reporter, since a page flag is used.
> > So if we ever rewrite existing hinting to use the new mm
> > infrastructure then we can't e.g. enable both types of hinting.
> 
> Does it make sense to have multiple types of hinting active at the same
> time though? That kind of seems wasteful to me. Ideally we should be able
> to provide the hints and have them feed whatever is supposed to be using
> them. So for example I could probably look at also clearing the bitmaps
> when migration is in process.
> 
> Also, I am wonder if the free page hints would be redundant with the form
> of page hinting/reporting that I have since we should be migrating a much
> smaller footprint anyway if the pages have been madvised away before we
> even start the migration.

Good points.

> > FWIW Nitesh's RFC does not have this limitation.
> 
> Yes, but there are also limitations to his approach. For example the fact
> that the bitmap it maintains is back to being a hint rather then being
> very exact. As a result you could end up walking the bitmap for a while
> clearing bits without ever finding a free page.

For sure.

> > I intend to think about this over the weekend.
> 
> Sounds good. I'll try to get the stuff you have pointed out so far
> addressed and hopefully have v3 ready to go next week.
> 
> Thanks.
> 
> - Alex

Re: [PATCH v2 4/5] mm: Introduce Hinted pages

[Alexander Duyck]

On Thu, 2019-07-25 at 18:48 +0200, David Hildenbrand wrote:
> On 25.07.19 17:59, Alexander Duyck wrote:
> > On Thu, Jul 25, 2019 at 1:53 AM David Hildenbrand <david@redhat.com> wrote:
> > > On 24.07.19 19:03, Alexander Duyck wrote:
> > > > From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> > 

<snip>

> > > Can't we reuse one of the traditional page flags for that, not used
> > > along with buddy pages? E.g., PG_dirty: Pages that were not hinted yet
> > > are dirty.
> > 
> > Reusing something like the dirty bit would just be confusing in my
> > opinion. In addition it looks like Xen has also re-purposed PG_dirty
> > already for another purpose.
> 
> You brought up waste page management. A dirty bit for unprocessed pages
> fits perfectly in this context. Regarding XEN, as long as it's not used
> along with buddy pages, no issue.

I would rather not have to dirty all pages that aren't hinted. That starts
to get too invasive. Ideally we only modify pages if we are hinting on
them. That is why I said I didn't like the use of a dirty bit. What we
want is more of a "guaranteed clean" bit.

> FWIW, I don't even thing PG_offline matches to what you are using it
> here for. The pages are not logically offline. They were simply buddy
> pages that were hinted. (I'd even prefer a separate page type for that
> instead - if we cannot simply reuse one of the other flags)
> 
> "Offline pages" that are not actually offline in the context of the
> buddy is way more confusing.

Right now offline and hinted are essentially the same thing since the
effect is identical.

There may be cases in the future where that is not the case, but with the
current patch set they both result in the pages being evicted from the
guest.

> > If anything I could probably look at seeing if the PG_private flags
> > are available when a page is in the buddy allocator which I suspect
> > they probably are since the only users I currently see appear to be
> > SLOB and compound pages. Either that or maybe something like PG_head
> > might make sense since once we start allocating them we are popping
> > the head off of the boundary list.
> 
> Would also be fine with me.

Actually I may have found an even better bit if we are going with the
"reporting" name. I could probably use "PG_uptodate" since it looks like
most of its uses are related to filesystems. I will wait till I hear from
Matthew on what bits would be available for use before I update things.

Re: [PATCH v2 5/5] virtio-balloon: Add support for providing page hints to host

[Nitesh Narayan Lal]

On 7/24/19 1:05 PM, Alexander Duyck wrote:
> From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
>
> Add support for the page hinting feature provided by virtio-balloon.
> Hinting differs from the regular balloon functionality in that is is
> much less durable than a standard memory balloon. Instead of creating a
> list of pages that cannot be accessed the pages are only inaccessible
> while they are being indicated to the virtio interface. Once the
> interface has acknowledged them they are placed back into their respective
> free lists and are once again accessible by the guest system.
>
> Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> ---
>  drivers/virtio/Kconfig              |    1 +
>  drivers/virtio/virtio_balloon.c     |   47 +++++++++++++++++++++++++++++++++++
>  include/uapi/linux/virtio_balloon.h |    1 +
>  3 files changed, 49 insertions(+)
>
> diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig
> index 078615cf2afc..d45556ae1f81 100644
> --- a/drivers/virtio/Kconfig
> +++ b/drivers/virtio/Kconfig
> @@ -58,6 +58,7 @@ config VIRTIO_BALLOON
>  	tristate "Virtio balloon driver"
>  	depends on VIRTIO
>  	select MEMORY_BALLOON
> +	select PAGE_HINTING
>  	---help---
>  	 This driver supports increasing and decreasing the amount
>  	 of memory within a KVM guest.
> diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
> index 226fbb995fb0..dee9f8f3ad09 100644
> --- a/drivers/virtio/virtio_balloon.c
> +++ b/drivers/virtio/virtio_balloon.c
> @@ -19,6 +19,7 @@
>  #include <linux/mount.h>
>  #include <linux/magic.h>
>  #include <linux/pseudo_fs.h>
> +#include <linux/page_hinting.h>
>  
>  /*
>   * Balloon device works in 4K page units.  So each page is pointed to by
> @@ -27,6 +28,7 @@
>   */
>  #define VIRTIO_BALLOON_PAGES_PER_PAGE (unsigned)(PAGE_SIZE >> VIRTIO_BALLOON_PFN_SHIFT)
>  #define VIRTIO_BALLOON_ARRAY_PFNS_MAX 256
> +#define VIRTIO_BALLOON_ARRAY_HINTS_MAX	32
>  #define VIRTBALLOON_OOM_NOTIFY_PRIORITY 80
>  
>  #define VIRTIO_BALLOON_FREE_PAGE_ALLOC_FLAG (__GFP_NORETRY | __GFP_NOWARN | \
> @@ -46,6 +48,7 @@ enum virtio_balloon_vq {
>  	VIRTIO_BALLOON_VQ_DEFLATE,
>  	VIRTIO_BALLOON_VQ_STATS,
>  	VIRTIO_BALLOON_VQ_FREE_PAGE,
> +	VIRTIO_BALLOON_VQ_HINTING,
>  	VIRTIO_BALLOON_VQ_MAX
>  };
>  
> @@ -113,6 +116,10 @@ struct virtio_balloon {
>  
>  	/* To register a shrinker to shrink memory upon memory pressure */
>  	struct shrinker shrinker;
> +
> +	/* Unused page hinting device */
> +	struct virtqueue *hinting_vq;
> +	struct page_hinting_dev_info ph_dev_info;
>  };
>  
>  static struct virtio_device_id id_table[] = {
> @@ -152,6 +159,22 @@ static void tell_host(struct virtio_balloon *vb, struct virtqueue *vq)
>  
>  }
>  
> +void virtballoon_page_hinting_react(struct page_hinting_dev_info *ph_dev_info,
> +				    unsigned int num_hints)
> +{
> +	struct virtio_balloon *vb =
> +		container_of(ph_dev_info, struct virtio_balloon, ph_dev_info);
> +	struct virtqueue *vq = vb->hinting_vq;
> +	unsigned int unused;
> +
> +	/* We should always be able to add these buffers to an empty queue. */
> +	virtqueue_add_inbuf(vq, ph_dev_info->sg, num_hints, vb, GFP_KERNEL);
> +	virtqueue_kick(vq);
> +
> +	/* When host has read buffer, this completes via balloon_ack */
> +	wait_event(vb->acked, virtqueue_get_buf(vq, &unused));
> +}
> +
>  static void set_page_pfns(struct virtio_balloon *vb,
>  			  __virtio32 pfns[], struct page *page)
>  {
> @@ -476,6 +499,7 @@ static int init_vqs(struct virtio_balloon *vb)
>  	names[VIRTIO_BALLOON_VQ_DEFLATE] = "deflate";
>  	names[VIRTIO_BALLOON_VQ_STATS] = NULL;
>  	names[VIRTIO_BALLOON_VQ_FREE_PAGE] = NULL;
> +	names[VIRTIO_BALLOON_VQ_HINTING] = NULL;
>  
>  	if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_STATS_VQ)) {
>  		names[VIRTIO_BALLOON_VQ_STATS] = "stats";
> @@ -487,11 +511,19 @@ static int init_vqs(struct virtio_balloon *vb)
>  		callbacks[VIRTIO_BALLOON_VQ_FREE_PAGE] = NULL;
>  	}
>  
> +	if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_HINTING)) {
> +		names[VIRTIO_BALLOON_VQ_HINTING] = "hinting_vq";
> +		callbacks[VIRTIO_BALLOON_VQ_HINTING] = balloon_ack;
> +	}
> +
>  	err = vb->vdev->config->find_vqs(vb->vdev, VIRTIO_BALLOON_VQ_MAX,
>  					 vqs, callbacks, names, NULL, NULL);
>  	if (err)
>  		return err;
>  
> +	if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_HINTING))
> +		vb->hinting_vq = vqs[VIRTIO_BALLOON_VQ_HINTING];
> +
>  	vb->inflate_vq = vqs[VIRTIO_BALLOON_VQ_INFLATE];
>  	vb->deflate_vq = vqs[VIRTIO_BALLOON_VQ_DEFLATE];
>  	if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_STATS_VQ)) {
> @@ -924,12 +956,24 @@ static int virtballoon_probe(struct virtio_device *vdev)
>  		if (err)
>  			goto out_del_balloon_wq;
>  	}
> +
> +	vb->ph_dev_info.react = virtballoon_page_hinting_react;
> +	vb->ph_dev_info.capacity = VIRTIO_BALLOON_ARRAY_HINTS_MAX;
> +	if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_HINTING)) {
> +		err = page_hinting_startup(&vb->ph_dev_info);
> +		if (err)
> +			goto out_unregister_shrinker;
> +	}
Any reason why you have kept vb->ph_dev_info.react & vb->ph_dev_info.capacity
initialization outside the feature check?
> +
>  	virtio_device_ready(vdev);
>  
>  	if (towards_target(vb))
>  		virtballoon_changed(vdev);
>  	return 0;
>  
> +out_unregister_shrinker:
> +	if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_DEFLATE_ON_OOM))
> +		virtio_balloon_unregister_shrinker(vb);
>  out_del_balloon_wq:
>  	if (virtio_has_feature(vdev, VIRTIO_BALLOON_F_FREE_PAGE_HINT))
>  		destroy_workqueue(vb->balloon_wq);
> @@ -958,6 +1002,8 @@ static void virtballoon_remove(struct virtio_device *vdev)
>  {
>  	struct virtio_balloon *vb = vdev->priv;
>  
> +	if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_HINTING))
> +		page_hinting_shutdown(&vb->ph_dev_info);
>  	if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_DEFLATE_ON_OOM))
>  		virtio_balloon_unregister_shrinker(vb);
>  	spin_lock_irq(&vb->stop_update_lock);
> @@ -1027,6 +1073,7 @@ static int virtballoon_validate(struct virtio_device *vdev)
>  	VIRTIO_BALLOON_F_DEFLATE_ON_OOM,
>  	VIRTIO_BALLOON_F_FREE_PAGE_HINT,
>  	VIRTIO_BALLOON_F_PAGE_POISON,
> +	VIRTIO_BALLOON_F_HINTING,
>  };
>  
>  static struct virtio_driver virtio_balloon_driver = {
> diff --git a/include/uapi/linux/virtio_balloon.h b/include/uapi/linux/virtio_balloon.h
> index a1966cd7b677..2b0f62814e22 100644
> --- a/include/uapi/linux/virtio_balloon.h
> +++ b/include/uapi/linux/virtio_balloon.h
> @@ -36,6 +36,7 @@
>  #define VIRTIO_BALLOON_F_DEFLATE_ON_OOM	2 /* Deflate balloon on OOM */
>  #define VIRTIO_BALLOON_F_FREE_PAGE_HINT	3 /* VQ to report free pages */
>  #define VIRTIO_BALLOON_F_PAGE_POISON	4 /* Guest is using page poisoning */
> +#define VIRTIO_BALLOON_F_HINTING	5 /* Page hinting virtqueue */
>  
>  /* Size of a PFN in the balloon interface. */
>  #define VIRTIO_BALLOON_PFN_SHIFT 12
>
-- 
Thanks
Nitesh

Re: [PATCH v2 QEMU] virtio-balloon: Provide a interface for "bubble hinting"

[Nitesh Narayan Lal]

On 7/25/19 12:16 PM, Alexander Duyck wrote:
> On Thu, 2019-07-25 at 11:16 -0400, Michael S. Tsirkin wrote:
>> On Thu, Jul 25, 2019 at 08:05:30AM -0700, Alexander Duyck wrote:
>>> On Thu, 2019-07-25 at 07:35 -0400, Nitesh Narayan Lal wrote:
>>>> On 7/24/19 6:03 PM, Alexander Duyck wrote:
>>>>> On Wed, 2019-07-24 at 17:38 -0400, Michael S. Tsirkin wrote:
>>>>>> On Wed, Jul 24, 2019 at 10:12:10AM -0700, Alexander Duyck wrote:
>>>>>>> From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
>>>>>>>
>>>>>>> Add support for what I am referring to as "bubble hinting". Basically the
>>>>>>> idea is to function very similar to how the balloon works in that we
>>>>>>> basically end up madvising the page as not being used. However we don't
>>>>>>> really need to bother with any deflate type logic since the page will be
>>>>>>> faulted back into the guest when it is read or written to.
>>>>>>>
>>>>>>> This is meant to be a simplification of the existing balloon interface
>>>>>>> to use for providing hints to what memory needs to be freed. I am assuming
>>>>>>> this is safe to do as the deflate logic does not actually appear to do very
>>>>>>> much other than tracking what subpages have been released and which ones
>>>>>>> haven't.
>>>>>>>
>>>>>>> Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
>>>>>> BTW I wonder about migration here.  When we migrate we lose all hints
>>>>>> right?  Well destination could be smarter, detect that page is full of
>>>>>> 0s and just map a zero page. Then we don't need a hint as such - but I
>>>>>> don't think it's done like that ATM.
>>>>> I was wondering about that a bit myself. If you migrate with a balloon
>>>>> active what currently happens with the pages in the balloon? Do you
>>>>> actually migrate them, or do you ignore them and just assume a zero page?
>>>>> I'm just reusing the ram_block_discard_range logic that was being used for
>>>>> the balloon inflation so I would assume the behavior would be the same.
>>>> I agree, however, I think it is worth investigating to see if enabling hinting
>>>> adds some sort of overhead specifically in this kind of scenarios. What do you
>>>> think?
>>> I suspect that the hinting/reporting would probably improve migration
>>> times based on the fact that from the sound of things it would just be
>>> migrated as a zero page.
>>>
>>> I don't have a good setup for testing migration though and I am not that
>>> familiar with trying to do a live migration. That is one of the reasons
>>> why I didn't want to stray too far from the existing balloon code as that
>>> has already been tested with migration so I would assume as long as I am
>>> doing almost the exact same thing to hint the pages away it should behave
>>> exactly the same.
>>>
>>>>>> I also wonder about interaction with deflate.  ATM deflate will add
>>>>>> pages to the free list, then balloon will come right back and report
>>>>>> them as free.
>>>>> I don't know how likely it is that somebody who is getting the free page
>>>>> reporting is likely to want to also use the balloon to take up memory.
>>>> I think it is possible. There are two possibilities:
>>>> 1. User has a workload running, which is allocating and freeing the pages and at
>>>> the same time, user deflates.
>>>> If these new pages get used by this workload, we don't have to worry as you are
>>>> already handling that by not hinting the free pages immediately.
>>>> 2. Guest is idle and the user adds up some memory, for this situation what you
>>>> have explained below does seems reasonable.
>>> Us hinting on pages that are freed up via deflate wouldn't be too big of a
>>> deal. I would think that is something we could look at addressing as more
>>> of a follow-on if we ever needed to since it would just add more
>>> complexity.
>>>
>>> Really what I would like to see is the balloon itself get updated first to
>>> perhaps work with variable sized pages first so that we could then have
>>> pages come directly out of the balloon and go back into the freelist as
>>> hinted, or visa-versa where hinted pages could be pulled directly into the
>>> balloon without needing to notify the host.
>> Right, I agree. At this point the main thing I worry about is that
>> the interfaces only support one reporter, since a page flag is used.
>> So if we ever rewrite existing hinting to use the new mm
>> infrastructure then we can't e.g. enable both types of hinting.
> Does it make sense to have multiple types of hinting active at the same
> time though? That kind of seems wasteful to me. 


I agree.


> Ideally we should be able
> to provide the hints and have them feed whatever is supposed to be using
> them. So for example I could probably look at also clearing the bitmaps
> when migration is in process.
>
> Also, I am wonder if the free page hints would be redundant with the form
> of page hinting/reporting that I have since we should be migrating a much
> smaller footprint anyway if the pages have been madvised away before we
> even start the migration.
>
>> FWIW Nitesh's RFC does not have this limitation.
> Yes, but there are also limitations to his approach. For example the fact
> that the bitmap it maintains is back to being a hint rather then being
> very exact.

True.


>  As a result you could end up walking the bitmap for a while
> clearing bits without ever finding a free page.


Are referring to the overhead which will be introduced due to bitmap scanning on
very large guests?


>
>> I intend to think about this over the weekend.
> Sounds good. I'll try to get the stuff you have pointed out so far
> addressed and hopefully have v3 ready to go next week.
>
> Thanks.
>
> - Alex
>
-- 
Thanks
Nitesh

Re: [PATCH v2 4/5] mm: Introduce Hinted pages

[David Hildenbrand]

On 25.07.19 19:38, Alexander Duyck wrote:
> On Thu, 2019-07-25 at 18:48 +0200, David Hildenbrand wrote:
>> On 25.07.19 17:59, Alexander Duyck wrote:
>>> On Thu, Jul 25, 2019 at 1:53 AM David Hildenbrand <david@redhat.com> wrote:
>>>> On 24.07.19 19:03, Alexander Duyck wrote:
>>>>> From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
>>>
> 
> <snip>
> 
>>>> Can't we reuse one of the traditional page flags for that, not used
>>>> along with buddy pages? E.g., PG_dirty: Pages that were not hinted yet
>>>> are dirty.
>>>
>>> Reusing something like the dirty bit would just be confusing in my
>>> opinion. In addition it looks like Xen has also re-purposed PG_dirty
>>> already for another purpose.
>>
>> You brought up waste page management. A dirty bit for unprocessed pages
>> fits perfectly in this context. Regarding XEN, as long as it's not used
>> along with buddy pages, no issue.
> 
> I would rather not have to dirty all pages that aren't hinted. That starts
> to get too invasive. Ideally we only modify pages if we are hinting on
> them. That is why I said I didn't like the use of a dirty bit. What we
> want is more of a "guaranteed clean" bit.

Not sure if that is too invasive, but fair enough.

> 
>> FWIW, I don't even thing PG_offline matches to what you are using it
>> here for. The pages are not logically offline. They were simply buddy
>> pages that were hinted. (I'd even prefer a separate page type for that
>> instead - if we cannot simply reuse one of the other flags)
>>
>> "Offline pages" that are not actually offline in the context of the
>> buddy is way more confusing.
> 
> Right now offline and hinted are essentially the same thing since the
> effect is identical.

No they are not the same thing. Regarding virtio-balloon: You are free
to reuse any hinted pages immediate. Offline pages (a.k.a. inflated) you
might not generally reuse before deflating.

> 
> There may be cases in the future where that is not the case, but with the
> current patch set they both result in the pages being evicted from the
> guest.
> 
>>> If anything I could probably look at seeing if the PG_private flags
>>> are available when a page is in the buddy allocator which I suspect
>>> they probably are since the only users I currently see appear to be
>>> SLOB and compound pages. Either that or maybe something like PG_head
>>> might make sense since once we start allocating them we are popping
>>> the head off of the boundary list.
>>
>> Would also be fine with me.
> 
> Actually I may have found an even better bit if we are going with the
> "reporting" name. I could probably use "PG_uptodate" since it looks like
> most of its uses are related to filesystems. I will wait till I hear from
> Matthew on what bits would be available for use before I update things.

Also fine with me. In the optimal case we (in my opinion)
a) Don't reuse PG_offline
b) Don't use another page type

-- 

Thanks,

David / dhildenb

Re: [PATCH v2 5/5] virtio-balloon: Add support for providing page hints to host

[Alexander Duyck]

On Thu, 2019-07-25 at 13:42 -0400, Nitesh Narayan Lal wrote:
> On 7/24/19 1:05 PM, Alexander Duyck wrote:
> > From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> > 
> > 

<snip>

> > @@ -924,12 +956,24 @@ static int virtballoon_probe(struct virtio_device *vdev)
> >  		if (err)
> >  			goto out_del_balloon_wq;
> >  	}
> > +
> > +	vb->ph_dev_info.react = virtballoon_page_hinting_react;
> > +	vb->ph_dev_info.capacity = VIRTIO_BALLOON_ARRAY_HINTS_MAX;
> > +	if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_HINTING)) {
> > +		err = page_hinting_startup(&vb->ph_dev_info);
> > +		if (err)
> > +			goto out_unregister_shrinker;
> > +	}
> Any reason why you have kept vb->ph_dev_info.react & vb->ph_dev_info.capacity
> initialization outside the feature check?

I just had them on the outside because it didn't really matter if I
initialized them or not if the feature was not present. So I just
defaulted to initializing them in all cases.

Since I will be updating capacity to be based on the size of the hinting
queue in the next patch set I will move capacity initialization inside of
the check.

Re: [PATCH v2 QEMU] virtio-balloon: Provide a interface for "bubble hinting"

[Alexander Duyck]

On Thu, 2019-07-25 at 14:25 -0400, Nitesh Narayan Lal wrote:
> On 7/25/19 12:16 PM, Alexander Duyck wrote:
> > On Thu, 2019-07-25 at 11:16 -0400, Michael S. Tsirkin wrote:
> > > On Thu, Jul 25, 2019 at 08:05:30AM -0700, Alexander Duyck wrote:
> > > > On Thu, 2019-07-25 at 07:35 -0400, Nitesh Narayan Lal wrote:
> > > > > On 7/24/19 6:03 PM, Alexander Duyck wrote:
> > > > > > On Wed, 2019-07-24 at 17:38 -0400, Michael S. Tsirkin wrote:
> > > > > > > On Wed, Jul 24, 2019 at 10:12:10AM -0700, Alexander Duyck wrote:
> > > > > > > > From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> > > > > > > > 
> > > > > > > 

<snip>


> > Ideally we should be able
> > to provide the hints and have them feed whatever is supposed to be using
> > them. So for example I could probably look at also clearing the bitmaps
> > when migration is in process.
> > 
> > Also, I am wonder if the free page hints would be redundant with the form
> > of page hinting/reporting that I have since we should be migrating a much
> > smaller footprint anyway if the pages have been madvised away before we
> > even start the migration.
> > 
> > > FWIW Nitesh's RFC does not have this limitation.
> > Yes, but there are also limitations to his approach. For example the fact
> > that the bitmap it maintains is back to being a hint rather then being
> > very exact.
> 
> True.
> 
> 
> >  As a result you could end up walking the bitmap for a while
> > clearing bits without ever finding a free page.
> 
> Are referring to the overhead which will be introduced due to bitmap scanning on
> very large guests?

Yes. One concern I have had is that for large memory footprints the RFC
would end up having a large number of false positives on an highly active
system. I am worried it will result in a feedback loop where having more
false hits slows down your processing speed, and the slower your
processing speed the more likely you are to encounter more false hits.

Re: [PATCH v2 QEMU] virtio-balloon: Provide a interface for "bubble hinting"

[Nitesh Narayan Lal]

On 7/25/19 4:00 PM, Alexander Duyck wrote:
> On Thu, 2019-07-25 at 14:25 -0400, Nitesh Narayan Lal wrote:
>> On 7/25/19 12:16 PM, Alexander Duyck wrote:
>>> On Thu, 2019-07-25 at 11:16 -0400, Michael S. Tsirkin wrote:
>>>> On Thu, Jul 25, 2019 at 08:05:30AM -0700, Alexander Duyck wrote:
>>>>> On Thu, 2019-07-25 at 07:35 -0400, Nitesh Narayan Lal wrote:
>>>>>> On 7/24/19 6:03 PM, Alexander Duyck wrote:
>>>>>>> On Wed, 2019-07-24 at 17:38 -0400, Michael S. Tsirkin wrote:
>>>>>>>> On Wed, Jul 24, 2019 at 10:12:10AM -0700, Alexander Duyck wrote:
>>>>>>>>> From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
>>>>>>>>>
> <snip>
>
>
>>> Ideally we should be able
>>> to provide the hints and have them feed whatever is supposed to be using
>>> them. So for example I could probably look at also clearing the bitmaps
>>> when migration is in process.
>>>
>>> Also, I am wonder if the free page hints would be redundant with the form
>>> of page hinting/reporting that I have since we should be migrating a much
>>> smaller footprint anyway if the pages have been madvised away before we
>>> even start the migration.
>>>
>>>> FWIW Nitesh's RFC does not have this limitation.
>>> Yes, but there are also limitations to his approach. For example the fact
>>> that the bitmap it maintains is back to being a hint rather then being
>>> very exact.
>> True.
>>
>>
>>>  As a result you could end up walking the bitmap for a while
>>> clearing bits without ever finding a free page.
>> Are referring to the overhead which will be introduced due to bitmap scanning on
>> very large guests?
> Yes. One concern I have had is that for large memory footprints the RFC
> would end up having a large number of false positives on an highly active
> system. I am worried it will result in a feedback loop where having more
> false hits slows down your processing speed, and the slower your
> processing speed the more likely you are to encounter more false hits.
>
>

It is definitely an interesting thing to see, I intend to test such a scenario
with large guest before my next posting.

-- 
Thanks
Nitesh

Re: [PATCH v2 4/5] mm: Introduce Hinted pages

[Alexander Duyck]

On Thu, 2019-07-25 at 20:32 +0200, David Hildenbrand wrote:
> On 25.07.19 19:38, Alexander Duyck wrote:
> > On Thu, 2019-07-25 at 18:48 +0200, David Hildenbrand wrote:
> > > On 25.07.19 17:59, Alexander Duyck wrote:
> > > > On Thu, Jul 25, 2019 at 1:53 AM David Hildenbrand <david@redhat.com> wrote:
> > > > > On 24.07.19 19:03, Alexander Duyck wrote:
> > > > > > From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> > 
> > <snip>
> > 
> > > > > Can't we reuse one of the traditional page flags for that, not used
> > > > > along with buddy pages? E.g., PG_dirty: Pages that were not hinted yet
> > > > > are dirty.
> > > > 
> > > > Reusing something like the dirty bit would just be confusing in my
> > > > opinion. In addition it looks like Xen has also re-purposed PG_dirty
> > > > already for another purpose.
> > > 
> > > You brought up waste page management. A dirty bit for unprocessed pages
> > > fits perfectly in this context. Regarding XEN, as long as it's not used
> > > along with buddy pages, no issue.
> > 
> > I would rather not have to dirty all pages that aren't hinted. That starts
> > to get too invasive. Ideally we only modify pages if we are hinting on
> > them. That is why I said I didn't like the use of a dirty bit. What we
> > want is more of a "guaranteed clean" bit.
> 
> Not sure if that is too invasive, but fair enough.
> 
> > > FWIW, I don't even thing PG_offline matches to what you are using it
> > > here for. The pages are not logically offline. They were simply buddy
> > > pages that were hinted. (I'd even prefer a separate page type for that
> > > instead - if we cannot simply reuse one of the other flags)
> > > 
> > > "Offline pages" that are not actually offline in the context of the
> > > buddy is way more confusing.
> > 
> > Right now offline and hinted are essentially the same thing since the
> > effect is identical.
> 
> No they are not the same thing. Regarding virtio-balloon: You are free
> to reuse any hinted pages immediate. Offline pages (a.k.a. inflated) you
> might not generally reuse before deflating.

Okay, so it sounds like your perspective is a bit different than mine. I
was thinking of it from the perspective of the host OS where in either
case the guest has set the page as MADV_DONTNEED. You are looking at it
from the guest perspective where Offline means the guest cannot use it.

> > There may be cases in the future where that is not the case, but with the
> > current patch set they both result in the pages being evicted from the
> > guest.
> > 
> > > > If anything I could probably look at seeing if the PG_private flags
> > > > are available when a page is in the buddy allocator which I suspect
> > > > they probably are since the only users I currently see appear to be
> > > > SLOB and compound pages. Either that or maybe something like PG_head
> > > > might make sense since once we start allocating them we are popping
> > > > the head off of the boundary list.
> > > 
> > > Would also be fine with me.
> > 
> > Actually I may have found an even better bit if we are going with the
> > "reporting" name. I could probably use "PG_uptodate" since it looks like
> > most of its uses are related to filesystems. I will wait till I hear from
> > Matthew on what bits would be available for use before I update things.
> 
> Also fine with me. In the optimal case we (in my opinion)
> a) Don't reuse PG_offline
> b) Don't use another page type

That is fine. I just need to determine the exact flag to use then. I'll do
some more research and wait to see if anyone else from MM comunity has
input or suggestions on the page flag to be used. From what I can tell it
looks like there are a bunch of flag bits that are unused as far as the
buddy pages are concerned so I should have a few to choose from.

Re: [PATCH v2 4/5] mm: Introduce Hinted pages

[David Hildenbrand]

On 25.07.19 22:37, Alexander Duyck wrote:
> On Thu, 2019-07-25 at 20:32 +0200, David Hildenbrand wrote:
>> On 25.07.19 19:38, Alexander Duyck wrote:
>>> On Thu, 2019-07-25 at 18:48 +0200, David Hildenbrand wrote:
>>>> On 25.07.19 17:59, Alexander Duyck wrote:
>>>>> On Thu, Jul 25, 2019 at 1:53 AM David Hildenbrand <david@redhat.com> wrote:
>>>>>> On 24.07.19 19:03, Alexander Duyck wrote:
>>>>>>> From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
>>>
>>> <snip>
>>>
>>>>>> Can't we reuse one of the traditional page flags for that, not used
>>>>>> along with buddy pages? E.g., PG_dirty: Pages that were not hinted yet
>>>>>> are dirty.
>>>>>
>>>>> Reusing something like the dirty bit would just be confusing in my
>>>>> opinion. In addition it looks like Xen has also re-purposed PG_dirty
>>>>> already for another purpose.
>>>>
>>>> You brought up waste page management. A dirty bit for unprocessed pages
>>>> fits perfectly in this context. Regarding XEN, as long as it's not used
>>>> along with buddy pages, no issue.
>>>
>>> I would rather not have to dirty all pages that aren't hinted. That starts
>>> to get too invasive. Ideally we only modify pages if we are hinting on
>>> them. That is why I said I didn't like the use of a dirty bit. What we
>>> want is more of a "guaranteed clean" bit.
>>
>> Not sure if that is too invasive, but fair enough.
>>
>>>> FWIW, I don't even thing PG_offline matches to what you are using it
>>>> here for. The pages are not logically offline. They were simply buddy
>>>> pages that were hinted. (I'd even prefer a separate page type for that
>>>> instead - if we cannot simply reuse one of the other flags)
>>>>
>>>> "Offline pages" that are not actually offline in the context of the
>>>> buddy is way more confusing.
>>>
>>> Right now offline and hinted are essentially the same thing since the
>>> effect is identical.
>>
>> No they are not the same thing. Regarding virtio-balloon: You are free
>> to reuse any hinted pages immediate. Offline pages (a.k.a. inflated) you
>> might not generally reuse before deflating.
> 
> Okay, so it sounds like your perspective is a bit different than mine. I
> was thinking of it from the perspective of the host OS where in either
> case the guest has set the page as MADV_DONTNEED. You are looking at it
> from the guest perspective where Offline means the guest cannot use it.
> 
>>> There may be cases in the future where that is not the case, but with the
>>> current patch set they both result in the pages being evicted from the
>>> guest.
>>>
>>>>> If anything I could probably look at seeing if the PG_private flags
>>>>> are available when a page is in the buddy allocator which I suspect
>>>>> they probably are since the only users I currently see appear to be
>>>>> SLOB and compound pages. Either that or maybe something like PG_head
>>>>> might make sense since once we start allocating them we are popping
>>>>> the head off of the boundary list.
>>>>
>>>> Would also be fine with me.
>>>
>>> Actually I may have found an even better bit if we are going with the
>>> "reporting" name. I could probably use "PG_uptodate" since it looks like
>>> most of its uses are related to filesystems. I will wait till I hear from
>>> Matthew on what bits would be available for use before I update things.
>>
>> Also fine with me. In the optimal case we (in my opinion)
>> a) Don't reuse PG_offline
>> b) Don't use another page type
> 
> That is fine. I just need to determine the exact flag to use then. I'll do
> some more research and wait to see if anyone else from MM comunity has
> input or suggestions on the page flag to be used. From what I can tell it
> looks like there are a bunch of flag bits that are unused as far as the
> buddy pages are concerned so I should have a few to choose from.

Right, and I would favor that - at least less hacking with the
kexec/kdump interface :)

You can then go ahead and add

PG_hinted or PG_reported = PG_*younameit* and properly document how it
is being used along with PageBuddy() only.

-- 

Thanks,

David / dhildenb

Re: [PATCH v2 4/5] mm: Introduce Hinted pages

[Nitesh Narayan Lal]

On 7/24/19 1:03 PM, Alexander Duyck wrote:
> From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
>
> In order to pave the way for free page hinting in virtualized environments
> we will need a way to get pages out of the free lists and identify those
> pages after they have been returned. To accomplish this, this patch adds
> the concept of a Hinted Buddy, which is essentially meant to just be the
> Offline page type used in conjunction with the Buddy page type.
>
> It adds a set of pointers we shall call "boundary" which represents the
> upper boundary between the unhinted and hinted pages. The general idea is
> that in order for a page to cross from one side of the boundary to the
> other it will need to go through the hinting process. Ultimately a
> free_list has been fully processed when the boundary has been moved from
> the tail all they way up to occupying the first entry in the list.
>
> Doing this we should be able to make certain that we keep the hinted
> pages as one contiguous block in each free list. This will allow us to
> efficiently manipulate the free lists whenever we need to go in and start
> sending hints to the hypervisor that there are new pages that have been
> freed and are no longer in use.
>
> An added advantage to this approach is that we should be reducing the
> overall memory footprint of the guest as it will be more likely to recycle
> warm pages versus trying to allocate the hinted pages that were likely
> evicted from the guest memory.
>
> Since we will only be hinting one zone at a time we keep the boundary
> limited to being defined for just the zone we are currently placing hinted
> pages into. Doing this we can keep the number of additional pointers needed
> quite small. To flag that the boundaries are in place we use a single bit
> in the zone to indicate that hinting and the boundaries are active.
>
> The determination of when to start hinting is based on the tracking of the
> number of free pages in a given area versus the number of hinted pages in
> that area. We keep track of the number of hinted pages per free_area in a
> separate zone specific area. We do this to avoid modifying the free_area
> structure as this can lead to false sharing for the highest order with the
> zone lock which leads to a noticeable performance degradation.
>
> Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> ---
>  include/linux/mmzone.h       |   40 +++++-
>  include/linux/page-flags.h   |    8 +
>  include/linux/page_hinting.h |  139 ++++++++++++++++++++
>  mm/Kconfig                   |    5 +
>  mm/Makefile                  |    1 
>  mm/memory_hotplug.c          |    1 
>  mm/page_alloc.c              |  136 ++++++++++++++++++-
>  mm/page_hinting.c            |  298 ++++++++++++++++++++++++++++++++++++++++++
>  8 files changed, 620 insertions(+), 8 deletions(-)
>  create mode 100644 include/linux/page_hinting.h
>  create mode 100644 mm/page_hinting.c
>
> diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
> index f0c68b6b6154..42bdebb20484 100644
> --- a/include/linux/mmzone.h
> +++ b/include/linux/mmzone.h
> @@ -460,6 +460,14 @@ struct zone {
>  	seqlock_t		span_seqlock;
>  #endif
>  
> +#ifdef CONFIG_PAGE_HINTING
> +	/*
> +	 * Pointer to hinted page tracking statistics array. The size of
> +	 * the array is MAX_ORDER - PAGE_HINTING_MIN_ORDER. NULL when
> +	 * page hinting is not present.
> +	 */
> +	unsigned long		*hinted_pages;
> +#endif
>  	int initialized;
>  
>  	/* Write-intensive fields used from the page allocator */
> @@ -535,6 +543,14 @@ enum zone_flags {
>  	ZONE_BOOSTED_WATERMARK,		/* zone recently boosted watermarks.
>  					 * Cleared when kswapd is woken.
>  					 */
> +	ZONE_PAGE_HINTING_REQUESTED,	/* zone enabled page hinting and has
> +					 * requested flushing the data out of
> +					 * higher order pages.
> +					 */
> +	ZONE_PAGE_HINTING_ACTIVE,	/* zone enabled page hinting and is
> +					 * activly flushing the data out of
> +					 * higher order pages.
> +					 */
>  };
>  
>  static inline unsigned long zone_managed_pages(struct zone *zone)
> @@ -755,6 +771,8 @@ static inline bool pgdat_is_empty(pg_data_t *pgdat)
>  	return !pgdat->node_start_pfn && !pgdat->node_spanned_pages;
>  }
>  
> +#include <linux/page_hinting.h>
> +
>  /* Used for pages not on another list */
>  static inline void add_to_free_list(struct page *page, struct zone *zone,
>  				    unsigned int order, int migratetype)
> @@ -769,10 +787,16 @@ static inline void add_to_free_list(struct page *page, struct zone *zone,
>  static inline void add_to_free_list_tail(struct page *page, struct zone *zone,
>  					 unsigned int order, int migratetype)
>  {
> -	struct free_area *area = &zone->free_area[order];
> +	struct list_head *tail = get_unhinted_tail(zone, order, migratetype);
>  
> -	list_add_tail(&page->lru, &area->free_list[migratetype]);
> -	area->nr_free++;
> +	/*
> +	 * To prevent the unhinted pages from being interleaved with the
> +	 * hinted ones while we are actively processing pages we will use
> +	 * the head of the hinted pages to determine the tail of the free
> +	 * list.
> +	 */
> +	list_add_tail(&page->lru, tail);
> +	zone->free_area[order].nr_free++;
>  }
>  
>  /* Used for pages which are on another list */
> @@ -781,12 +805,22 @@ static inline void move_to_free_list(struct page *page, struct zone *zone,
>  {
>  	struct free_area *area = &zone->free_area[order];
>  
> +	/*
> +	 * Clear Hinted flag, if present, to avoid placing hinted pages
> +	 * at the top of the free_list. It is cheaper to just process this
> +	 * page again, then have to walk around a page that is already hinted.
> +	 */
> +	clear_page_hinted(page, zone);
> +
>  	list_move(&page->lru, &area->free_list[migratetype]);
>  }
>  
>  static inline void del_page_from_free_list(struct page *page, struct zone *zone,
>  					   unsigned int order)
>  {
> +	/* Clear Hinted flag, if present, before clearing the Buddy flag */
> +	clear_page_hinted(page, zone);
> +
>  	list_del(&page->lru);
>  	__ClearPageBuddy(page);
>  	set_page_private(page, 0);
> diff --git a/include/linux/page-flags.h b/include/linux/page-flags.h
> index b848517da64c..b753dbf673cb 100644
> --- a/include/linux/page-flags.h
> +++ b/include/linux/page-flags.h
> @@ -745,6 +745,14 @@ static inline int page_has_type(struct page *page)
>  PAGE_TYPE_OPS(Offline, offline)
>  
>  /*
> + * PageHinted() is an alias for Offline, however it is not meant to be an
> + * exclusive value. It should be combined with PageBuddy() when seen as it
> + * is meant to indicate that the page has been scrubbed while waiting in
> + * the buddy system.
> + */
> +PAGE_TYPE_OPS(Hinted, offline)
> +
> +/*
>   * If kmemcg is enabled, the buddy allocator will set PageKmemcg() on
>   * pages allocated with __GFP_ACCOUNT. It gets cleared on page free.
>   */
> diff --git a/include/linux/page_hinting.h b/include/linux/page_hinting.h
> new file mode 100644
> index 000000000000..526fb26663d9
> --- /dev/null
> +++ b/include/linux/page_hinting.h
> @@ -0,0 +1,139 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef _LINUX_PAGE_HINTING_H
> +#define _LINUX_PAGE_HINTING_H
> +
> +#include <linux/mmzone.h>
> +#include <linux/jump_label.h>
> +#include <linux/pageblock-flags.h>
> +#include <asm/pgtable_types.h>
> +
> +#define PAGE_HINTING_MIN_ORDER	pageblock_order
> +#define PAGE_HINTING_HWM		32
> +
> +#ifdef CONFIG_PAGE_HINTING
> +struct page_hinting_dev_info {
> +	/* function that alters pages to make them "hinted" */
> +	void (*react)(struct page_hinting_dev_info *phdev,
> +		      unsigned int num_hints);
> +
> +	/* scatterlist containing pages to be processed */
> +	struct scatterlist *sg;
> +
> +	/*
> +	 * Upper limit on the number of pages that the react function
> +	 * expects to be placed into the batch list to be processed.
> +	 */
> +	unsigned long capacity;
> +
> +	/* work struct for processing hints */
> +	struct delayed_work work;
> +
> +	/*
> +	 * The number of zones requesting hinting, plus one additional if
> +	 * processing thread is active.
> +	 */
> +	atomic_t refcnt;
> +};
> +
> +extern struct static_key page_hinting_notify_enabled;
> +
> +/* Boundary functions */
> +struct list_head *__page_hinting_get_boundary(unsigned int order,
> +					      int migratetype);
> +void page_hinting_del_from_boundary(struct page *page, struct zone *zone);
> +void page_hinting_add_to_boundary(struct page *page, struct zone *zone,
> +			     int migratetype);
> +
> +/* Hinted page accessors, defined in page_alloc.c */
> +struct page *get_unhinted_page(struct zone *zone, unsigned int order,
> +			       int migratetype);
> +void put_hinted_page(struct zone *zone, struct page *page);
> +
> +void __page_hinting_request(struct zone *zone);
> +void __page_hinting_free_stats(struct zone *zone);
> +
> +/* Tear-down and bring-up for page hinting devices */
> +void page_hinting_shutdown(struct page_hinting_dev_info *phdev);
> +int page_hinting_startup(struct page_hinting_dev_info *phdev);
> +#endif /* CONFIG_PAGE_HINTING */
> +
> +static inline struct list_head *get_unhinted_tail(struct zone *zone,
> +						  unsigned int order,
> +						  int migratetype)
> +{
> +#ifdef CONFIG_PAGE_HINTING
> +	if (order >= PAGE_HINTING_MIN_ORDER &&
> +	    test_bit(ZONE_PAGE_HINTING_ACTIVE, &zone->flags))
> +		return __page_hinting_get_boundary(order, migratetype);
> +#endif
> +	return &zone->free_area[order].free_list[migratetype];
> +}
> +
> +static inline void clear_page_hinted(struct page *page,
> +				     struct zone *zone)
> +{
> +#ifdef CONFIG_PAGE_HINTING
> +	if (likely(!PageHinted(page)))
> +		return;
> +
> +	/* push boundary back if we removed the upper boundary */
> +	if (test_bit(ZONE_PAGE_HINTING_ACTIVE, &zone->flags))
> +		page_hinting_del_from_boundary(page, zone);
> +
> +	__ClearPageHinted(page);
> +
> +	/* page_private will contain the page order, so just use it directly */
> +	zone->hinted_pages[page_private(page) - PAGE_HINTING_MIN_ORDER]--;
> +#endif
> +}
> +
> +/* Free hinted_pages and reset hinted page tracking count to 0 */
> +static inline void page_hinting_reset(struct zone *zone)
> +{
> +#ifdef CONFIG_PAGE_HINTING
> +	if (zone->hinted_pages)
> +		__page_hinting_free_stats(zone);
> +#endif
> +}
> +
> +/**
> + * page_hinting_notify_free - Free page notification to start page processing
> + * @zone: Pointer to current zone of last page processed
> + * @order: Order of last page added to zone
> + *
> + * This function is meant to act as a screener for __page_hinting_request which
> + * will determine if a give zone has crossed over the high-water mark that
> + * will justify us beginning page treatment. If we have crossed that
> + * threshold then it will start the process of pulling some pages and
> + * placing them in the batch list for treatment.
> + */
> +static inline void page_hinting_notify_free(struct zone *zone, int order)
> +{
> +#ifdef CONFIG_PAGE_HINTING
> +	unsigned long nr_hinted;
> +
> +	/* Called from hot path in __free_one_page() */
> +	if (!static_key_false(&page_hinting_notify_enabled))
> +		return;
> +
> +	/* Limit notifications only to higher order pages */
> +	if (order < PAGE_HINTING_MIN_ORDER)
> +		return;
> +
> +	/* Do not bother with tests if we have already requested hinting */
> +	if (test_bit(ZONE_PAGE_HINTING_REQUESTED, &zone->flags))
> +		return;
> +
> +	/* If hinted_pages is not populated, assume 0 */
> +	nr_hinted = zone->hinted_pages ?
> +		    zone->hinted_pages[order - PAGE_HINTING_MIN_ORDER] : 0;
> +
> +	/* Only request it if we have enough to begin the page hinting */
> +	if (zone->free_area[order].nr_free < nr_hinted + PAGE_HINTING_HWM)
> +		return;
> +
> +	/* This is slow, but should be called very rarely */
> +	__page_hinting_request(zone);
> +#endif
> +}
> +#endif /*_LINUX_PAGE_HINTING_H */
> diff --git a/mm/Kconfig b/mm/Kconfig
> index 56cec636a1fc..38354668f849 100644
> --- a/mm/Kconfig
> +++ b/mm/Kconfig
> @@ -237,6 +237,11 @@ config COMPACTION
>            linux-mm@kvack.org.
>  
>  #
> +# support for free page hinting
> +config PAGE_HINTING
> +	bool
> +
> +#
>  # support for page migration
>  #
>  config MIGRATION
> diff --git a/mm/Makefile b/mm/Makefile
> index 338e528ad436..7277ced923ab 100644
> --- a/mm/Makefile
> +++ b/mm/Makefile
> @@ -104,3 +104,4 @@ obj-$(CONFIG_HARDENED_USERCOPY) += usercopy.o
>  obj-$(CONFIG_PERCPU_STATS) += percpu-stats.o
>  obj-$(CONFIG_HMM_MIRROR) += hmm.o
>  obj-$(CONFIG_MEMFD_CREATE) += memfd.o
> +obj-$(CONFIG_PAGE_HINTING) += page_hinting.o
> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> index 2a9bbddb0e55..7c2d49b1a918 100644
> --- a/mm/memory_hotplug.c
> +++ b/mm/memory_hotplug.c
> @@ -1622,6 +1622,7 @@ static int __ref __offline_pages(unsigned long start_pfn,
>  	if (!populated_zone(zone)) {
>  		zone_pcp_reset(zone);
>  		build_all_zonelists(NULL);
> +		page_hinting_reset(zone);
>  	} else
>  		zone_pcp_update(zone);
>  
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 9a73f69b37af..c83cb4a30aff 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -68,6 +68,7 @@
>  #include <linux/lockdep.h>
>  #include <linux/nmi.h>
>  #include <linux/psi.h>
> +#include <linux/page_hinting.h>
>  
>  #include <asm/sections.h>
>  #include <asm/tlbflush.h>
> @@ -915,7 +916,7 @@ static inline struct capture_control *task_capc(struct zone *zone)
>  static inline void __free_one_page(struct page *page,
>  		unsigned long pfn,
>  		struct zone *zone, unsigned int order,
> -		int migratetype)
> +		int migratetype, bool hinted)
>  {
>  	struct capture_control *capc = task_capc(zone);
>  	unsigned long uninitialized_var(buddy_pfn);
> @@ -990,11 +991,20 @@ static inline void __free_one_page(struct page *page,
>  done_merging:
>  	set_page_order(page, order);
>  
> -	if (is_shuffle_order(order) ? shuffle_add_to_tail() :
> -	    buddy_merge_likely(pfn, buddy_pfn, page, order))
> +	if (hinted ||
> +	    (is_shuffle_order(order) ? shuffle_add_to_tail() :
> +	     buddy_merge_likely(pfn, buddy_pfn, page, order)))
>  		add_to_free_list_tail(page, zone, order, migratetype);
>  	else
>  		add_to_free_list(page, zone, order, migratetype);
> +
> +	/*
> +	 * No need to notify on a hinted page as the total count of
> +	 * unhinted pages will not have increased since we have essentially
> +	 * merged the hinted page with one or more unhinted pages.
> +	 */
> +	if (!hinted)
> +		page_hinting_notify_free(zone, order);
>  }
>  
>  /*
> @@ -1305,7 +1315,7 @@ static void free_pcppages_bulk(struct zone *zone, int count,
>  		if (unlikely(isolated_pageblocks))
>  			mt = get_pageblock_migratetype(page);
>  
> -		__free_one_page(page, page_to_pfn(page), zone, 0, mt);
> +		__free_one_page(page, page_to_pfn(page), zone, 0, mt, false);
>  		trace_mm_page_pcpu_drain(page, 0, mt);
>  	}
>  	spin_unlock(&zone->lock);
> @@ -1321,7 +1331,7 @@ static void free_one_page(struct zone *zone,
>  		is_migrate_isolate(migratetype))) {
>  		migratetype = get_pfnblock_migratetype(page, pfn);
>  	}
> -	__free_one_page(page, pfn, zone, order, migratetype);
> +	__free_one_page(page, pfn, zone, order, migratetype, false);
>  	spin_unlock(&zone->lock);
>  }
>  
> @@ -2183,6 +2193,122 @@ struct page *__rmqueue_smallest(struct zone *zone, unsigned int order,
>  	return NULL;
>  }
>  
> +#ifdef CONFIG_PAGE_HINTING
> +/**
> + * get_unhinted_page - Pull an unhinted page from the free_list
> + * @zone: Zone to draw pages from
> + * @order: Order to draw pages from
> + * @mt: Migratetype to draw pages from
> + *
> + * This function will obtain a page from the free list. It will start by
> + * attempting to pull from the tail of the free list and if that is already
> + * hinted on it will instead pull the head if that is unhinted.
> + *
> + * The page will have the migrate type and order stored in the page
> + * metadata. While being processed the page will not be avaialble for
> + * allocation.
> + *
> + * Return: page pointer if raw page found, otherwise NULL
> + */
> +struct page *get_unhinted_page(struct zone *zone, unsigned int order, int mt)
> +{
> +	struct list_head *tail = get_unhinted_tail(zone, order, mt);
> +	struct free_area *area = &(zone->free_area[order]);
> +	struct list_head *list = &area->free_list[mt];
> +	struct page *page;
> +
> +	/* zone lock should be held when this function is called */
> +	lockdep_assert_held(&zone->lock);
> +
> +	/* Find a page of the appropriate size in the preferred list */
> +	page = list_last_entry(tail, struct page, lru);
> +	list_for_each_entry_from_reverse(page, list, lru) {
> +		/* If we entered this loop then the "raw" list isn't empty */
> +
> +		/* If the page is hinted try the head of the list */
> +		if (PageHinted(page)) {
> +			page = list_first_entry(list, struct page, lru);
> +
> +			/*
> +			 * If both the head and tail are hinted then reset
> +			 * the boundary so that we read as an empty list
> +			 * next time and bail out.
> +			 */
> +			if (PageHinted(page)) {
> +				page_hinting_add_to_boundary(page, zone, mt);
> +				break;
> +			}
> +		}
> +
> +		del_page_from_free_list(page, zone, order);
> +
> +		/* record migratetype and order within page */
> +		set_pcppage_migratetype(page, mt);
> +		set_page_private(page, order);
> +
> +		/*
> +		 * Page will not be available for allocation while we are
> +		 * processing it so update the freepage state.
> +		 */
> +		__mod_zone_freepage_state(zone, -(1 << order), mt);
> +
> +		return page;
> +	}
> +
> +	return NULL;
> +}
> +
> +/**
> + * put_hinted_page - Return a now-hinted page back where we got it
> + * @zone: Zone to return pages to
> + * @page: Page that was hinted
> + *
> + * This function will pull the migratetype and order information out
> + * of the page and attempt to return it where it found it. If the page
> + * is added to the free list without changes we will mark it as being
> + * hinted.
> + */
> +void put_hinted_page(struct zone *zone, struct page *page)
> +{
> +	unsigned int order, mt;
> +	unsigned long pfn;
> +
> +	/* zone lock should be held when this function is called */
> +	lockdep_assert_held(&zone->lock);
> +
> +	mt = get_pcppage_migratetype(page);
> +	pfn = page_to_pfn(page);
> +
> +	if (unlikely(has_isolate_pageblock(zone) || is_migrate_isolate(mt))) {
> +		mt = get_pfnblock_migratetype(page, pfn);
> +		set_pcppage_migratetype(page, mt);
> +	}
> +
> +	order = page_private(page);
> +	set_page_private(page, 0);
> +
> +	__free_one_page(page, pfn, zone, order, mt, true);
> +
> +	/*
> +	 * If page was comingled with another page we cannot consider
> +	 * the result to be "hinted" since part of the page hasn't been.
> +	 * In this case we will simply exit and not update the "hinted"
> +	 * state. Instead just treat the result as a unhinted page.
> +	 */
> +	if (!PageBuddy(page) || page_order(page) != order)
> +		return;
> +
> +	/* update areated page accounting */
> +	zone->hinted_pages[order - PAGE_HINTING_MIN_ORDER]++;
> +
> +	/* update boundary of new migratetype and record it */
> +	page_hinting_add_to_boundary(page, zone, mt);
> +
> +	/* flag page as hinted */
> +	__SetPageHinted(page);
> +}
> +#endif /* CONFIG_PAGE_HINTING */
> +
>  /*
>   * This array describes the order lists are fallen back to when
>   * the free lists for the desirable migrate type are depleted
> diff --git a/mm/page_hinting.c b/mm/page_hinting.c
> new file mode 100644
> index 000000000000..d06d3762b315
> --- /dev/null
> +++ b/mm/page_hinting.c
> @@ -0,0 +1,298 @@
> +// SPDX-License-Identifier: GPL-2.0
> +#include <linux/mm.h>
> +#include <linux/mmzone.h>
> +#include <linux/page-isolation.h>
> +#include <linux/gfp.h>
> +#include <linux/export.h>
> +#include <linux/delay.h>
> +#include <linux/slab.h>
> +#include <linux/scatterlist.h>
> +#include "internal.h"
> +
> +static struct page_hinting_dev_info __rcu *ph_dev_info __read_mostly;
> +struct static_key page_hinting_notify_enabled;
> +
> +struct list_head *boundary[MAX_ORDER - PAGE_HINTING_MIN_ORDER][MIGRATE_TYPES];
> +
> +static void page_hinting_reset_boundary(struct zone *zone, unsigned int order,
> +				   unsigned int migratetype)
> +{
> +	boundary[order - PAGE_HINTING_MIN_ORDER][migratetype] =
> +			&zone->free_area[order].free_list[migratetype];
> +}
> +
> +#define for_each_hinting_migratetype_order(_order, _type) \
> +	for (_order = MAX_ORDER; _order-- != PAGE_HINTING_MIN_ORDER;) \
> +		for (_type = MIGRATE_TYPES; _type--;)
> +
> +static int page_hinting_populate_metadata(struct zone *zone)
> +{
> +	unsigned int order, mt;
> +
> +	/*
> +	 * We need to make sure we have somewhere to store the tracking
> +	 * data for how many hinted pages are in the zone. To do that
> +	 * we need to make certain zone->hinted_pages is populated.
> +	 */
> +	if (!zone->hinted_pages) {
> +		zone->hinted_pages = kcalloc(MAX_ORDER - PAGE_HINTING_MIN_ORDER,
> +					     sizeof(unsigned long),
> +					     GFP_KERNEL);
> +		if (!zone->hinted_pages)
> +			return -ENOMEM;
> +	}
> +
> +	/* Update boundary data to reflect the zone we are currently working */
> +	for_each_hinting_migratetype_order(order, mt)
> +		page_hinting_reset_boundary(zone, order, mt);
> +
> +	return 0;
> +}
> +
> +struct list_head *__page_hinting_get_boundary(unsigned int order,
> +					      int migratetype)
> +{
> +	return boundary[order - PAGE_HINTING_MIN_ORDER][migratetype];
> +}
> +
> +void page_hinting_del_from_boundary(struct page *page, struct zone *zone)
> +{
> +	unsigned int order = page_private(page) - PAGE_HINTING_MIN_ORDER;
> +	int mt = get_pcppage_migratetype(page);
> +	struct list_head **tail = &boundary[order][mt];
> +
> +	if (*tail == &page->lru)
> +		*tail = page->lru.next;
> +}
> +
> +void page_hinting_add_to_boundary(struct page *page, struct zone *zone,
> +			     int migratetype)
> +{
> +	unsigned int order = page_private(page) - PAGE_HINTING_MIN_ORDER;
> +	struct list_head **tail = &boundary[order][migratetype];
> +
> +	*tail = &page->lru;
> +}
> +
> +static unsigned int page_hinting_fill(struct zone *zone,
> +				      struct page_hinting_dev_info *phdev)
> +{
> +	struct scatterlist *sg = phdev->sg;
> +	unsigned int order, mt, count = 0;
> +
> +	sg_init_table(phdev->sg, phdev->capacity);
> +
> +	for_each_hinting_migratetype_order(order, mt) {
> +		struct page *page;
> +
> +		/*
> +		 * Pull pages from free list until we have drained
> +		 * it or we have reached capacity.
> +		 */
> +		while ((page = get_unhinted_page(zone, order, mt))) {
> +			sg_set_page(&sg[count], page, PAGE_SIZE << order, 0);
> +
> +			if (++count == phdev->capacity)
> +				return count;
> +		}
> +	}
> +
> +	/* mark end of scatterlist due to underflow */
> +	if (count)
> +		sg_mark_end(&sg[count - 1]);
> +
> +	/*
> +	 * If there are no longer enough free pages to fully populate
> +	 * the scatterlist, then we can just shut it down for this zone.
> +	 */
> +	clear_bit(ZONE_PAGE_HINTING_REQUESTED, &zone->flags);
> +	atomic_dec(&phdev->refcnt);
> +
> +	return count;
> +}
> +
> +static void page_hinting_drain(struct zone *zone,
> +			       struct page_hinting_dev_info *phdev)
> +{
> +	struct scatterlist *sg = phdev->sg;
> +
> +	/*
> +	 * Drain the now hinted pages back into their respective
> +	 * free lists/areas. We assume at least one page is populated.
> +	 */
> +	do {
> +		put_hinted_page(zone, sg_page(sg));
> +	} while (!sg_is_last(sg++));
> +}
> +
> +/*
> + * The page hinting cycle consists of 4 stages, fill, react, drain, and idle.
> + * We will cycle through the first 3 stages until we fail to obtain any
> + * pages, in that case we will switch to idle.
> + */
> +static void page_hinting_cycle(struct zone *zone,
> +			       struct page_hinting_dev_info *phdev)
> +{
> +	/*
> +	 * Guarantee boundaries and stats are populated before we
> +	 * start placing hinted pages in the zone.
> +	 */
> +	if (page_hinting_populate_metadata(zone))
> +		return;
> +
> +	spin_lock(&zone->lock);
> +
> +	/* set bit indicating boundaries are present */
> +	set_bit(ZONE_PAGE_HINTING_ACTIVE, &zone->flags);
> +
> +	do {
> +		/* Pull pages out of allocator into a scaterlist */
> +		unsigned int num_hints = page_hinting_fill(zone, phdev);
> +
> +		/* no pages were acquired, give up */
> +		if (!num_hints)
> +			break;
> +
> +		spin_unlock(&zone->lock);

Is there any recommendation in general about how/where we should lock and unlock
zones in the code? For instance, over here you have a zone lock outside the loop
and you are unlocking it inside the loop and then re-acquiring it.
My guess is we should be fine as long as:
1. We are not holding the lock for a very long time.
2. We are making sure that if we have a zone lock we are releasing it before
returning from the function.

> +
> +		/* begin processing pages in local list */
> +		phdev->react(phdev, num_hints);
> +
> +		spin_lock(&zone->lock);
> +
> +		/*
> +		 * We should have a scatterlist of pages that have been
> +		 * processed. Return them to their original free lists.
> +		 */
> +		page_hinting_drain(zone, phdev);
> +
> +		/* keep pulling pages till there are none to pull */
> +	} while (test_bit(ZONE_PAGE_HINTING_REQUESTED, &zone->flags));
> +
> +	/* processing of the zone is complete, we can disable boundaries */
> +	clear_bit(ZONE_PAGE_HINTING_ACTIVE, &zone->flags);
> +
> +	spin_unlock(&zone->lock);
> +}
> +
> +static void page_hinting_process(struct work_struct *work)
> +{
> +	struct delayed_work *d_work = to_delayed_work(work);
> +	struct page_hinting_dev_info *phdev =
> +		container_of(d_work, struct page_hinting_dev_info, work);
> +	struct zone *zone = first_online_pgdat()->node_zones;
> +
> +	do {
> +		if (test_bit(ZONE_PAGE_HINTING_REQUESTED, &zone->flags))
> +			page_hinting_cycle(zone, phdev);
> +
> +		/*
> +		 * Move to next zone, if at the end of the list
> +		 * test to see if we can just go into idle.
> +		 */
> +		zone = next_zone(zone);
> +		if (zone)
> +			continue;
> +		zone = first_online_pgdat()->node_zones;
> +
> +		/*
> +		 * As long as refcnt has not reached zero there are still
> +		 * zones to be processed.
> +		 */
> +	} while (atomic_read(&phdev->refcnt));
> +}
> +
> +/* request page hinting on this zone */
> +void __page_hinting_request(struct zone *zone)
> +{
> +	struct page_hinting_dev_info *phdev;
> +
> +	rcu_read_lock();
> +
> +	/*
> +	 * We use RCU to protect the ph_dev_info pointer. In almost all
> +	 * cases this should be present, however in the unlikely case of
> +	 * a shutdown this will be NULL and we should exit.
> +	 */
> +	phdev = rcu_dereference(ph_dev_info);
> +	if (unlikely(!phdev))
> +		return;
> +
> +	/*
> +	 * We can use separate test and set operations here as there
> +	 * is nothing else that can set or clear this bit while we are
> +	 * holding the zone lock. The advantage to doing it this way is
> +	 * that we don't have to dirty the cacheline unless we are
> +	 * changing the value.
> +	 */
> +	set_bit(ZONE_PAGE_HINTING_REQUESTED, &zone->flags);
> +
> +	/*
> +	 * Delay the start of work to allow a sizable queue to
> +	 * build. For now we are limiting this to running no more
> +	 * than 10 times per second.
> +	 */
> +	if (!atomic_fetch_inc(&phdev->refcnt))
> +		schedule_delayed_work(&phdev->work, HZ / 10);
> +
> +	rcu_read_unlock();
> +}
> +
> +void __page_hinting_free_stats(struct zone *zone)
> +{
> +	/* free hinted_page statisitics */
> +	kfree(zone->hinted_pages);
> +	zone->hinted_pages = NULL;
> +}
> +
> +void page_hinting_shutdown(struct page_hinting_dev_info *phdev)
> +{
> +	if (rcu_access_pointer(ph_dev_info) != phdev)
> +		return;
> +
> +	/* Disable page hinting notification */
> +	static_key_slow_dec(&page_hinting_notify_enabled);
> +	RCU_INIT_POINTER(ph_dev_info, NULL);
> +	synchronize_rcu();
> +
> +	/* Flush any existing work, and lock it out */
> +	cancel_delayed_work_sync(&phdev->work);
> +
> +	/* Free scatterlist */
> +	kfree(phdev->sg);
> +	phdev->sg = NULL;
> +}
> +EXPORT_SYMBOL_GPL(page_hinting_shutdown);
> +
> +int page_hinting_startup(struct page_hinting_dev_info *phdev)
> +{
> +	struct zone *zone;
> +
> +	/* nothing to do if already in use */
> +	if (rcu_access_pointer(ph_dev_info))
> +		return -EBUSY;
> +
> +	/* allocate scatterlist to store pages being hinted on */
> +	phdev->sg = kcalloc(phdev->capacity, sizeof(*phdev->sg), GFP_KERNEL);
> +	if (!phdev->sg)
> +		return -ENOMEM;
> +
> +	/* initialize refcnt and work structures */
> +	atomic_set(&phdev->refcnt, 0);
> +	INIT_DELAYED_WORK(&phdev->work, &page_hinting_process);
> +
> +	/* assign device, and begin initial flush of populated zones */
> +	rcu_assign_pointer(ph_dev_info, phdev);
> +	for_each_populated_zone(zone) {
> +		spin_lock(&zone->lock);
> +		__page_hinting_request(zone);
> +		spin_unlock(&zone->lock);
> +	}
> +
> +	/* enable page hinting notification */
> +	static_key_slow_inc(&page_hinting_notify_enabled);
> +
> +	return 0;
> +}
> +EXPORT_SYMBOL_GPL(page_hinting_startup);
> +
>
-- 
Thanks
Nitesh

Re: [PATCH v2 4/5] mm: Introduce Hinted pages

[Alexander Duyck]

On Fri, 2019-07-26 at 08:24 -0400, Nitesh Narayan Lal wrote:
> On 7/24/19 1:03 PM, Alexander Duyck wrote:
> > From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> > 
> > 

<snip>

> > +/*
> > + * The page hinting cycle consists of 4 stages, fill, react, drain, and idle.
> > + * We will cycle through the first 3 stages until we fail to obtain any
> > + * pages, in that case we will switch to idle.
> > + */
> > +static void page_hinting_cycle(struct zone *zone,
> > +			       struct page_hinting_dev_info *phdev)
> > +{
> > +	/*
> > +	 * Guarantee boundaries and stats are populated before we
> > +	 * start placing hinted pages in the zone.
> > +	 */
> > +	if (page_hinting_populate_metadata(zone))
> > +		return;
> > +
> > +	spin_lock(&zone->lock);
> > +
> > +	/* set bit indicating boundaries are present */
> > +	set_bit(ZONE_PAGE_HINTING_ACTIVE, &zone->flags);
> > +
> > +	do {
> > +		/* Pull pages out of allocator into a scaterlist */
> > +		unsigned int num_hints = page_hinting_fill(zone, phdev);
> > +
> > +		/* no pages were acquired, give up */
> > +		if (!num_hints)
> > +			break;
> > +
> > +		spin_unlock(&zone->lock);
> 
> Is there any recommendation in general about how/where we should lock and unlock
> zones in the code? For instance, over here you have a zone lock outside the loop
> and you are unlocking it inside the loop and then re-acquiring it.
> My guess is we should be fine as long as:
> 1. We are not holding the lock for a very long time.
> 2. We are making sure that if we have a zone lock we are releasing it before
> returning from the function.

So as a general rule the first two you mention work. Basically what you
want to do is work with some sort of bounded limit when you are holding
the lock so you know it will be released in a timely fashion.

The reason for dropping the lock inside of the loop s because we will end
up sleeping while we wait for the virtio-balloon device to process the
pages. So it makes sense to release the lock, process the pages, and then
reacquire the lock so that we can return the pages and grab another 16
pages.

Re: [PATCH v2 QEMU] virtio-balloon: Provide a interface for "bubble hinting"

[Alexander Duyck]

On Wed, Jul 24, 2019 at 1:42 PM Michael S. Tsirkin <mst@redhat.com> wrote:
>
> On Wed, Jul 24, 2019 at 04:29:27PM -0400, Nitesh Narayan Lal wrote:
> >
> > On 7/24/19 4:18 PM, Alexander Duyck wrote:
> > > On Wed, 2019-07-24 at 15:02 -0400, Michael S. Tsirkin wrote:
> > >> On Wed, Jul 24, 2019 at 10:12:10AM -0700, Alexander Duyck wrote:
> > >>> From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> > >>>
> > >>> Add support for what I am referring to as "bubble hinting". Basically the
> > >>> idea is to function very similar to how the balloon works in that we
> > >>> basically end up madvising the page as not being used. However we don't
> > >>> really need to bother with any deflate type logic since the page will be
> > >>> faulted back into the guest when it is read or written to.
> > >>>
> > >>> This is meant to be a simplification of the existing balloon interface
> > >>> to use for providing hints to what memory needs to be freed. I am assuming
> > >>> this is safe to do as the deflate logic does not actually appear to do very
> > >>> much other than tracking what subpages have been released and which ones
> > >>> haven't.
> > >>>
> > >>> Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> > >>> ---
> > >>>  hw/virtio/virtio-balloon.c                      |   40 +++++++++++++++++++++++
> > >>>  include/hw/virtio/virtio-balloon.h              |    2 +
> > >>>  include/standard-headers/linux/virtio_balloon.h |    1 +
> > >>>  3 files changed, 42 insertions(+), 1 deletion(-)
> > >>>
> > >>> diff --git a/hw/virtio/virtio-balloon.c b/hw/virtio/virtio-balloon.c
> > >>> index 2112874055fb..70c0004c0f88 100644
> > >>> --- a/hw/virtio/virtio-balloon.c
> > >>> +++ b/hw/virtio/virtio-balloon.c
> > >>> @@ -328,6 +328,39 @@ static void balloon_stats_set_poll_interval(Object *obj, Visitor *v,
> > >>>      balloon_stats_change_timer(s, 0);
> > >>>  }
> > >>>
> > >>> +static void virtio_bubble_handle_output(VirtIODevice *vdev, VirtQueue *vq)
> > >>> +{
> > >>> +    VirtQueueElement *elem;
> > >>> +
> > >>> +    while ((elem = virtqueue_pop(vq, sizeof(VirtQueueElement)))) {
> > >>> +         unsigned int i;
> > >>> +
> > >>> +        for (i = 0; i < elem->in_num; i++) {
> > >>> +            void *addr = elem->in_sg[i].iov_base;
> > >>> +            size_t size = elem->in_sg[i].iov_len;
> > >>> +            ram_addr_t ram_offset;
> > >>> +            size_t rb_page_size;
> > >>> +            RAMBlock *rb;
> > >>> +
> > >>> +            if (qemu_balloon_is_inhibited())
> > >>> +                continue;
> > >>> +
> > >>> +            rb = qemu_ram_block_from_host(addr, false, &ram_offset);
> > >>> +            rb_page_size = qemu_ram_pagesize(rb);
> > >>> +
> > >>> +            /* For now we will simply ignore unaligned memory regions */
> > >>> +            if ((ram_offset | size) & (rb_page_size - 1))
> > >>> +                continue;
> > >>> +
> > >>> +            ram_block_discard_range(rb, ram_offset, size);
> > >> I suspect this needs to do like the migration type of
> > >> hinting and get disabled if page poisoning is in effect.
> > >> Right?
> > > Shouldn't something like that end up getting handled via
> > > qemu_balloon_is_inhibited, or did I miss something there? I assumed cases
> > > like that would end up setting qemu_balloon_is_inhibited to true, if that
> > > isn't the case then I could add some additional conditions. I would do it
> > > in about the same spot as the qemu_balloon_is_inhibited check.
> > I don't think qemu_balloon_is_inhibited() will take care of the page poisoning
> > situations.
> > If I am not wrong we may have to look to extend VIRTIO_BALLOON_F_PAGE_POISON
> > support as per Michael's suggestion.
>
>
> BTW upstream qemu seems to ignore VIRTIO_BALLOON_F_PAGE_POISON ATM.
> Which is probably a bug.
> Wei, could you take a look pls?

So I was looking at sorting out this for the unused page reporting
that I am working on and it occurred to me that I don't think we can
do the free page hinting if any sort of poison validation is present.
The problem is that free page hinting simply stops the page from being
migrated. As a result if there was stale data present it will just
leave it there instead of zeroing it or writing it to alternating 1s
and 0s.

Also it looks like the VIRTIO_BALLOON_F_PAGE_POISON feature is
assuming that 0 means that page poisoning is disabled, when in reality
it might just mean we are using the value zero to poison pages instead
of the 0xaa pattern. As such I think there are several cases where we
could incorrectly flag the pages with the hint and result in the
migrated guest reporting pages that contain non-poison values.

The zero assumption works for unused page reporting since we will be
zeroing out the page when it is faulted back into the guest, however
the same doesn't work for the free page hint since it is simply
skipping the migration of the recently dirtied page.

Re: [PATCH v2 QEMU] virtio-balloon: Provide a interface for "bubble hinting"

[Michael S. Tsirkin]

On Mon, Jul 29, 2019 at 09:58:04AM -0700, Alexander Duyck wrote:
> On Wed, Jul 24, 2019 at 1:42 PM Michael S. Tsirkin <mst@redhat.com> wrote:
> >
> > On Wed, Jul 24, 2019 at 04:29:27PM -0400, Nitesh Narayan Lal wrote:
> > >
> > > On 7/24/19 4:18 PM, Alexander Duyck wrote:
> > > > On Wed, 2019-07-24 at 15:02 -0400, Michael S. Tsirkin wrote:
> > > >> On Wed, Jul 24, 2019 at 10:12:10AM -0700, Alexander Duyck wrote:
> > > >>> From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> > > >>>
> > > >>> Add support for what I am referring to as "bubble hinting". Basically the
> > > >>> idea is to function very similar to how the balloon works in that we
> > > >>> basically end up madvising the page as not being used. However we don't
> > > >>> really need to bother with any deflate type logic since the page will be
> > > >>> faulted back into the guest when it is read or written to.
> > > >>>
> > > >>> This is meant to be a simplification of the existing balloon interface
> > > >>> to use for providing hints to what memory needs to be freed. I am assuming
> > > >>> this is safe to do as the deflate logic does not actually appear to do very
> > > >>> much other than tracking what subpages have been released and which ones
> > > >>> haven't.
> > > >>>
> > > >>> Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> > > >>> ---
> > > >>>  hw/virtio/virtio-balloon.c                      |   40 +++++++++++++++++++++++
> > > >>>  include/hw/virtio/virtio-balloon.h              |    2 +
> > > >>>  include/standard-headers/linux/virtio_balloon.h |    1 +
> > > >>>  3 files changed, 42 insertions(+), 1 deletion(-)
> > > >>>
> > > >>> diff --git a/hw/virtio/virtio-balloon.c b/hw/virtio/virtio-balloon.c
> > > >>> index 2112874055fb..70c0004c0f88 100644
> > > >>> --- a/hw/virtio/virtio-balloon.c
> > > >>> +++ b/hw/virtio/virtio-balloon.c
> > > >>> @@ -328,6 +328,39 @@ static void balloon_stats_set_poll_interval(Object *obj, Visitor *v,
> > > >>>      balloon_stats_change_timer(s, 0);
> > > >>>  }
> > > >>>
> > > >>> +static void virtio_bubble_handle_output(VirtIODevice *vdev, VirtQueue *vq)
> > > >>> +{
> > > >>> +    VirtQueueElement *elem;
> > > >>> +
> > > >>> +    while ((elem = virtqueue_pop(vq, sizeof(VirtQueueElement)))) {
> > > >>> +         unsigned int i;
> > > >>> +
> > > >>> +        for (i = 0; i < elem->in_num; i++) {
> > > >>> +            void *addr = elem->in_sg[i].iov_base;
> > > >>> +            size_t size = elem->in_sg[i].iov_len;
> > > >>> +            ram_addr_t ram_offset;
> > > >>> +            size_t rb_page_size;
> > > >>> +            RAMBlock *rb;
> > > >>> +
> > > >>> +            if (qemu_balloon_is_inhibited())
> > > >>> +                continue;
> > > >>> +
> > > >>> +            rb = qemu_ram_block_from_host(addr, false, &ram_offset);
> > > >>> +            rb_page_size = qemu_ram_pagesize(rb);
> > > >>> +
> > > >>> +            /* For now we will simply ignore unaligned memory regions */
> > > >>> +            if ((ram_offset | size) & (rb_page_size - 1))
> > > >>> +                continue;
> > > >>> +
> > > >>> +            ram_block_discard_range(rb, ram_offset, size);
> > > >> I suspect this needs to do like the migration type of
> > > >> hinting and get disabled if page poisoning is in effect.
> > > >> Right?
> > > > Shouldn't something like that end up getting handled via
> > > > qemu_balloon_is_inhibited, or did I miss something there? I assumed cases
> > > > like that would end up setting qemu_balloon_is_inhibited to true, if that
> > > > isn't the case then I could add some additional conditions. I would do it
> > > > in about the same spot as the qemu_balloon_is_inhibited check.
> > > I don't think qemu_balloon_is_inhibited() will take care of the page poisoning
> > > situations.
> > > If I am not wrong we may have to look to extend VIRTIO_BALLOON_F_PAGE_POISON
> > > support as per Michael's suggestion.
> >
> >
> > BTW upstream qemu seems to ignore VIRTIO_BALLOON_F_PAGE_POISON ATM.
> > Which is probably a bug.
> > Wei, could you take a look pls?
> 
> So I was looking at sorting out this for the unused page reporting
> that I am working on and it occurred to me that I don't think we can
> do the free page hinting if any sort of poison validation is present.
> The problem is that free page hinting simply stops the page from being
> migrated. As a result if there was stale data present it will just
> leave it there instead of zeroing it or writing it to alternating 1s
> and 0s.

stale data where? on source or on destination?
do you mean the case where memory was corrupted?






> 
> Also it looks like the VIRTIO_BALLOON_F_PAGE_POISON feature is
> assuming that 0 means that page poisoning is disabled,
> when in reality
> it might just mean we are using the value zero to poison pages instead
> of the 0xaa pattern. As such I think there are several cases where we
> could incorrectly flag the pages with the hint and result in the
> migrated guest reporting pages that contain non-poison values.
> 


Well guest has this code:
static int virtballoon_validate(struct virtio_device *vdev)
{
        if (!page_poisoning_enabled())
                __virtio_clear_bit(vdev, VIRTIO_BALLOON_F_PAGE_POISON);

        __virtio_clear_bit(vdev, VIRTIO_F_IOMMU_PLATFORM);
        return 0;
}

So it seems that host can figure out what is going on easily enough.
What did I miss?



> The zero assumption works for unused page reporting since we will be
> zeroing out the page when it is faulted back into the guest, however
> the same doesn't work for the free page hint since it is simply
> skipping the migration of the recently dirtied page.

Right but the dirtied page is normally full of 0 since that is the
poison value, if we just leave it there we still get 0s, right?

-- 
MST

Re: [PATCH v2 QEMU] virtio-balloon: Provide a interface for "bubble hinting"

[Alexander Duyck]

On Mon, Jul 29, 2019 at 12:25 PM Michael S. Tsirkin <mst@redhat.com> wrote:
>
> On Mon, Jul 29, 2019 at 09:58:04AM -0700, Alexander Duyck wrote:
> > On Wed, Jul 24, 2019 at 1:42 PM Michael S. Tsirkin <mst@redhat.com> wrote:
> > >
> > > On Wed, Jul 24, 2019 at 04:29:27PM -0400, Nitesh Narayan Lal wrote:
> > > >
> > > > On 7/24/19 4:18 PM, Alexander Duyck wrote:
> > > > > On Wed, 2019-07-24 at 15:02 -0400, Michael S. Tsirkin wrote:
> > > > >> On Wed, Jul 24, 2019 at 10:12:10AM -0700, Alexander Duyck wrote:
> > > > >>> From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> > > > >>>
> > > > >>> Add support for what I am referring to as "bubble hinting". Basically the
> > > > >>> idea is to function very similar to how the balloon works in that we
> > > > >>> basically end up madvising the page as not being used. However we don't
> > > > >>> really need to bother with any deflate type logic since the page will be
> > > > >>> faulted back into the guest when it is read or written to.
> > > > >>>
> > > > >>> This is meant to be a simplification of the existing balloon interface
> > > > >>> to use for providing hints to what memory needs to be freed. I am assuming
> > > > >>> this is safe to do as the deflate logic does not actually appear to do very
> > > > >>> much other than tracking what subpages have been released and which ones
> > > > >>> haven't.
> > > > >>>
> > > > >>> Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> > > > >>> ---
> > > > >>>  hw/virtio/virtio-balloon.c                      |   40 +++++++++++++++++++++++
> > > > >>>  include/hw/virtio/virtio-balloon.h              |    2 +
> > > > >>>  include/standard-headers/linux/virtio_balloon.h |    1 +
> > > > >>>  3 files changed, 42 insertions(+), 1 deletion(-)
> > > > >>>
> > > > >>> diff --git a/hw/virtio/virtio-balloon.c b/hw/virtio/virtio-balloon.c
> > > > >>> index 2112874055fb..70c0004c0f88 100644
> > > > >>> --- a/hw/virtio/virtio-balloon.c
> > > > >>> +++ b/hw/virtio/virtio-balloon.c
> > > > >>> @@ -328,6 +328,39 @@ static void balloon_stats_set_poll_interval(Object *obj, Visitor *v,
> > > > >>>      balloon_stats_change_timer(s, 0);
> > > > >>>  }
> > > > >>>
> > > > >>> +static void virtio_bubble_handle_output(VirtIODevice *vdev, VirtQueue *vq)
> > > > >>> +{
> > > > >>> +    VirtQueueElement *elem;
> > > > >>> +
> > > > >>> +    while ((elem = virtqueue_pop(vq, sizeof(VirtQueueElement)))) {
> > > > >>> +         unsigned int i;
> > > > >>> +
> > > > >>> +        for (i = 0; i < elem->in_num; i++) {
> > > > >>> +            void *addr = elem->in_sg[i].iov_base;
> > > > >>> +            size_t size = elem->in_sg[i].iov_len;
> > > > >>> +            ram_addr_t ram_offset;
> > > > >>> +            size_t rb_page_size;
> > > > >>> +            RAMBlock *rb;
> > > > >>> +
> > > > >>> +            if (qemu_balloon_is_inhibited())
> > > > >>> +                continue;
> > > > >>> +
> > > > >>> +            rb = qemu_ram_block_from_host(addr, false, &ram_offset);
> > > > >>> +            rb_page_size = qemu_ram_pagesize(rb);
> > > > >>> +
> > > > >>> +            /* For now we will simply ignore unaligned memory regions */
> > > > >>> +            if ((ram_offset | size) & (rb_page_size - 1))
> > > > >>> +                continue;
> > > > >>> +
> > > > >>> +            ram_block_discard_range(rb, ram_offset, size);
> > > > >> I suspect this needs to do like the migration type of
> > > > >> hinting and get disabled if page poisoning is in effect.
> > > > >> Right?
> > > > > Shouldn't something like that end up getting handled via
> > > > > qemu_balloon_is_inhibited, or did I miss something there? I assumed cases
> > > > > like that would end up setting qemu_balloon_is_inhibited to true, if that
> > > > > isn't the case then I could add some additional conditions. I would do it
> > > > > in about the same spot as the qemu_balloon_is_inhibited check.
> > > > I don't think qemu_balloon_is_inhibited() will take care of the page poisoning
> > > > situations.
> > > > If I am not wrong we may have to look to extend VIRTIO_BALLOON_F_PAGE_POISON
> > > > support as per Michael's suggestion.
> > >
> > >
> > > BTW upstream qemu seems to ignore VIRTIO_BALLOON_F_PAGE_POISON ATM.
> > > Which is probably a bug.
> > > Wei, could you take a look pls?
> >
> > So I was looking at sorting out this for the unused page reporting
> > that I am working on and it occurred to me that I don't think we can
> > do the free page hinting if any sort of poison validation is present.
> > The problem is that free page hinting simply stops the page from being
> > migrated. As a result if there was stale data present it will just
> > leave it there instead of zeroing it or writing it to alternating 1s
> > and 0s.
>
> stale data where? on source or on destination?
> do you mean the case where memory was corrupted?
>

Actually I am getting my implementation and this one partially mixed
up again. I was thinking that the page just gets put back. However it
doesn't. Instead free_pages is called. As such it is going to dirty
the page by poisoning it as soon as the hinting is complete.

In some ways it is worse because I think page poisoning combined with
free page hinting will make the VM nearly unusable because it will be
burning cycles allocating all memory, and then poisoning all those
pages on free. So it will be populating the dirty bitmap with all free
memory each time it goes through and attempts to determine what memory
is free.

> >
> > Also it looks like the VIRTIO_BALLOON_F_PAGE_POISON feature is
> > assuming that 0 means that page poisoning is disabled,
> > when in reality
> > it might just mean we are using the value zero to poison pages instead
> > of the 0xaa pattern. As such I think there are several cases where we
> > could incorrectly flag the pages with the hint and result in the
> > migrated guest reporting pages that contain non-poison values.
> >
>
>
> Well guest has this code:
> static int virtballoon_validate(struct virtio_device *vdev)
> {
>         if (!page_poisoning_enabled())
>                 __virtio_clear_bit(vdev, VIRTIO_BALLOON_F_PAGE_POISON);
>
>         __virtio_clear_bit(vdev, VIRTIO_F_IOMMU_PLATFORM);
>         return 0;
> }
>
> So it seems that host can figure out what is going on easily enough.
> What did I miss?

Okay. So it is clearing that feature bit. I didn't see that part.
However that leads to the question of where we should be setting that
feature bit in the QEMU side of things. I was looking at setting that
bit in virtio_balloon_get_features(). Would that be the appropriate
place to set that so that the feature flag is reset when we are
changing OSes or rebooting the guest?

> > The zero assumption works for unused page reporting since we will be
> > zeroing out the page when it is faulted back into the guest, however
> > the same doesn't work for the free page hint since it is simply
> > skipping the migration of the recently dirtied page.
>
> Right but the dirtied page is normally full of 0 since that is the
> poison value, if we just leave it there we still get 0s, right?

So for the unused page reporting which I am working on we can still
hint the page away since it will be 0s, and us returning the pages
doesn't alter the page data. However for the free page hinting I don't
think we can.

With page poisoning and free page hinting I am thinking we should just
disable the free page hinting as I don't see how there can be any
advantage to it if page poisoning is enbled. Basically the thing that
makes the hinting "safe" will sabotage it since for every page we
don't migrate we will also be marking as dirty for the next iteration
through migration. As such we are just pushing the migration of any
free pages until the VM has stopped since the VM will just keep
dirtying the free pages until it stops hinting.

Re: [PATCH v2 QEMU] virtio-balloon: Provide a interface for "bubble hinting"

[Michael S. Tsirkin]

On Mon, Jul 29, 2019 at 01:21:32PM -0700, Alexander Duyck wrote:
> On Mon, Jul 29, 2019 at 12:25 PM Michael S. Tsirkin <mst@redhat.com> wrote:
> >
> > On Mon, Jul 29, 2019 at 09:58:04AM -0700, Alexander Duyck wrote:
> > > On Wed, Jul 24, 2019 at 1:42 PM Michael S. Tsirkin <mst@redhat.com> wrote:
> > > >
> > > > On Wed, Jul 24, 2019 at 04:29:27PM -0400, Nitesh Narayan Lal wrote:
> > > > >
> > > > > On 7/24/19 4:18 PM, Alexander Duyck wrote:
> > > > > > On Wed, 2019-07-24 at 15:02 -0400, Michael S. Tsirkin wrote:
> > > > > >> On Wed, Jul 24, 2019 at 10:12:10AM -0700, Alexander Duyck wrote:
> > > > > >>> From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> > > > > >>>
> > > > > >>> Add support for what I am referring to as "bubble hinting". Basically the
> > > > > >>> idea is to function very similar to how the balloon works in that we
> > > > > >>> basically end up madvising the page as not being used. However we don't
> > > > > >>> really need to bother with any deflate type logic since the page will be
> > > > > >>> faulted back into the guest when it is read or written to.
> > > > > >>>
> > > > > >>> This is meant to be a simplification of the existing balloon interface
> > > > > >>> to use for providing hints to what memory needs to be freed. I am assuming
> > > > > >>> this is safe to do as the deflate logic does not actually appear to do very
> > > > > >>> much other than tracking what subpages have been released and which ones
> > > > > >>> haven't.
> > > > > >>>
> > > > > >>> Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> > > > > >>> ---
> > > > > >>>  hw/virtio/virtio-balloon.c                      |   40 +++++++++++++++++++++++
> > > > > >>>  include/hw/virtio/virtio-balloon.h              |    2 +
> > > > > >>>  include/standard-headers/linux/virtio_balloon.h |    1 +
> > > > > >>>  3 files changed, 42 insertions(+), 1 deletion(-)
> > > > > >>>
> > > > > >>> diff --git a/hw/virtio/virtio-balloon.c b/hw/virtio/virtio-balloon.c
> > > > > >>> index 2112874055fb..70c0004c0f88 100644
> > > > > >>> --- a/hw/virtio/virtio-balloon.c
> > > > > >>> +++ b/hw/virtio/virtio-balloon.c
> > > > > >>> @@ -328,6 +328,39 @@ static void balloon_stats_set_poll_interval(Object *obj, Visitor *v,
> > > > > >>>      balloon_stats_change_timer(s, 0);
> > > > > >>>  }
> > > > > >>>
> > > > > >>> +static void virtio_bubble_handle_output(VirtIODevice *vdev, VirtQueue *vq)
> > > > > >>> +{
> > > > > >>> +    VirtQueueElement *elem;
> > > > > >>> +
> > > > > >>> +    while ((elem = virtqueue_pop(vq, sizeof(VirtQueueElement)))) {
> > > > > >>> +         unsigned int i;
> > > > > >>> +
> > > > > >>> +        for (i = 0; i < elem->in_num; i++) {
> > > > > >>> +            void *addr = elem->in_sg[i].iov_base;
> > > > > >>> +            size_t size = elem->in_sg[i].iov_len;
> > > > > >>> +            ram_addr_t ram_offset;
> > > > > >>> +            size_t rb_page_size;
> > > > > >>> +            RAMBlock *rb;
> > > > > >>> +
> > > > > >>> +            if (qemu_balloon_is_inhibited())
> > > > > >>> +                continue;
> > > > > >>> +
> > > > > >>> +            rb = qemu_ram_block_from_host(addr, false, &ram_offset);
> > > > > >>> +            rb_page_size = qemu_ram_pagesize(rb);
> > > > > >>> +
> > > > > >>> +            /* For now we will simply ignore unaligned memory regions */
> > > > > >>> +            if ((ram_offset | size) & (rb_page_size - 1))
> > > > > >>> +                continue;
> > > > > >>> +
> > > > > >>> +            ram_block_discard_range(rb, ram_offset, size);
> > > > > >> I suspect this needs to do like the migration type of
> > > > > >> hinting and get disabled if page poisoning is in effect.
> > > > > >> Right?
> > > > > > Shouldn't something like that end up getting handled via
> > > > > > qemu_balloon_is_inhibited, or did I miss something there? I assumed cases
> > > > > > like that would end up setting qemu_balloon_is_inhibited to true, if that
> > > > > > isn't the case then I could add some additional conditions. I would do it
> > > > > > in about the same spot as the qemu_balloon_is_inhibited check.
> > > > > I don't think qemu_balloon_is_inhibited() will take care of the page poisoning
> > > > > situations.
> > > > > If I am not wrong we may have to look to extend VIRTIO_BALLOON_F_PAGE_POISON
> > > > > support as per Michael's suggestion.
> > > >
> > > >
> > > > BTW upstream qemu seems to ignore VIRTIO_BALLOON_F_PAGE_POISON ATM.
> > > > Which is probably a bug.
> > > > Wei, could you take a look pls?
> > >
> > > So I was looking at sorting out this for the unused page reporting
> > > that I am working on and it occurred to me that I don't think we can
> > > do the free page hinting if any sort of poison validation is present.
> > > The problem is that free page hinting simply stops the page from being
> > > migrated. As a result if there was stale data present it will just
> > > leave it there instead of zeroing it or writing it to alternating 1s
> > > and 0s.
> >
> > stale data where? on source or on destination?
> > do you mean the case where memory was corrupted?
> >
> 
> Actually I am getting my implementation and this one partially mixed
> up again. I was thinking that the page just gets put back. However it
> doesn't. Instead free_pages is called. As such it is going to dirty
> the page by poisoning it as soon as the hinting is complete.
> 
> In some ways it is worse because I think page poisoning combined with
> free page hinting will make the VM nearly unusable because it will be
> burning cycles allocating all memory, and then poisoning all those
> pages on free. So it will be populating the dirty bitmap with all free
> memory each time it goes through and attempts to determine what memory
> is free.

Right, it does make it useless.

I really consider this a bug: page should be given to hypervisor after
it's poisoned. Then at least with 0 poison we could just mark it clean.
For non-zero poison, we could think about adding kvm APIs for
aggressively mapping all freed pages to a single non-zero one with COW.

I guess it's prudent to sacrifice another feature bit if/when
we fix it properly, saving a feature bit isn't worth
the risk that someone shipped a guest like this.

But it does show why just using alloc/free for hinting isn't
as great an idea as it seems on the surface.

> > >
> > > Also it looks like the VIRTIO_BALLOON_F_PAGE_POISON feature is
> > > assuming that 0 means that page poisoning is disabled,
> > > when in reality
> > > it might just mean we are using the value zero to poison pages instead
> > > of the 0xaa pattern. As such I think there are several cases where we
> > > could incorrectly flag the pages with the hint and result in the
> > > migrated guest reporting pages that contain non-poison values.
> > >
> >
> >
> > Well guest has this code:
> > static int virtballoon_validate(struct virtio_device *vdev)
> > {
> >         if (!page_poisoning_enabled())
> >                 __virtio_clear_bit(vdev, VIRTIO_BALLOON_F_PAGE_POISON);
> >
> >         __virtio_clear_bit(vdev, VIRTIO_F_IOMMU_PLATFORM);
> >         return 0;
> > }
> >
> > So it seems that host can figure out what is going on easily enough.
> > What did I miss?
> 
> Okay. So it is clearing that feature bit. I didn't see that part.
> However that leads to the question of where we should be setting that
> feature bit in the QEMU side of things. I was looking at setting that
> bit in virtio_balloon_get_features(). Would that be the appropriate
> place to set that so that the feature flag is reset when we are
> changing OSes or rebooting the guest?

We have
    DEFINE_PROP_BIT("free-page-hint", VirtIOBalloon, host_features,
                    VIRTIO_BALLOON_F_FREE_PAGE_HINT, false),
and poison should be there, too.


> > > The zero assumption works for unused page reporting since we will be
> > > zeroing out the page when it is faulted back into the guest, however
> > > the same doesn't work for the free page hint since it is simply
> > > skipping the migration of the recently dirtied page.
> >
> > Right but the dirtied page is normally full of 0 since that is the
> > poison value, if we just leave it there we still get 0s, right?
> 
> So for the unused page reporting which I am working on we can still
> hint the page away since it will be 0s, and us returning the pages
> doesn't alter the page data. However for the free page hinting I don't
> think we can.
> 
> With page poisoning and free page hinting I am thinking we should just
> disable the free page hinting as I don't see how there can be any
> advantage to it if page poisoning is enbled. Basically the thing that
> makes the hinting "safe" will sabotage it since for every page we
> don't migrate we will also be marking as dirty for the next iteration
> through migration. As such we are just pushing the migration of any
> free pages until the VM has stopped since the VM will just keep
> dirtying the free pages until it stops hinting.


Right this was discussed at the time for non-zero poison.

For hinting, my argument was simple: the reason it's useless is contained
within the hypervisor. So don't put the logic in the guest:
hypervisor can see poison is set and not request hints from guest.


For reporting, as you say it works with 0s and we can thinkably
make it work with non-0s down the road.
Until we do we can always have the hypervisor do something like

	if (poisoning && poison != 0)
		return;
	madvise(MADV_FREE);

-- 
MST

Re: [PATCH v2 QEMU] virtio-balloon: Provide a interface for "bubble hinting"

[Alexander Duyck]

On Mon, Jul 29, 2019 at 1:49 PM Michael S. Tsirkin <mst@redhat.com> wrote:
>
> On Mon, Jul 29, 2019 at 01:21:32PM -0700, Alexander Duyck wrote:
> > On Mon, Jul 29, 2019 at 12:25 PM Michael S. Tsirkin <mst@redhat.com> wrote:
> > >
> > > On Mon, Jul 29, 2019 at 09:58:04AM -0700, Alexander Duyck wrote:
> > > > On Wed, Jul 24, 2019 at 1:42 PM Michael S. Tsirkin <mst@redhat.com> wrote:
> > > > >
> > > > > On Wed, Jul 24, 2019 at 04:29:27PM -0400, Nitesh Narayan Lal wrote:
> > > > > >
> > > > > > On 7/24/19 4:18 PM, Alexander Duyck wrote:
> > > > > > > On Wed, 2019-07-24 at 15:02 -0400, Michael S. Tsirkin wrote:
> > > > > > >> On Wed, Jul 24, 2019 at 10:12:10AM -0700, Alexander Duyck wrote:
> > > > > > >>> From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> > > > > > >>>
> > > > > > >>> Add support for what I am referring to as "bubble hinting". Basically the
> > > > > > >>> idea is to function very similar to how the balloon works in that we
> > > > > > >>> basically end up madvising the page as not being used. However we don't
> > > > > > >>> really need to bother with any deflate type logic since the page will be
> > > > > > >>> faulted back into the guest when it is read or written to.
> > > > > > >>>
> > > > > > >>> This is meant to be a simplification of the existing balloon interface
> > > > > > >>> to use for providing hints to what memory needs to be freed. I am assuming
> > > > > > >>> this is safe to do as the deflate logic does not actually appear to do very
> > > > > > >>> much other than tracking what subpages have been released and which ones
> > > > > > >>> haven't.
> > > > > > >>>
> > > > > > >>> Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> > > > > > >>> ---
> > > > > > >>>  hw/virtio/virtio-balloon.c                      |   40 +++++++++++++++++++++++
> > > > > > >>>  include/hw/virtio/virtio-balloon.h              |    2 +
> > > > > > >>>  include/standard-headers/linux/virtio_balloon.h |    1 +
> > > > > > >>>  3 files changed, 42 insertions(+), 1 deletion(-)
> > > > > > >>>
> > > > > > >>> diff --git a/hw/virtio/virtio-balloon.c b/hw/virtio/virtio-balloon.c
> > > > > > >>> index 2112874055fb..70c0004c0f88 100644
> > > > > > >>> --- a/hw/virtio/virtio-balloon.c
> > > > > > >>> +++ b/hw/virtio/virtio-balloon.c
> > > > > > >>> @@ -328,6 +328,39 @@ static void balloon_stats_set_poll_interval(Object *obj, Visitor *v,
> > > > > > >>>      balloon_stats_change_timer(s, 0);
> > > > > > >>>  }
> > > > > > >>>
> > > > > > >>> +static void virtio_bubble_handle_output(VirtIODevice *vdev, VirtQueue *vq)
> > > > > > >>> +{
> > > > > > >>> +    VirtQueueElement *elem;
> > > > > > >>> +
> > > > > > >>> +    while ((elem = virtqueue_pop(vq, sizeof(VirtQueueElement)))) {
> > > > > > >>> +         unsigned int i;
> > > > > > >>> +
> > > > > > >>> +        for (i = 0; i < elem->in_num; i++) {
> > > > > > >>> +            void *addr = elem->in_sg[i].iov_base;
> > > > > > >>> +            size_t size = elem->in_sg[i].iov_len;
> > > > > > >>> +            ram_addr_t ram_offset;
> > > > > > >>> +            size_t rb_page_size;
> > > > > > >>> +            RAMBlock *rb;
> > > > > > >>> +
> > > > > > >>> +            if (qemu_balloon_is_inhibited())
> > > > > > >>> +                continue;
> > > > > > >>> +
> > > > > > >>> +            rb = qemu_ram_block_from_host(addr, false, &ram_offset);
> > > > > > >>> +            rb_page_size = qemu_ram_pagesize(rb);
> > > > > > >>> +
> > > > > > >>> +            /* For now we will simply ignore unaligned memory regions */
> > > > > > >>> +            if ((ram_offset | size) & (rb_page_size - 1))
> > > > > > >>> +                continue;
> > > > > > >>> +
> > > > > > >>> +            ram_block_discard_range(rb, ram_offset, size);
> > > > > > >> I suspect this needs to do like the migration type of
> > > > > > >> hinting and get disabled if page poisoning is in effect.
> > > > > > >> Right?
> > > > > > > Shouldn't something like that end up getting handled via
> > > > > > > qemu_balloon_is_inhibited, or did I miss something there? I assumed cases
> > > > > > > like that would end up setting qemu_balloon_is_inhibited to true, if that
> > > > > > > isn't the case then I could add some additional conditions. I would do it
> > > > > > > in about the same spot as the qemu_balloon_is_inhibited check.
> > > > > > I don't think qemu_balloon_is_inhibited() will take care of the page poisoning
> > > > > > situations.
> > > > > > If I am not wrong we may have to look to extend VIRTIO_BALLOON_F_PAGE_POISON
> > > > > > support as per Michael's suggestion.
> > > > >
> > > > >
> > > > > BTW upstream qemu seems to ignore VIRTIO_BALLOON_F_PAGE_POISON ATM.
> > > > > Which is probably a bug.
> > > > > Wei, could you take a look pls?
> > > >
> > > > So I was looking at sorting out this for the unused page reporting
> > > > that I am working on and it occurred to me that I don't think we can
> > > > do the free page hinting if any sort of poison validation is present.
> > > > The problem is that free page hinting simply stops the page from being
> > > > migrated. As a result if there was stale data present it will just
> > > > leave it there instead of zeroing it or writing it to alternating 1s
> > > > and 0s.
> > >
> > > stale data where? on source or on destination?
> > > do you mean the case where memory was corrupted?
> > >
> >
> > Actually I am getting my implementation and this one partially mixed
> > up again. I was thinking that the page just gets put back. However it
> > doesn't. Instead free_pages is called. As such it is going to dirty
> > the page by poisoning it as soon as the hinting is complete.
> >
> > In some ways it is worse because I think page poisoning combined with
> > free page hinting will make the VM nearly unusable because it will be
> > burning cycles allocating all memory, and then poisoning all those
> > pages on free. So it will be populating the dirty bitmap with all free
> > memory each time it goes through and attempts to determine what memory
> > is free.
>
> Right, it does make it useless.
>
> I really consider this a bug: page should be given to hypervisor after
> it's poisoned. Then at least with 0 poison we could just mark it clean.
> For non-zero poison, we could think about adding kvm APIs for
> aggressively mapping all freed pages to a single non-zero one with COW.
>
> I guess it's prudent to sacrifice another feature bit if/when
> we fix it properly, saving a feature bit isn't worth
> the risk that someone shipped a guest like this.
>
> But it does show why just using alloc/free for hinting isn't
> as great an idea as it seems on the surface.

What I think I can do for now is address this partially in QEMU. What
I will do is just return without starting the free page hinting in
virtio_balloon_free_page_start() if VIRTIO_BALLOON_F_PAGE_POISON is
set.

> > > >
> > > > Also it looks like the VIRTIO_BALLOON_F_PAGE_POISON feature is
> > > > assuming that 0 means that page poisoning is disabled,
> > > > when in reality
> > > > it might just mean we are using the value zero to poison pages instead
> > > > of the 0xaa pattern. As such I think there are several cases where we
> > > > could incorrectly flag the pages with the hint and result in the
> > > > migrated guest reporting pages that contain non-poison values.
> > > >
> > >
> > >
> > > Well guest has this code:
> > > static int virtballoon_validate(struct virtio_device *vdev)
> > > {
> > >         if (!page_poisoning_enabled())
> > >                 __virtio_clear_bit(vdev, VIRTIO_BALLOON_F_PAGE_POISON);
> > >
> > >         __virtio_clear_bit(vdev, VIRTIO_F_IOMMU_PLATFORM);
> > >         return 0;
> > > }
> > >
> > > So it seems that host can figure out what is going on easily enough.
> > > What did I miss?
> >
> > Okay. So it is clearing that feature bit. I didn't see that part.
> > However that leads to the question of where we should be setting that
> > feature bit in the QEMU side of things. I was looking at setting that
> > bit in virtio_balloon_get_features(). Would that be the appropriate
> > place to set that so that the feature flag is reset when we are
> > changing OSes or rebooting the guest?
>
> We have
>     DEFINE_PROP_BIT("free-page-hint", VirtIOBalloon, host_features,
>                     VIRTIO_BALLOON_F_FREE_PAGE_HINT, false),
> and poison should be there, too.

I don't think we want it to be user configurable though, do we? It
seems like it should be set if either free-page-hint or
unused-page-reporting are enabled. Then the guest can disable it on
its end if poisoning is not present.

> > > > The zero assumption works for unused page reporting since we will be
> > > > zeroing out the page when it is faulted back into the guest, however
> > > > the same doesn't work for the free page hint since it is simply
> > > > skipping the migration of the recently dirtied page.
> > >
> > > Right but the dirtied page is normally full of 0 since that is the
> > > poison value, if we just leave it there we still get 0s, right?
> >
> > So for the unused page reporting which I am working on we can still
> > hint the page away since it will be 0s, and us returning the pages
> > doesn't alter the page data. However for the free page hinting I don't
> > think we can.
> >
> > With page poisoning and free page hinting I am thinking we should just
> > disable the free page hinting as I don't see how there can be any
> > advantage to it if page poisoning is enbled. Basically the thing that
> > makes the hinting "safe" will sabotage it since for every page we
> > don't migrate we will also be marking as dirty for the next iteration
> > through migration. As such we are just pushing the migration of any
> > free pages until the VM has stopped since the VM will just keep
> > dirtying the free pages until it stops hinting.
>
>
> Right this was discussed at the time for non-zero poison.
>
> For hinting, my argument was simple: the reason it's useless is contained
> within the hypervisor. So don't put the logic in the guest:
> hypervisor can see poison is set and not request hints from guest.

Agreed. What I am going to do is store off the config value to a value
local to the vdev when the config is written from the guest and the
VIRTIO_BALLOON_F_PAGE_POISON value is set.

Like I mentioned above I will just disable the free page hinting
functionality by just not having the hypervisor request hinting if
page poisoning is set. I will just drop the reports from the guest
when the poison value is non-zero.

> For reporting, as you say it works with 0s and we can thinkably
> make it work with non-0s down the road.
> Until we do we can always have the hypervisor do something like
>
>         if (poisoning && poison != 0)
>                 return;
>         madvise(MADV_FREE);

Agreed.

Re: [PATCH v2 QEMU] virtio-balloon: Provide a interface for "bubble hinting"

[Michael S. Tsirkin]

On Mon, Jul 29, 2019 at 02:37:26PM -0700, Alexander Duyck wrote:
> On Mon, Jul 29, 2019 at 1:49 PM Michael S. Tsirkin <mst@redhat.com> wrote:
> >
> > On Mon, Jul 29, 2019 at 01:21:32PM -0700, Alexander Duyck wrote:
> > > On Mon, Jul 29, 2019 at 12:25 PM Michael S. Tsirkin <mst@redhat.com> wrote:
> > > >
> > > > On Mon, Jul 29, 2019 at 09:58:04AM -0700, Alexander Duyck wrote:
> > > > > On Wed, Jul 24, 2019 at 1:42 PM Michael S. Tsirkin <mst@redhat.com> wrote:
> > > > > >
> > > > > > On Wed, Jul 24, 2019 at 04:29:27PM -0400, Nitesh Narayan Lal wrote:
> > > > > > >
> > > > > > > On 7/24/19 4:18 PM, Alexander Duyck wrote:
> > > > > > > > On Wed, 2019-07-24 at 15:02 -0400, Michael S. Tsirkin wrote:
> > > > > > > >> On Wed, Jul 24, 2019 at 10:12:10AM -0700, Alexander Duyck wrote:
> > > > > > > >>> From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> > > > > > > >>>
> > > > > > > >>> Add support for what I am referring to as "bubble hinting". Basically the
> > > > > > > >>> idea is to function very similar to how the balloon works in that we
> > > > > > > >>> basically end up madvising the page as not being used. However we don't
> > > > > > > >>> really need to bother with any deflate type logic since the page will be
> > > > > > > >>> faulted back into the guest when it is read or written to.
> > > > > > > >>>
> > > > > > > >>> This is meant to be a simplification of the existing balloon interface
> > > > > > > >>> to use for providing hints to what memory needs to be freed. I am assuming
> > > > > > > >>> this is safe to do as the deflate logic does not actually appear to do very
> > > > > > > >>> much other than tracking what subpages have been released and which ones
> > > > > > > >>> haven't.
> > > > > > > >>>
> > > > > > > >>> Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> > > > > > > >>> ---
> > > > > > > >>>  hw/virtio/virtio-balloon.c                      |   40 +++++++++++++++++++++++
> > > > > > > >>>  include/hw/virtio/virtio-balloon.h              |    2 +
> > > > > > > >>>  include/standard-headers/linux/virtio_balloon.h |    1 +
> > > > > > > >>>  3 files changed, 42 insertions(+), 1 deletion(-)
> > > > > > > >>>
> > > > > > > >>> diff --git a/hw/virtio/virtio-balloon.c b/hw/virtio/virtio-balloon.c
> > > > > > > >>> index 2112874055fb..70c0004c0f88 100644
> > > > > > > >>> --- a/hw/virtio/virtio-balloon.c
> > > > > > > >>> +++ b/hw/virtio/virtio-balloon.c
> > > > > > > >>> @@ -328,6 +328,39 @@ static void balloon_stats_set_poll_interval(Object *obj, Visitor *v,
> > > > > > > >>>      balloon_stats_change_timer(s, 0);
> > > > > > > >>>  }
> > > > > > > >>>
> > > > > > > >>> +static void virtio_bubble_handle_output(VirtIODevice *vdev, VirtQueue *vq)
> > > > > > > >>> +{
> > > > > > > >>> +    VirtQueueElement *elem;
> > > > > > > >>> +
> > > > > > > >>> +    while ((elem = virtqueue_pop(vq, sizeof(VirtQueueElement)))) {
> > > > > > > >>> +         unsigned int i;
> > > > > > > >>> +
> > > > > > > >>> +        for (i = 0; i < elem->in_num; i++) {
> > > > > > > >>> +            void *addr = elem->in_sg[i].iov_base;
> > > > > > > >>> +            size_t size = elem->in_sg[i].iov_len;
> > > > > > > >>> +            ram_addr_t ram_offset;
> > > > > > > >>> +            size_t rb_page_size;
> > > > > > > >>> +            RAMBlock *rb;
> > > > > > > >>> +
> > > > > > > >>> +            if (qemu_balloon_is_inhibited())
> > > > > > > >>> +                continue;
> > > > > > > >>> +
> > > > > > > >>> +            rb = qemu_ram_block_from_host(addr, false, &ram_offset);
> > > > > > > >>> +            rb_page_size = qemu_ram_pagesize(rb);
> > > > > > > >>> +
> > > > > > > >>> +            /* For now we will simply ignore unaligned memory regions */
> > > > > > > >>> +            if ((ram_offset | size) & (rb_page_size - 1))
> > > > > > > >>> +                continue;
> > > > > > > >>> +
> > > > > > > >>> +            ram_block_discard_range(rb, ram_offset, size);
> > > > > > > >> I suspect this needs to do like the migration type of
> > > > > > > >> hinting and get disabled if page poisoning is in effect.
> > > > > > > >> Right?
> > > > > > > > Shouldn't something like that end up getting handled via
> > > > > > > > qemu_balloon_is_inhibited, or did I miss something there? I assumed cases
> > > > > > > > like that would end up setting qemu_balloon_is_inhibited to true, if that
> > > > > > > > isn't the case then I could add some additional conditions. I would do it
> > > > > > > > in about the same spot as the qemu_balloon_is_inhibited check.
> > > > > > > I don't think qemu_balloon_is_inhibited() will take care of the page poisoning
> > > > > > > situations.
> > > > > > > If I am not wrong we may have to look to extend VIRTIO_BALLOON_F_PAGE_POISON
> > > > > > > support as per Michael's suggestion.
> > > > > >
> > > > > >
> > > > > > BTW upstream qemu seems to ignore VIRTIO_BALLOON_F_PAGE_POISON ATM.
> > > > > > Which is probably a bug.
> > > > > > Wei, could you take a look pls?
> > > > >
> > > > > So I was looking at sorting out this for the unused page reporting
> > > > > that I am working on and it occurred to me that I don't think we can
> > > > > do the free page hinting if any sort of poison validation is present.
> > > > > The problem is that free page hinting simply stops the page from being
> > > > > migrated. As a result if there was stale data present it will just
> > > > > leave it there instead of zeroing it or writing it to alternating 1s
> > > > > and 0s.
> > > >
> > > > stale data where? on source or on destination?
> > > > do you mean the case where memory was corrupted?
> > > >
> > >
> > > Actually I am getting my implementation and this one partially mixed
> > > up again. I was thinking that the page just gets put back. However it
> > > doesn't. Instead free_pages is called. As such it is going to dirty
> > > the page by poisoning it as soon as the hinting is complete.
> > >
> > > In some ways it is worse because I think page poisoning combined with
> > > free page hinting will make the VM nearly unusable because it will be
> > > burning cycles allocating all memory, and then poisoning all those
> > > pages on free. So it will be populating the dirty bitmap with all free
> > > memory each time it goes through and attempts to determine what memory
> > > is free.
> >
> > Right, it does make it useless.
> >
> > I really consider this a bug: page should be given to hypervisor after
> > it's poisoned. Then at least with 0 poison we could just mark it clean.
> > For non-zero poison, we could think about adding kvm APIs for
> > aggressively mapping all freed pages to a single non-zero one with COW.
> >
> > I guess it's prudent to sacrifice another feature bit if/when
> > we fix it properly, saving a feature bit isn't worth
> > the risk that someone shipped a guest like this.
> >
> > But it does show why just using alloc/free for hinting isn't
> > as great an idea as it seems on the surface.
> 
> What I think I can do for now is address this partially in QEMU. What
> I will do is just return without starting the free page hinting in
> virtio_balloon_free_page_start() if VIRTIO_BALLOON_F_PAGE_POISON is
> set.
> 
> > > > >
> > > > > Also it looks like the VIRTIO_BALLOON_F_PAGE_POISON feature is
> > > > > assuming that 0 means that page poisoning is disabled,
> > > > > when in reality
> > > > > it might just mean we are using the value zero to poison pages instead
> > > > > of the 0xaa pattern. As such I think there are several cases where we
> > > > > could incorrectly flag the pages with the hint and result in the
> > > > > migrated guest reporting pages that contain non-poison values.
> > > > >
> > > >
> > > >
> > > > Well guest has this code:
> > > > static int virtballoon_validate(struct virtio_device *vdev)
> > > > {
> > > >         if (!page_poisoning_enabled())
> > > >                 __virtio_clear_bit(vdev, VIRTIO_BALLOON_F_PAGE_POISON);
> > > >
> > > >         __virtio_clear_bit(vdev, VIRTIO_F_IOMMU_PLATFORM);
> > > >         return 0;
> > > > }
> > > >
> > > > So it seems that host can figure out what is going on easily enough.
> > > > What did I miss?
> > >
> > > Okay. So it is clearing that feature bit. I didn't see that part.
> > > However that leads to the question of where we should be setting that
> > > feature bit in the QEMU side of things. I was looking at setting that
> > > bit in virtio_balloon_get_features(). Would that be the appropriate
> > > place to set that so that the feature flag is reset when we are
> > > changing OSes or rebooting the guest?
> >
> > We have
> >     DEFINE_PROP_BIT("free-page-hint", VirtIOBalloon, host_features,
> >                     VIRTIO_BALLOON_F_FREE_PAGE_HINT, false),
> > and poison should be there, too.
> 
> I don't think we want it to be user configurable though, do we? It
> seems like it should be set if either free-page-hint or
> unused-page-reporting are enabled. Then the guest can disable it on
> its end if poisoning is not present.


Oh right. So it can be in virtio_balloon_get_features then, sorry.  We
still do need to make it conditional on a property (internal one,
starting with "x-") for machine compat reasons.



> > > > > The zero assumption works for unused page reporting since we will be
> > > > > zeroing out the page when it is faulted back into the guest, however
> > > > > the same doesn't work for the free page hint since it is simply
> > > > > skipping the migration of the recently dirtied page.
> > > >
> > > > Right but the dirtied page is normally full of 0 since that is the
> > > > poison value, if we just leave it there we still get 0s, right?
> > >
> > > So for the unused page reporting which I am working on we can still
> > > hint the page away since it will be 0s, and us returning the pages
> > > doesn't alter the page data. However for the free page hinting I don't
> > > think we can.
> > >
> > > With page poisoning and free page hinting I am thinking we should just
> > > disable the free page hinting as I don't see how there can be any
> > > advantage to it if page poisoning is enbled. Basically the thing that
> > > makes the hinting "safe" will sabotage it since for every page we
> > > don't migrate we will also be marking as dirty for the next iteration
> > > through migration. As such we are just pushing the migration of any
> > > free pages until the VM has stopped since the VM will just keep
> > > dirtying the free pages until it stops hinting.
> >
> >
> > Right this was discussed at the time for non-zero poison.
> >
> > For hinting, my argument was simple: the reason it's useless is contained
> > within the hypervisor. So don't put the logic in the guest:
> > hypervisor can see poison is set and not request hints from guest.
> 
> Agreed. What I am going to do is store off the config value to a value
> local to the vdev when the config is written from the guest and the
> VIRTIO_BALLOON_F_PAGE_POISON value is set.
> 
> Like I mentioned above I will just disable the free page hinting
> functionality by just not having the hypervisor request hinting if
> page poisoning is set. I will just drop the reports from the guest
> when the poison value is non-zero.

Makes sense. In fact this part is a bugfix, and if you
can post it quickly I'll try to fast track it into 4.1
(might be too late for that, we'll see).

> > For reporting, as you say it works with 0s and we can thinkably
> > make it work with non-0s down the road.
> > Until we do we can always have the hypervisor do something like
> >
> >         if (poisoning && poison != 0)
> >                 return;
> >         madvise(MADV_FREE);
> 
> Agreed.