Skip to contentSkip to conversation

mm / virtio: Provide support for page hinting

PATCH Superseded Alexander Duyck 5 participants 68 messages Jul 24, 2019 – Jul 29, 2019

Subsystems (8)

v2 of 17 Superseded Latest is v17 →

lore
Share & tools
lore
#0 lore raw

v2 cover mm / virtio: Provide support for page hinting

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/[email protected]/
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/[email protected]/
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

--

#1 lore raw

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

From: Alexander Duyck <[email protected]>

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.

---
 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(-)
include/linux/mmzone.h +0 -12
index d77d717c620c..738e9c758135 100644
@@ -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)
mm/page_alloc.c +39 -31

91 lines not on this page · raw message

mm/shuffle.c +0 -24
index 3ce12481b1dc..55d592e62526 100644
@@ -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;
-}
mm/shuffle.h +32 -0
index 777a257a0d2f..add763cc0995 100644
@@ -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 */
#2 lore raw

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

In reply to Alexander Duyck

From: Alexander Duyck <[email protected]>

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.

---
 mm/internal.h   |   18 ++++++++++++++++++
 mm/page_alloc.c |   18 ------------------
 2 files changed, 18 insertions(+), 18 deletions(-)
mm/internal.h +18 -0
index e32390802fd3..e432c7d5940d 100644
@@ -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 */
mm/page_alloc.c +0 -18
index 1c4644b6cdc3..3d612a6b1771 100644
@@ -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
#3 lore raw

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

In reply to Alexander Duyck

From: Alexander Duyck <[email protected]>

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.

---
 include/linux/mmzone.h |   70 ++++++++++++++++++++++++++----------------------
 mm/page_alloc.c        |   30 ++++++++-------------
 2 files changed, 49 insertions(+), 51 deletions(-)
include/linux/mmzone.h +38 -32
index 738e9c758135..f0c68b6b6154 100644
@@ -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);
mm/page_alloc.c +11 -19
index 3d612a6b1771..9a73f69b37af 100644
@@ -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);
#4 lore raw

PATCH v2 4/5 mm: Introduce Hinted pages

In reply to Alexander Duyck

From: Alexander Duyck <[email protected]>

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.

---
 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
include/linux/mmzone.h +37 -3
index f0c68b6b6154..42bdebb20484 100644
@@ -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);
include/linux/page-flags.h +8 -0
index b848517da64c..b753dbf673cb 100644
@@ -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.
  */
include/linux/page_hinting.h new file +139 -0

139 lines not on this page · raw message

mm/Kconfig +5 -0
index 56cec636a1fc..38354668f849 100644
@@ -237,6 +237,11 @@ config COMPACTION
           [email protected].
 
 #
+# support for free page hinting
+config PAGE_HINTING
+	bool
+
+#
 # support for page migration
 #
 config MIGRATION
mm/Makefile +1 -0
index 338e528ad436..7277ced923ab 100644
@@ -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
mm/memory_hotplug.c +1 -0
index 2a9bbddb0e55..7c2d49b1a918 100644
@@ -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);
 
mm/page_alloc.c +131 -5

175 lines not on this page · raw message

mm/page_hinting.c new file +298 -0

298 lines not on this page · raw message

#5 lore raw

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

Quoted 144 lines · Alexander Duyck

From: Alexander Duyck <[email protected]>

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.

---
 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
include/linux/mmzone.h +37 -3
index f0c68b6b6154..42bdebb20484 100644
@@ -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);
include/linux/page-flags.h +0 -0
index b848517da64c..b753dbf673cb 100644

include/linux/page-flags.h static inline int page_has_type(struct page *page) · line 753

Quoted 9 lines
include/linux/page-flags.h +6 -0
@@ -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?

Signature · 3 lines
Thanks,

David / dhildenb
#6 lore raw

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

Quoted 170 lines · David Hildenbrand
Quoted 144 lines · Alexander Duyck

From: Alexander Duyck <[email protected]>

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.

---
 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
include/linux/mmzone.h +37 -3
index f0c68b6b6154..42bdebb20484 100644
@@ -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);
include/linux/page-flags.h +0 -0
index b848517da64c..b753dbf673cb 100644

include/linux/page-flags.h static inline int page_has_type(struct page *page) · line 753

Quoted 9 lines
include/linux/page-flags.h +6 -0
@@ -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.

Quoted 3 lines

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?

Quoted 2 lines

Matthew, what's your take?

Signature · 2 lines
Thanks
Nitesh
#7 lore raw

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

Quoted 172 lines · Nitesh Narayan Lal
Quoted 170 lines · David Hildenbrand
Quoted 144 lines · Alexander Duyck

From: Alexander Duyck <[email protected]>

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.

---
 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
include/linux/mmzone.h +37 -3
index f0c68b6b6154..42bdebb20484 100644
@@ -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);
include/linux/page-flags.h +0 -0
index b848517da64c..b753dbf673cb 100644

include/linux/page-flags.h static inline int page_has_type(struct page *page) · line 753

Quoted 9 lines
include/linux/page-flags.h +6 -0
@@ -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.

Quoted 5 lines
Quoted 3 lines

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.

Signature · 3 lines
Thanks,

David / dhildenb
#8 lore raw

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

In reply to David Hildenbrand
Quoted 3 lines · David Hildenbrand
Quoted 1 line · Alexander Duyck

From: Alexander Duyck <[email protected]>

<snip>

Quoted 9 lines
Quoted 7 lines

/*
+ * 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)

Quoted 8 lines

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.

Quoted 4 lines

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.

Quoted 3 lines

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.

#9 lore raw

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

Quoted 25 lines · Alexander Duyck
Quoted 3 lines · David Hildenbrand
Quoted 1 line · Alexander Duyck

From: Alexander Duyck <[email protected]>

<snip>

Quoted 9 lines
Quoted 7 lines

/*
+ * 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)

Quoted 8 lines

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.

Quoted 4 lines

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.

Quoted 10 lines
Quoted 5 lines

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

Quoted 3 lines

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.

Quoted 8 lines
Quoted 4 lines

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.

Quoted 7 lines

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.

Signature · 3 lines
Thanks,

David / dhildenb
#10 lore raw

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

Quoted 5 lines · David Hildenbrand
Quoted 4 lines · Alexander Duyck
Quoted 2 lines · David Hildenbrand
Quoted 1 line · Alexander Duyck

From: Alexander Duyck <[email protected]>

<snip>

Quoted 11 lines
Quoted 7 lines
Quoted 3 lines

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.

Quoted 7 lines

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.

Quoted 8 lines
Quoted 6 lines

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.

#11 lore raw

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

Quoted 17 lines · Alexander Duyck
Quoted 5 lines · David Hildenbrand
Quoted 4 lines · Alexander Duyck
Quoted 2 lines · David Hildenbrand
Quoted 1 line · Alexander Duyck

From: Alexander Duyck <[email protected]>

<snip>

Quoted 8 lines
Quoted 7 lines
Quoted 3 lines

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.

Quoted 8 lines
Quoted 3 lines

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.

Quoted 11 lines
Quoted 8 lines

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.

Quoted 12 lines

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.

Quoted 7 lines
Quoted 6 lines

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.

Quoted 6 lines
Quoted 1 line

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

Signature · 3 lines
Thanks,

David / dhildenb
#12 lore raw

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

Quoted 36 lines · David Hildenbrand
Quoted 16 lines · Alexander Duyck
Quoted 4 lines · David Hildenbrand
Quoted 3 lines · Alexander Duyck
Quoted 2 lines · David Hildenbrand
Quoted 1 line · Alexander Duyck

From: Alexander Duyck <[email protected]>

<snip>

Quoted 8 lines
Quoted 7 lines
Quoted 3 lines

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.

Quoted 8 lines
Quoted 3 lines

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.

Quoted 8 lines
Quoted 7 lines

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.

Quoted 6 lines
Quoted 2 lines

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.

Quoted 13 lines
Quoted 13 lines

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.

Quoted 8 lines
Quoted 6 lines

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.

Quoted 8 lines
Quoted 4 lines

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.

#13 lore raw

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

Quoted 71 lines · Alexander Duyck
Quoted 36 lines · David Hildenbrand
Quoted 16 lines · Alexander Duyck
Quoted 4 lines · David Hildenbrand
Quoted 3 lines · Alexander Duyck
Quoted 2 lines · David Hildenbrand
Quoted 1 line · Alexander Duyck

From: Alexander Duyck <[email protected]>

<snip>

Quoted 8 lines
Quoted 7 lines
Quoted 3 lines

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.

Quoted 8 lines
Quoted 3 lines

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.

Quoted 8 lines
Quoted 7 lines

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.

Quoted 6 lines
Quoted 2 lines

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.

Quoted 13 lines
Quoted 13 lines

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.

Quoted 8 lines
Quoted 6 lines

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.

Quoted 8 lines
Quoted 4 lines

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

Quoted 5 lines

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.

Signature · 3 lines
Thanks,

David / dhildenb
#14 lore raw

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

In reply to Alexander Duyck
Quoted 677 lines · Alexander Duyck

From: Alexander Duyck <[email protected]>

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.

---
 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
include/linux/mmzone.h +37 -3
index f0c68b6b6154..42bdebb20484 100644
@@ -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);
include/linux/page-flags.h +8 -0
index b848517da64c..b753dbf673cb 100644
@@ -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.
  */
include/linux/page_hinting.h new file +139 -0
new file mode 100644
index 000000000000..526fb26663d9
@@ -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 */
mm/Kconfig +5 -0
index 56cec636a1fc..38354668f849 100644
@@ -237,6 +237,11 @@ config COMPACTION
           [email protected].
 
 #
+# support for free page hinting
+config PAGE_HINTING
+	bool
+
+#
 # support for page migration
 #
 config MIGRATION
mm/Makefile +1 -0
index 338e528ad436..7277ced923ab 100644
@@ -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
mm/memory_hotplug.c +1 -0
index 2a9bbddb0e55..7c2d49b1a918 100644
@@ -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);
 
mm/page_alloc.c +131 -5
index 9a73f69b37af..c83cb4a30aff 100644
@@ -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
mm/page_hinting.c new file +146 -0
new file mode 100644
index 000000000000..d06d3762b315
@@ -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);

mm/page_hinting.c line 156

Quoted 10 lines
mm/page_hinting.c new file +10 -0
+
+	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.

Quoted 143 lines
mm/page_hinting.c new file +142 -0
+
+		/* 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);
+
Signature · 2 lines
Thanks
Nitesh
#15 lore raw

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

Quoted 4 lines · Nitesh Narayan Lal
Quoted 3 lines · Alexander Duyck

From: Alexander Duyck <[email protected]>

<snip>

Quoted 30 lines
Quoted 19 lines
mm/page_hinting.c new file +19 -0
+/*
+ * 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);

mm/page_hinting.c line 156

Quoted 10 lines
mm/page_hinting.c new file +10 -0
+
+	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);
Quoted 7 lines

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.

#16 lore raw

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

In reply to Alexander Duyck

From: Alexander Duyck <[email protected]>

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.

---
 drivers/virtio/Kconfig              |    1 +
 drivers/virtio/virtio_balloon.c     |   47 +++++++++++++++++++++++++++++++++++
 include/uapi/linux/virtio_balloon.h |    1 +
 3 files changed, 49 insertions(+)
drivers/virtio/Kconfig +1 -0
index 078615cf2afc..d45556ae1f81 100644
@@ -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.
drivers/virtio/virtio_balloon.c +47 -0

118 lines not on this page · raw message

include/uapi/linux/virtio_balloon.h +1 -0
index a1966cd7b677..2b0f62814e22 100644
@@ -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
#17 lore raw

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

Quoted 11 lines · Alexander Duyck

From: Alexander Duyck <[email protected]>

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.

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 ...

Quoted 60 lines
---
 drivers/virtio/Kconfig              |    1 +
 drivers/virtio/virtio_balloon.c     |   47 +++++++++++++++++++++++++++++++++++
 include/uapi/linux/virtio_balloon.h |    1 +
 3 files changed, 49 insertions(+)
drivers/virtio/Kconfig +1 -0
index 078615cf2afc..d45556ae1f81 100644
@@ -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.
drivers/virtio/virtio_balloon.c +7 -0
index 226fbb995fb0..dee9f8f3ad09 100644
@@ -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)
 
 }

drivers/virtio/virtio_balloon.c static void tell_host(struct virtio_balloon *vb, struct virtqueue *vq) · line 170

Quoted 10 lines
drivers/virtio/virtio_balloon.c +9 -0
 
+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 ...

drivers/virtio/virtio_balloon.c static void tell_host(struct virtio_balloon *vb, struct virtqueue *vq) · line 172

Quoted 2 lines
drivers/virtio/virtio_balloon.c +2 -0
+	virtqueue_add_inbuf(vq, ph_dev_info->sg, num_hints, vb, GFP_KERNEL);
+	virtqueue_kick(vq);

... this will block forever.

drivers/virtio/virtio_balloon.c static void tell_host(struct virtio_balloon *vb, struct virtqueue *vq) · line 175

Quoted 2 lines
drivers/virtio/virtio_balloon.c +2 -0
+	/* 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.

Quoted 34 lines
drivers/virtio/virtio_balloon.c +11 -0
+}
+
 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)) {

drivers/virtio/virtio_balloon.c static int virtballoon_probe(struct virtio_device *vdev) · line 961

Quoted 6 lines
drivers/virtio/virtio_balloon.c +3 -0
@@ -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 ...

Quoted 47 lines
drivers/virtio/virtio_balloon.c +12 -0
+	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 = {
include/uapi/linux/virtio_balloon.h +1 -0
index a1966cd7b677..2b0f62814e22 100644
@@ -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
#18 lore raw

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

Quoted 11 lines · Michael S. Tsirkin
Quoted 10 lines · Alexander Duyck

From: Alexander Duyck <[email protected]>

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.

Quoted 7 lines
Quoted 1 line

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?

Quoted 183 lines

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

Not a blocker for sure ...

Quoted 60 lines
---
 drivers/virtio/Kconfig              |    1 +
 drivers/virtio/virtio_balloon.c     |   47 +++++++++++++++++++++++++++++++++++
 include/uapi/linux/virtio_balloon.h |    1 +
 3 files changed, 49 insertions(+)
drivers/virtio/Kconfig +1 -0
index 078615cf2afc..d45556ae1f81 100644
@@ -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.
drivers/virtio/virtio_balloon.c +7 -0
index 226fbb995fb0..dee9f8f3ad09 100644
@@ -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)
 
 }

drivers/virtio/virtio_balloon.c static void tell_host(struct virtio_balloon *vb, struct virtqueue *vq) · line 170

Quoted 10 lines
drivers/virtio/virtio_balloon.c +9 -0
 
+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 ...

drivers/virtio/virtio_balloon.c static void tell_host(struct virtio_balloon *vb, struct virtqueue *vq) · line 172

Quoted 2 lines
drivers/virtio/virtio_balloon.c +2 -0
+	virtqueue_add_inbuf(vq, ph_dev_info->sg, num_hints, vb, GFP_KERNEL);
+	virtqueue_kick(vq);

... this will block forever.

drivers/virtio/virtio_balloon.c static void tell_host(struct virtio_balloon *vb, struct virtqueue *vq) · line 175

Quoted 2 lines
drivers/virtio/virtio_balloon.c +2 -0
+	/* 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.

Quoted 34 lines
drivers/virtio/virtio_balloon.c +11 -0
+}
+
 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)) {

drivers/virtio/virtio_balloon.c static int virtballoon_probe(struct virtio_device *vdev) · line 961

Quoted 6 lines
drivers/virtio/virtio_balloon.c +3 -0
@@ -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 ...

Quoted 47 lines
drivers/virtio/virtio_balloon.c +12 -0
+	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 = {
include/uapi/linux/virtio_balloon.h +1 -0
index a1966cd7b677..2b0f62814e22 100644
@@ -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
Signature · 2 lines
Thanks
Nitesh
#19 lore raw

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

Quoted 14 lines · Nitesh Narayan Lal
Quoted 12 lines · Michael S. Tsirkin
Quoted 11 lines · Alexander Duyck

From: Alexander Duyck <[email protected]>

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.

Quoted 8 lines
Quoted 6 lines

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.

Quoted 186 lines
Quoted 183 lines

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

Not a blocker for sure ...

Quoted 60 lines
---
 drivers/virtio/Kconfig              |    1 +
 drivers/virtio/virtio_balloon.c     |   47 +++++++++++++++++++++++++++++++++++
 include/uapi/linux/virtio_balloon.h |    1 +
 3 files changed, 49 insertions(+)
drivers/virtio/Kconfig +1 -0
index 078615cf2afc..d45556ae1f81 100644
@@ -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.
drivers/virtio/virtio_balloon.c +7 -0
index 226fbb995fb0..dee9f8f3ad09 100644
@@ -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)
 
 }

drivers/virtio/virtio_balloon.c static void tell_host(struct virtio_balloon *vb, struct virtqueue *vq) · line 170

Quoted 10 lines
drivers/virtio/virtio_balloon.c +9 -0
 
+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 ...

drivers/virtio/virtio_balloon.c static void tell_host(struct virtio_balloon *vb, struct virtqueue *vq) · line 172

Quoted 2 lines
drivers/virtio/virtio_balloon.c +2 -0
+	virtqueue_add_inbuf(vq, ph_dev_info->sg, num_hints, vb, GFP_KERNEL);
+	virtqueue_kick(vq);

... this will block forever.

drivers/virtio/virtio_balloon.c static void tell_host(struct virtio_balloon *vb, struct virtqueue *vq) · line 175

Quoted 2 lines
drivers/virtio/virtio_balloon.c +2 -0
+	/* 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.

Quoted 34 lines
drivers/virtio/virtio_balloon.c +11 -0
+}
+
 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)) {

drivers/virtio/virtio_balloon.c static int virtballoon_probe(struct virtio_device *vdev) · line 961

Quoted 6 lines
drivers/virtio/virtio_balloon.c +3 -0
@@ -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 ...

Quoted 47 lines
drivers/virtio/virtio_balloon.c +12 -0
+	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 = {
include/uapi/linux/virtio_balloon.h +1 -0
index a1966cd7b677..2b0f62814e22 100644
@@ -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
Signature · 2 lines
Thanks
Nitesh
#20 lore raw

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

In reply to Michael S. Tsirkin
Quoted 20 lines · Michael S. Tsirkin
Quoted 11 lines · Alexander Duyck

From: Alexander Duyck <[email protected]>

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.

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

Quoted 4 lines

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.

Quoted 78 lines
Quoted 60 lines
---
 drivers/virtio/Kconfig              |    1 +
 drivers/virtio/virtio_balloon.c     |   47 +++++++++++++++++++++++++++++++++++
 include/uapi/linux/virtio_balloon.h |    1 +
 3 files changed, 49 insertions(+)
drivers/virtio/Kconfig +1 -0
index 078615cf2afc..d45556ae1f81 100644
@@ -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.
drivers/virtio/virtio_balloon.c +7 -0
index 226fbb995fb0..dee9f8f3ad09 100644
@@ -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)
 
 }

drivers/virtio/virtio_balloon.c static void tell_host(struct virtio_balloon *vb, struct virtqueue *vq) · line 170

Quoted 10 lines
drivers/virtio/virtio_balloon.c +9 -0
 
+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 ...

drivers/virtio/virtio_balloon.c static void tell_host(struct virtio_balloon *vb, struct virtqueue *vq) · line 172

Quoted 2 lines
drivers/virtio/virtio_balloon.c +2 -0
+	virtqueue_add_inbuf(vq, ph_dev_info->sg, num_hints, vb, GFP_KERNEL);
+	virtqueue_kick(vq);

... this will block forever.

Quoted 5 lines

drivers/virtio/virtio_balloon.c static void tell_host(struct virtio_balloon *vb, struct virtqueue *vq) · line 175

Quoted 2 lines
drivers/virtio/virtio_balloon.c +2 -0
+	/* 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.

Quoted 38 lines
Quoted 38 lines
drivers/virtio/virtio_balloon.c +12 -0
+}
+
 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;
 	}
+
Quoted 8 lines

drivers/virtio/virtio_balloon.c static int virtballoon_probe(struct virtio_device *vdev) · line 961

Quoted 2 lines
drivers/virtio/virtio_balloon.c +2 -0
+	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?

#21 lore raw

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

Quoted 24 lines · Alexander Duyck
Quoted 23 lines · Michael S. Tsirkin
Quoted 11 lines · Alexander Duyck

From: Alexander Duyck <[email protected]>

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.

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.

Quoted 7 lines
Quoted 1 line

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...

Quoted 138 lines
Quoted 78 lines
Quoted 60 lines
---
 drivers/virtio/Kconfig              |    1 +
 drivers/virtio/virtio_balloon.c     |   47 +++++++++++++++++++++++++++++++++++
 include/uapi/linux/virtio_balloon.h |    1 +
 3 files changed, 49 insertions(+)
drivers/virtio/Kconfig +1 -0
index 078615cf2afc..d45556ae1f81 100644
@@ -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.
drivers/virtio/virtio_balloon.c +7 -0
index 226fbb995fb0..dee9f8f3ad09 100644
@@ -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)
 
 }

drivers/virtio/virtio_balloon.c static void tell_host(struct virtio_balloon *vb, struct virtqueue *vq) · line 170

Quoted 10 lines
drivers/virtio/virtio_balloon.c +9 -0
 
+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 ...

drivers/virtio/virtio_balloon.c static void tell_host(struct virtio_balloon *vb, struct virtqueue *vq) · line 172

Quoted 2 lines
drivers/virtio/virtio_balloon.c +2 -0
+	virtqueue_add_inbuf(vq, ph_dev_info->sg, num_hints, vb, GFP_KERNEL);
+	virtqueue_kick(vq);

... this will block forever.

Quoted 5 lines

drivers/virtio/virtio_balloon.c static void tell_host(struct virtio_balloon *vb, struct virtqueue *vq) · line 175

Quoted 2 lines
drivers/virtio/virtio_balloon.c +2 -0
+	/* 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.

Quoted 38 lines
Quoted 38 lines
drivers/virtio/virtio_balloon.c +12 -0
+}
+
 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;
 	}
+
Quoted 8 lines

drivers/virtio/virtio_balloon.c static int virtballoon_probe(struct virtio_device *vdev) · line 961

Quoted 2 lines
drivers/virtio/virtio_balloon.c +2 -0
+	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?

#22 lore raw

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

In reply to Michael S. Tsirkin
Quoted 86 lines · Michael S. Tsirkin
Quoted 11 lines · Alexander Duyck

From: Alexander Duyck <[email protected]>

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.

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 ...

Quoted 61 lines
---
 drivers/virtio/Kconfig              |    1 +
 drivers/virtio/virtio_balloon.c     |   47 +++++++++++++++++++++++++++++++++++
 include/uapi/linux/virtio_balloon.h |    1 +
 3 files changed, 49 insertions(+)
drivers/virtio/Kconfig +1 -0
index 078615cf2afc..d45556ae1f81 100644
@@ -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.
drivers/virtio/virtio_balloon.c +7 -0
index 226fbb995fb0..dee9f8f3ad09 100644
@@ -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)
 
 }
 
Quoted 11 lines

drivers/virtio/virtio_balloon.c static void tell_host(struct virtio_balloon *vb, struct virtqueue *vq) · line 170

Quoted 9 lines
drivers/virtio/virtio_balloon.c +9 -0
+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?

Quoted 105 lines

drivers/virtio/virtio_balloon.c static void tell_host(struct virtio_balloon *vb, struct virtqueue *vq) · line 172

Quoted 3 lines
drivers/virtio/virtio_balloon.c +2 -0
+	virtqueue_add_inbuf(vq, ph_dev_info->sg, num_hints, vb, GFP_KERNEL);
+	virtqueue_kick(vq);

... this will block forever.

drivers/virtio/virtio_balloon.c static void tell_host(struct virtio_balloon *vb, struct virtqueue *vq) · line 175

Quoted 2 lines
drivers/virtio/virtio_balloon.c +2 -0
+	/* 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.

Quoted 34 lines
drivers/virtio/virtio_balloon.c +11 -0
+}
+
 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)) {

drivers/virtio/virtio_balloon.c static int virtballoon_probe(struct virtio_device *vdev) · line 961

Quoted 6 lines
drivers/virtio/virtio_balloon.c +3 -0
@@ -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 ...

Quoted 47 lines
drivers/virtio/virtio_balloon.c +12 -0
+	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 = {
include/uapi/linux/virtio_balloon.h +1 -0
index a1966cd7b677..2b0f62814e22 100644
@@ -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
Signature · 2 lines
Thanks
Nitesh
#23 lore raw

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

Quoted 100 lines · Nitesh Narayan Lal
Quoted 86 lines · Michael S. Tsirkin
Quoted 11 lines · Alexander Duyck

From: Alexander Duyck <[email protected]>

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.

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 ...

Quoted 61 lines
---
 drivers/virtio/Kconfig              |    1 +
 drivers/virtio/virtio_balloon.c     |   47 +++++++++++++++++++++++++++++++++++
 include/uapi/linux/virtio_balloon.h |    1 +
 3 files changed, 49 insertions(+)
drivers/virtio/Kconfig +1 -0
index 078615cf2afc..d45556ae1f81 100644
@@ -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.
drivers/virtio/virtio_balloon.c +7 -0
index 226fbb995fb0..dee9f8f3ad09 100644
@@ -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)
 
 }
 
Quoted 11 lines

drivers/virtio/virtio_balloon.c static void tell_host(struct virtio_balloon *vb, struct virtqueue *vq) · line 170

Quoted 9 lines
drivers/virtio/virtio_balloon.c +9 -0
+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 ...

Quoted 3 lines

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.

Quoted 109 lines
Quoted 106 lines

drivers/virtio/virtio_balloon.c static void tell_host(struct virtio_balloon *vb, struct virtqueue *vq) · line 172

Quoted 4 lines
drivers/virtio/virtio_balloon.c +2 -0
+	virtqueue_add_inbuf(vq, ph_dev_info->sg, num_hints, vb, GFP_KERNEL);
+	virtqueue_kick(vq);

... this will block forever.

drivers/virtio/virtio_balloon.c static void tell_host(struct virtio_balloon *vb, struct virtqueue *vq) · line 175

Quoted 2 lines
drivers/virtio/virtio_balloon.c +2 -0
+	/* 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.

Quoted 34 lines
drivers/virtio/virtio_balloon.c +11 -0
+}
+
 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)) {

drivers/virtio/virtio_balloon.c static int virtballoon_probe(struct virtio_device *vdev) · line 961

Quoted 6 lines
drivers/virtio/virtio_balloon.c +3 -0
@@ -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 ...

Quoted 47 lines
drivers/virtio/virtio_balloon.c +12 -0
+	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 = {
include/uapi/linux/virtio_balloon.h +1 -0
index a1966cd7b677..2b0f62814e22 100644
@@ -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
Signature · 2 lines
Thanks
Nitesh
#24 lore raw

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

In reply to Nitesh Narayan Lal
Quoted 99 lines · Nitesh Narayan Lal
Quoted 86 lines · Michael S. Tsirkin
Quoted 11 lines · Alexander Duyck

From: Alexander Duyck <[email protected]>

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.

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 ...

Quoted 61 lines
---
 drivers/virtio/Kconfig              |    1 +
 drivers/virtio/virtio_balloon.c     |   47 +++++++++++++++++++++++++++++++++++
 include/uapi/linux/virtio_balloon.h |    1 +
 3 files changed, 49 insertions(+)
drivers/virtio/Kconfig +1 -0
index 078615cf2afc..d45556ae1f81 100644
@@ -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.
drivers/virtio/virtio_balloon.c +7 -0
index 226fbb995fb0..dee9f8f3ad09 100644
@@ -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)
 
 }
 
Quoted 11 lines

drivers/virtio/virtio_balloon.c static void tell_host(struct virtio_balloon *vb, struct virtqueue *vq) · line 170

Quoted 9 lines
drivers/virtio/virtio_balloon.c +9 -0
+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 ...

Quoted 3 lines

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.

#25 lore raw

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

Quoted 104 lines · Alexander Duyck
Quoted 99 lines · Nitesh Narayan Lal
Quoted 86 lines · Michael S. Tsirkin
Quoted 11 lines · Alexander Duyck

From: Alexander Duyck <[email protected]>

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.

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 ...

Quoted 61 lines
---
 drivers/virtio/Kconfig              |    1 +
 drivers/virtio/virtio_balloon.c     |   47 +++++++++++++++++++++++++++++++++++
 include/uapi/linux/virtio_balloon.h |    1 +
 3 files changed, 49 insertions(+)
drivers/virtio/Kconfig +1 -0
index 078615cf2afc..d45556ae1f81 100644
@@ -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.
drivers/virtio/virtio_balloon.c +7 -0
index 226fbb995fb0..dee9f8f3ad09 100644
@@ -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)
 
 }
 
Quoted 11 lines

drivers/virtio/virtio_balloon.c static void tell_host(struct virtio_balloon *vb, struct virtqueue *vq) · line 170

Quoted 9 lines
drivers/virtio/virtio_balloon.c +9 -0
+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 ...

Quoted 3 lines

Do we need an error check here?

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

Quoted 9 lines

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.

Quoted 1 line
#26 lore raw

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

In reply to Alexander Duyck
Quoted 121 lines · Alexander Duyck

From: Alexander Duyck <[email protected]>

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.

---
 drivers/virtio/Kconfig              |    1 +
 drivers/virtio/virtio_balloon.c     |   47 +++++++++++++++++++++++++++++++++++
 include/uapi/linux/virtio_balloon.h |    1 +
 3 files changed, 49 insertions(+)
drivers/virtio/Kconfig +1 -0
index 078615cf2afc..d45556ae1f81 100644
@@ -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.
drivers/virtio/virtio_balloon.c +32 -0
index 226fbb995fb0..dee9f8f3ad09 100644
@@ -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)

drivers/virtio/virtio_balloon.c static int virtballoon_probe(struct virtio_device *vdev) · line 966

Quoted 10 lines
drivers/virtio/virtio_balloon.c +8 -0
 			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?

Quoted 43 lines
drivers/virtio/virtio_balloon.c +7 -0
+
 	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 = {
include/uapi/linux/virtio_balloon.h +1 -0
index a1966cd7b677..2b0f62814e22 100644
@@ -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
Signature · 2 lines
Thanks
Nitesh
#27 lore raw

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

Quoted 4 lines · Nitesh Narayan Lal
Quoted 3 lines · Alexander Duyck

From: Alexander Duyck <[email protected]>

<snip>

Quoted 6 lines
Quoted 6 lines
drivers/virtio/virtio_balloon.c +2 -0
@@ -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;
Quoted 8 lines

drivers/virtio/virtio_balloon.c static int virtballoon_probe(struct virtio_device *vdev) · line 966

Quoted 6 lines
drivers/virtio/virtio_balloon.c +6 -0
+	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.

#28 lore raw

PATCH v2 1/1 virtio-balloon: Provide a interface for "bubble hinting"

In reply to Alexander Duyck

From: Alexander Duyck <[email protected]>

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.

---
 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(-)
hw/virtio/virtio-balloon.c +40 -0
index 2112874055fb..70c0004c0f88 100644
@@ -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(),
include/hw/virtio/virtio-balloon.h +1 -1
index 1afafb12f6bc..a58b24fdf29d 100644
@@ -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;
include/standard-headers/linux/virtio_balloon.h +1 -0
index 9375ca2a70de..f9e3e8256261 100644
@@ -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
#29 lore raw

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

Quoted 44 lines · Alexander Duyck

From: Alexander Duyck <[email protected]>

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.

---
 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(-)
hw/virtio/virtio-balloon.c +15 -0
index 2112874055fb..70c0004c0f88 100644
@@ -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())

hw/virtio/virtio-balloon.c static void balloon_stats_set_poll_interval(Object *obj, Visitor *v, · line 355

Quoted 10 lines
hw/virtio/virtio-balloon.c +10 -0
+                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?

Quoted 57 lines
hw/virtio/virtio-balloon.c +15 -0
+        }
+
+        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(),
include/hw/virtio/virtio-balloon.h +1 -1
index 1afafb12f6bc..a58b24fdf29d 100644
@@ -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;
include/standard-headers/linux/virtio_balloon.h +1 -0
index 9375ca2a70de..f9e3e8256261 100644
@@ -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
#30 lore raw

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

Quoted 51 lines · Michael S. Tsirkin
Quoted 50 lines · Alexander Duyck

From: Alexander Duyck <[email protected]>

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.

---
 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(-)
hw/virtio/virtio-balloon.c +21 -0
index 2112874055fb..70c0004c0f88 100644
@@ -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 */
Quoted 8 lines

hw/virtio/virtio-balloon.c static void balloon_stats_set_poll_interval(Object *obj, Visitor *v, · line 355

Quoted 4 lines
hw/virtio/virtio-balloon.c +4 -0
+            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.

#31 lore raw

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

Quoted 59 lines · Alexander Duyck
Quoted 50 lines · Michael S. Tsirkin
Quoted 49 lines · Alexander Duyck

From: Alexander Duyck <[email protected]>

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.

---
 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(-)
hw/virtio/virtio-balloon.c +20 -0
index 2112874055fb..70c0004c0f88 100644
@@ -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);
+
Quoted 8 lines

hw/virtio/virtio-balloon.c static void balloon_stats_set_poll_interval(Object *obj, Visitor *v, · line 355

Quoted 5 lines
hw/virtio/virtio-balloon.c +5 -0
+            /* 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?

Quoted 5 lines

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.

Quoted 2 lines
Signature · 2 lines
Thanks
Nitesh
#32 lore raw

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

Quoted 66 lines · Nitesh Narayan Lal
Quoted 59 lines · Alexander Duyck
Quoted 50 lines · Michael S. Tsirkin
Quoted 49 lines · Alexander Duyck

From: Alexander Duyck <[email protected]>

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.

---
 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(-)
hw/virtio/virtio-balloon.c +20 -0
index 2112874055fb..70c0004c0f88 100644
@@ -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);
+
Quoted 8 lines

hw/virtio/virtio-balloon.c static void balloon_stats_set_poll_interval(Object *obj, Visitor *v, · line 355

Quoted 5 lines
hw/virtio/virtio-balloon.c +5 -0
+            /* 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?

Quoted 5 lines

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.

Quoted 4 lines

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?

Quoted 5 lines
Quoted 2 lines
Signature · 2 lines
Thanks
Nitesh
#33 lore raw

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

Quoted 74 lines · Michael S. Tsirkin
Quoted 66 lines · Nitesh Narayan Lal
Quoted 59 lines · Alexander Duyck
Quoted 50 lines · Michael S. Tsirkin
Quoted 49 lines · Alexander Duyck

From: Alexander Duyck <[email protected]>

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.

---
 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(-)
hw/virtio/virtio-balloon.c +20 -0
index 2112874055fb..70c0004c0f88 100644
@@ -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);
+
Quoted 8 lines

hw/virtio/virtio-balloon.c static void balloon_stats_set_poll_interval(Object *obj, Visitor *v, · line 355

Quoted 5 lines
hw/virtio/virtio-balloon.c +5 -0
+            /* 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?

Quoted 5 lines

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.

Quoted 4 lines

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.

Quoted 3 lines

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.

#34 lore raw

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

Quoted 79 lines · Alexander Duyck
Quoted 74 lines · Michael S. Tsirkin
Quoted 66 lines · Nitesh Narayan Lal
Quoted 59 lines · Alexander Duyck
Quoted 50 lines · Michael S. Tsirkin
Quoted 49 lines · Alexander Duyck

From: Alexander Duyck <[email protected]>

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.

---
 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(-)
hw/virtio/virtio-balloon.c +20 -0
index 2112874055fb..70c0004c0f88 100644
@@ -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);
+
Quoted 8 lines

hw/virtio/virtio-balloon.c static void balloon_stats_set_poll_interval(Object *obj, Visitor *v, · line 355

Quoted 5 lines
hw/virtio/virtio-balloon.c +5 -0
+            /* 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?

Quoted 5 lines

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.

Quoted 4 lines

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.

Quoted 3 lines

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

Quoted 7 lines

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?

Quoted 9 lines

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?

Quoted 4 lines

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?

Signature · 1 line
MST
#35 lore raw

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

Quoted 89 lines · Michael S. Tsirkin
Quoted 79 lines · Alexander Duyck
Quoted 74 lines · Michael S. Tsirkin
Quoted 66 lines · Nitesh Narayan Lal
Quoted 59 lines · Alexander Duyck
Quoted 50 lines · Michael S. Tsirkin
Quoted 49 lines · Alexander Duyck

From: Alexander Duyck <[email protected]>

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.

---
 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(-)
hw/virtio/virtio-balloon.c +20 -0
index 2112874055fb..70c0004c0f88 100644
@@ -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);
+
Quoted 8 lines

hw/virtio/virtio-balloon.c static void balloon_stats_set_poll_interval(Object *obj, Visitor *v, · line 355

Quoted 5 lines
hw/virtio/virtio-balloon.c +5 -0
+            /* 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?

Quoted 5 lines

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.

Quoted 4 lines

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.

Quoted 3 lines

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

Quoted 7 lines

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.

Quoted 3 lines

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.

Quoted 21 lines
Quoted 9 lines

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;
}
Quoted 2 lines

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?

Quoted 7 lines
Quoted 4 lines

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.

#36 lore raw

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

Quoted 99 lines · Alexander Duyck
Quoted 89 lines · Michael S. Tsirkin
Quoted 79 lines · Alexander Duyck
Quoted 74 lines · Michael S. Tsirkin
Quoted 66 lines · Nitesh Narayan Lal
Quoted 59 lines · Alexander Duyck
Quoted 50 lines · Michael S. Tsirkin
Quoted 49 lines · Alexander Duyck

From: Alexander Duyck <[email protected]>

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.

---
 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(-)
hw/virtio/virtio-balloon.c +20 -0
index 2112874055fb..70c0004c0f88 100644
@@ -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);
+
Quoted 8 lines

hw/virtio/virtio-balloon.c static void balloon_stats_set_poll_interval(Object *obj, Visitor *v, · line 355

Quoted 5 lines
hw/virtio/virtio-balloon.c +5 -0
+            /* 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?

Quoted 5 lines

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.

Quoted 4 lines

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.

Quoted 3 lines

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

Quoted 7 lines

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.

Quoted 3 lines

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.

Quoted 6 lines

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.

Quoted 24 lines
Quoted 21 lines
Quoted 9 lines

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;
}
Quoted 2 lines

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

Quoted 6 lines

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.

Quoted 13 lines
Quoted 7 lines
Quoted 4 lines

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.

Quoted 8 lines

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);
Signature · 1 line
MST
#37 lore raw

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

Quoted 115 lines · Michael S. Tsirkin
Quoted 99 lines · Alexander Duyck
Quoted 89 lines · Michael S. Tsirkin
Quoted 79 lines · Alexander Duyck
Quoted 74 lines · Michael S. Tsirkin
Quoted 66 lines · Nitesh Narayan Lal
Quoted 59 lines · Alexander Duyck
Quoted 50 lines · Michael S. Tsirkin
Quoted 49 lines · Alexander Duyck

From: Alexander Duyck <[email protected]>

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.

---
 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(-)
hw/virtio/virtio-balloon.c +20 -0
index 2112874055fb..70c0004c0f88 100644
@@ -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);
+
Quoted 8 lines

hw/virtio/virtio-balloon.c static void balloon_stats_set_poll_interval(Object *obj, Visitor *v, · line 355

Quoted 5 lines
hw/virtio/virtio-balloon.c +5 -0
+            /* 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?

Quoted 5 lines

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.

Quoted 4 lines

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.

Quoted 3 lines

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

Quoted 7 lines

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.

Quoted 3 lines

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.

Quoted 6 lines

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.

Quoted 6 lines

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.

Quoted 31 lines
Quoted 24 lines
Quoted 21 lines
Quoted 9 lines

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;
}
Quoted 2 lines

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

Quoted 6 lines

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?

Quoted 4 lines

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.

Quoted 23 lines
Quoted 13 lines
Quoted 7 lines
Quoted 4 lines

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.

Quoted 8 lines

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.

Quoted 5 lines

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.

Quoted 7 lines

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.

#38 lore raw

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

Quoted 164 lines · Alexander Duyck
Quoted 115 lines · Michael S. Tsirkin
Quoted 99 lines · Alexander Duyck
Quoted 89 lines · Michael S. Tsirkin
Quoted 79 lines · Alexander Duyck
Quoted 74 lines · Michael S. Tsirkin
Quoted 66 lines · Nitesh Narayan Lal
Quoted 59 lines · Alexander Duyck
Quoted 50 lines · Michael S. Tsirkin
Quoted 49 lines · Alexander Duyck

From: Alexander Duyck <[email protected]>

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.

---
 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(-)
hw/virtio/virtio-balloon.c +20 -0
index 2112874055fb..70c0004c0f88 100644
@@ -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);
+
Quoted 8 lines

hw/virtio/virtio-balloon.c static void balloon_stats_set_poll_interval(Object *obj, Visitor *v, · line 355

Quoted 5 lines
hw/virtio/virtio-balloon.c +5 -0
+            /* 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?

Quoted 5 lines

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.

Quoted 4 lines

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.

Quoted 3 lines

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

Quoted 7 lines

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.

Quoted 3 lines

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.

Quoted 6 lines

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.

Quoted 6 lines

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.

Quoted 31 lines
Quoted 24 lines
Quoted 21 lines
Quoted 9 lines

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;
}
Quoted 2 lines

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

Quoted 6 lines

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?

Quoted 4 lines

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

Quoted 4 lines

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.

Quoted 29 lines
Quoted 23 lines
Quoted 13 lines
Quoted 7 lines
Quoted 4 lines

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.

Quoted 8 lines

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.

Quoted 5 lines

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.

Quoted 8 lines

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).

Quoted 9 lines
Quoted 7 lines

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.

#39 lore raw

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

In reply to Alexander Duyck
Quoted 61 lines · Alexander Duyck
Quoted 51 lines · Michael S. Tsirkin
Quoted 50 lines · Alexander Duyck

From: Alexander Duyck <[email protected]>

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.

---
 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(-)
hw/virtio/virtio-balloon.c +21 -0
index 2112874055fb..70c0004c0f88 100644
@@ -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 */
Quoted 8 lines

hw/virtio/virtio-balloon.c static void balloon_stats_set_poll_interval(Object *obj, Visitor *v, · line 355

Quoted 4 lines
hw/virtio/virtio-balloon.c +4 -0
+            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?

Quoted 5 lines

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.

Signature · 1 line
MST
#40 lore raw

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

Quoted 68 lines · Michael S. Tsirkin
Quoted 61 lines · Alexander Duyck
Quoted 51 lines · Michael S. Tsirkin
Quoted 50 lines · Alexander Duyck

From: Alexander Duyck <[email protected]>

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.

---
 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(-)
hw/virtio/virtio-balloon.c +21 -0
index 2112874055fb..70c0004c0f88 100644
@@ -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 */
Quoted 8 lines

hw/virtio/virtio-balloon.c static void balloon_stats_set_poll_interval(Object *obj, Visitor *v, · line 355

Quoted 4 lines
hw/virtio/virtio-balloon.c +4 -0
+            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?

Quoted 5 lines

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.

Quoted 3 lines

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.

#41 lore raw

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

In reply to Alexander Duyck
Quoted 59 lines · Alexander Duyck
Quoted 50 lines · Michael S. Tsirkin
Quoted 49 lines · Alexander Duyck

From: Alexander Duyck <[email protected]>

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.

---
 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(-)
hw/virtio/virtio-balloon.c +20 -0
index 2112874055fb..70c0004c0f88 100644
@@ -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);
+
Quoted 8 lines

hw/virtio/virtio-balloon.c static void balloon_stats_set_poll_interval(Object *obj, Visitor *v, · line 355

Quoted 5 lines
hw/virtio/virtio-balloon.c +5 -0
+            /* 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?

Quoted 5 lines

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.

Quoted 2 lines
Signature · 2 lines
Thanks
Nitesh
#42 lore raw

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

Quoted 66 lines · Nitesh Narayan Lal
Quoted 59 lines · Alexander Duyck
Quoted 50 lines · Michael S. Tsirkin
Quoted 49 lines · Alexander Duyck

From: Alexander Duyck <[email protected]>

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.

---
 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(-)
hw/virtio/virtio-balloon.c +20 -0
index 2112874055fb..70c0004c0f88 100644
@@ -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);
+
Quoted 8 lines

hw/virtio/virtio-balloon.c static void balloon_stats_set_poll_interval(Object *obj, Visitor *v, · line 355

Quoted 5 lines
hw/virtio/virtio-balloon.c +5 -0
+            /* 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?

Quoted 5 lines

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.

Quoted 3 lines

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.

#43 lore raw

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

In reply to Alexander Duyck
Quoted 8 lines · Alexander Duyck

From: Alexander Duyck <[email protected]>

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.

Quoted 7 lines

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.

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.

Quoted 96 lines
---
 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(-)
hw/virtio/virtio-balloon.c +40 -0
index 2112874055fb..70c0004c0f88 100644
@@ -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(),
include/hw/virtio/virtio-balloon.h +1 -1
index 1afafb12f6bc..a58b24fdf29d 100644
@@ -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;
include/standard-headers/linux/virtio_balloon.h +1 -0
index 9375ca2a70de..f9e3e8256261 100644
@@ -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
#44 lore raw

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

Quoted 15 lines · Michael S. Tsirkin
Quoted 14 lines · Alexander Duyck

From: Alexander Duyck <[email protected]>

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.

Quoted 6 lines
Quoted 1 line

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.

Quoted 3 lines

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.

#45 lore raw

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

Quoted 18 lines · Alexander Duyck
Quoted 17 lines · Michael S. Tsirkin
Quoted 15 lines · Alexander Duyck

From: Alexander Duyck <[email protected]>

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.

Quoted 8 lines
Quoted 4 lines

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.

Quoted 9 lines

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.

Quoted 3 lines

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?

Quoted 4 lines

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 :)

Signature · 1 line
MST
#46 lore raw

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

Quoted 33 lines · Michael S. Tsirkin
Quoted 18 lines · Alexander Duyck
Quoted 17 lines · Michael S. Tsirkin
Quoted 15 lines · Alexander Duyck

From: Alexander Duyck <[email protected]>

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.

Quoted 8 lines
Quoted 4 lines

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.

Quoted 3 lines

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.

Quoted 8 lines
Quoted 6 lines
Quoted 3 lines

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.

Quoted 7 lines
Quoted 4 lines

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.

#47 lore raw

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

Quoted 41 lines · Alexander Duyck
Quoted 40 lines · Michael S. Tsirkin
Quoted 18 lines · Alexander Duyck
Quoted 17 lines · Michael S. Tsirkin
Quoted 15 lines · Alexander Duyck

From: Alexander Duyck <[email protected]>

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.

Quoted 8 lines
Quoted 4 lines

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.

Quoted 9 lines

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.

Quoted 3 lines

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.

Quoted 6 lines
Quoted 1 line

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.

Quoted 14 lines
Quoted 7 lines
Quoted 4 lines

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.

Quoted 3 lines

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 :)

#48 lore raw

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

In reply to Alexander Duyck
Quoted 21 lines · Alexander Duyck
Quoted 15 lines · Michael S. Tsirkin
Quoted 14 lines · Alexander Duyck

From: Alexander Duyck <[email protected]>

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.

Quoted 5 lines
Quoted 1 line

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.

Quoted 5 lines

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?

Quoted 5 lines
Quoted 3 lines

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.

Quoted 5 lines

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.

Signature · 2 lines
Thanks
Nitesh
#49 lore raw

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

Quoted 22 lines · Nitesh Narayan Lal
Quoted 21 lines · Alexander Duyck
Quoted 20 lines · Michael S. Tsirkin
Quoted 8 lines · Alexander Duyck

From: Alexander Duyck <[email protected]>

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.

Quoted 7 lines

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.

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.

Quoted 8 lines
Quoted 5 lines

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.

Quoted 5 lines
Quoted 5 lines
Quoted 3 lines

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.

Quoted 7 lines

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.

#50 lore raw

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

Quoted 61 lines · Alexander Duyck
Quoted 22 lines · Nitesh Narayan Lal
Quoted 21 lines · Alexander Duyck
Quoted 20 lines · Michael S. Tsirkin
Quoted 8 lines · Alexander Duyck

From: Alexander Duyck <[email protected]>

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.

Quoted 7 lines

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.

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.

Quoted 8 lines
Quoted 5 lines

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.

Quoted 5 lines
Quoted 5 lines
Quoted 3 lines

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.

Quoted 7 lines

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.

Quoted 5 lines

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.

Signature · 1 line
MST
#51 lore raw

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

Quoted 68 lines · Michael S. Tsirkin
Quoted 61 lines · Alexander Duyck
Quoted 22 lines · Nitesh Narayan Lal
Quoted 21 lines · Alexander Duyck
Quoted 20 lines · Michael S. Tsirkin
Quoted 8 lines · Alexander Duyck

From: Alexander Duyck <[email protected]>

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.

Quoted 7 lines

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.

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.

Quoted 8 lines
Quoted 5 lines

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.

Quoted 5 lines
Quoted 5 lines
Quoted 3 lines

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.

Quoted 7 lines

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.

Quoted 5 lines

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.

Quoted 4 lines

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.

Quoted 1 line

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.

Quoted 1 line

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

#52 lore raw

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

Quoted 80 lines · Alexander Duyck
Quoted 68 lines · Michael S. Tsirkin
Quoted 61 lines · Alexander Duyck
Quoted 22 lines · Nitesh Narayan Lal
Quoted 21 lines · Alexander Duyck
Quoted 20 lines · Michael S. Tsirkin
Quoted 8 lines · Alexander Duyck

From: Alexander Duyck <[email protected]>

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.

Quoted 7 lines

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.

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.

Quoted 8 lines
Quoted 5 lines

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.

Quoted 5 lines
Quoted 5 lines
Quoted 3 lines

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.

Quoted 7 lines

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.

Quoted 5 lines

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.

Quoted 4 lines

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.

Quoted 4 lines

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.

Quoted 6 lines
Quoted 1 line

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.

Quoted 8 lines
Quoted 1 line

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

#53 lore raw

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

In reply to Alexander Duyck
Quoted 66 lines · Alexander Duyck
Quoted 65 lines · Michael S. Tsirkin
Quoted 64 lines · Alexander Duyck
Quoted 22 lines · Nitesh Narayan Lal
Quoted 21 lines · Alexander Duyck
Quoted 20 lines · Michael S. Tsirkin
Quoted 8 lines · Alexander Duyck

From: Alexander Duyck <[email protected]>

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.

Quoted 7 lines

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.

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.

Quoted 8 lines
Quoted 5 lines

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.

Quoted 5 lines
Quoted 5 lines
Quoted 3 lines

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.

Quoted 7 lines

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.

Quoted 6 lines
Quoted 4 lines

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.

Quoted 10 lines

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.

Quoted 4 lines
Quoted 1 line

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.

Quoted 2 lines

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?

Quoted 9 lines
Quoted 2 lines

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

Signature · 2 lines
Thanks
Nitesh
#54 lore raw

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

Quoted 10 lines · Nitesh Narayan Lal
Quoted 9 lines · Alexander Duyck
Quoted 8 lines · Michael S. Tsirkin
Quoted 7 lines · Alexander Duyck
Quoted 6 lines · Nitesh Narayan Lal
Quoted 5 lines · Alexander Duyck
Quoted 4 lines · Michael S. Tsirkin
Quoted 2 lines · Alexander Duyck

From: Alexander Duyck <[email protected]>

<snip>

Quoted 15 lines
Quoted 10 lines

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.

Quoted 4 lines
Quoted 1 line

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.

Quoted 8 lines

True.

Quoted 2 lines

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.

#55 lore raw

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

Quoted 32 lines · Alexander Duyck
Quoted 9 lines · Nitesh Narayan Lal
Quoted 8 lines · Alexander Duyck
Quoted 7 lines · Michael S. Tsirkin
Quoted 6 lines · Alexander Duyck
Quoted 5 lines · Nitesh Narayan Lal
Quoted 4 lines · Alexander Duyck
Quoted 3 lines · Michael S. Tsirkin
Quoted 2 lines · Alexander Duyck

From: Alexander Duyck <[email protected]>

<snip>

Quoted 19 lines
Quoted 10 lines

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.

Quoted 4 lines
Quoted 1 line

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.

Quoted 2 lines

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

Quoted 9 lines
Quoted 2 lines

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.

Signature · 2 lines
Thanks
Nitesh
#56 lore raw
In reply to Alexander Duyck
Quoted 9 lines · 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,

Shouldn't we configure this to a lower number such as 16?

Quoted 11 lines

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.

Quoted 2 lines

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?

Quoted 3 lines

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.

Quoted 11 lines

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.

Quoted 3 lines

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?

Quoted 2 lines

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.

Quoted 17 lines

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/[email protected]/
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.

Quoted 3 lines

Changes from v1:
https://lore.kernel.org/lkml/[email protected]/
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.

Quoted 37 lines

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

--

Signature · 2 lines
Thanks
Nitesh
#57 lore raw
Quoted 69 lines · Nitesh Narayan Lal
Quoted 9 lines · 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,

Shouldn't we configure this to a lower number such as 16?

Quoted 11 lines

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.

Quoted 2 lines

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?

Quoted 3 lines

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.

Quoted 11 lines

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.

Quoted 3 lines

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?

Quoted 2 lines

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.

Quoted 17 lines

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/[email protected]/
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.

Quoted 5 lines
Quoted 3 lines

Changes from v1:
https://lore.kernel.org/lkml/[email protected]/
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.

Signature · 3 lines
Thanks,

David / dhildenb
#58 lore raw
Quoted 70 lines · David Hildenbrand
Quoted 69 lines · Nitesh Narayan Lal
Quoted 9 lines · 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,

Shouldn't we configure this to a lower number such as 16?

Quoted 11 lines

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.

Quoted 2 lines

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?

Quoted 3 lines

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.

Quoted 11 lines

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.

Quoted 3 lines

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?

Quoted 2 lines

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.

Quoted 17 lines

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/[email protected]/
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.

Quoted 8 lines
Quoted 5 lines
Quoted 3 lines

Changes from v1:
https://lore.kernel.org/lkml/[email protected]/
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.

Quoted 5 lines
Signature · 3 lines
Thanks,

David / dhildenb
#59 lore raw
Quoted 74 lines · Michael S. Tsirkin
Quoted 73 lines · David Hildenbrand
Quoted 72 lines · Nitesh Narayan Lal
Quoted 9 lines · 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,

Shouldn't we configure this to a lower number such as 16?

Quoted 11 lines

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.

Quoted 2 lines

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?

Quoted 3 lines

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.

Quoted 11 lines

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.

Quoted 3 lines

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?

Quoted 2 lines

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.

Quoted 20 lines

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/[email protected]/
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/[email protected]/
Dropped "waste page treatment" in favor of "page hinting"

Quoted 8 lines
Quoted 5 lines
Quoted 2 lines

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.

Signature · 3 lines
Thanks,

David / dhildenb
#60 lore raw
Quoted 77 lines · David Hildenbrand
Quoted 76 lines · Michael S. Tsirkin
Quoted 75 lines · David Hildenbrand
Quoted 67 lines · Nitesh Narayan Lal
Quoted 9 lines · 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,

Shouldn't we configure this to a lower number such as 16?

Quoted 11 lines

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.

Quoted 2 lines

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?

Quoted 3 lines

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.

Quoted 10 lines

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.

Quoted 3 lines

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?

Quoted 2 lines

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.

Quoted 17 lines

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/[email protected]/
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.

Quoted 5 lines
Quoted 3 lines

Changes from v1:
https://lore.kernel.org/lkml/[email protected]/
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.

Quoted 7 lines
Quoted 2 lines

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.

Signature · 2 lines
Thanks
Nitesh
#61 lore raw
In reply to David Hildenbrand
Quoted 81 lines · David Hildenbrand
Quoted 80 lines · Michael S. Tsirkin
Quoted 78 lines · David Hildenbrand
Quoted 69 lines · Nitesh Narayan Lal
Quoted 9 lines · 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,

Shouldn't we configure this to a lower number such as 16?

Quoted 11 lines

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.

Quoted 2 lines

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?

Quoted 3 lines

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.

Quoted 11 lines

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.

Quoted 3 lines

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?

Quoted 2 lines

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.

Quoted 17 lines

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/[email protected]/
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.

Quoted 5 lines
Quoted 3 lines

Changes from v1:
https://lore.kernel.org/lkml/[email protected]/
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.

Quoted 8 lines
Quoted 2 lines

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

Quoted 5 lines
Signature · 3 lines
Thanks,

David / dhildenb
#62 lore raw
In reply to Nitesh Narayan Lal
Quoted 69 lines · Nitesh Narayan Lal
Quoted 9 lines · 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,

Shouldn't we configure this to a lower number such as 16?

Quoted 11 lines

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.

Quoted 2 lines

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?

Quoted 3 lines

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.

Quoted 11 lines

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.

Quoted 3 lines

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?

Quoted 2 lines

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.

Quoted 17 lines

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/[email protected]/
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.

Quoted 5 lines
Quoted 3 lines

Changes from v1:
https://lore.kernel.org/lkml/[email protected]/
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.

Quoted 40 lines
Quoted 37 lines

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

--

Signature · 2 lines
Thanks
Nitesh
#63 lore raw
In reply to Nitesh Narayan Lal
Quoted 11 lines · Nitesh Narayan Lal
Quoted 9 lines · 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,

Shouldn't we configure this to a lower number such as 16?

Yes, we could do 16.

Quoted 11 lines
Quoted 11 lines

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.

Quoted 3 lines
Quoted 2 lines

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.

Quoted 5 lines
Quoted 3 lines

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.

Quoted 10 lines
Quoted 10 lines

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,

Quoted 6 lines

I think this is acceptable.

Quoted 3 lines

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.

Quoted 4 lines
Quoted 2 lines

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.

Quoted 17 lines
Quoted 17 lines

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/[email protected]/
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.

Quoted 5 lines
Quoted 3 lines

Changes from v1:
https://lore.kernel.org/lkml/[email protected]/
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.

#64 lore raw
Quoted 36 lines · Alexander Duyck
Quoted 11 lines · Nitesh Narayan Lal
Quoted 9 lines · 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,

Shouldn't we configure this to a lower number such as 16?

Yes, we could do 16.

Quoted 11 lines
Quoted 11 lines

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.

Quoted 3 lines
Quoted 2 lines

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.

Quoted 3 lines
Quoted 3 lines

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.

Quoted 6 lines
Quoted 2 lines

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?

Quoted 12 lines
Quoted 12 lines
Quoted 11 lines

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.

Quoted 8 lines
Quoted 5 lines
Quoted 3 lines

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.

Quoted 9 lines
Quoted 5 lines
Quoted 3 lines

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.

Quoted 18 lines
Quoted 18 lines
Quoted 18 lines

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/[email protected]/
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.

Quoted 7 lines
Quoted 5 lines
Quoted 3 lines

Changes from v1:
https://lore.kernel.org/lkml/[email protected]/
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.

Signature · 2 lines
Thanks
Nitesh
#65 lore raw
Quoted 37 lines · Nitesh Narayan Lal
Quoted 36 lines · Alexander Duyck
Quoted 11 lines · Nitesh Narayan Lal
Quoted 9 lines · 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,

Shouldn't we configure this to a lower number such as 16?

Yes, we could do 16.

Quoted 11 lines
Quoted 11 lines

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.

Quoted 3 lines
Quoted 2 lines

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.

Quoted 3 lines
Quoted 3 lines

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.

Quoted 7 lines
Quoted 6 lines
Quoted 2 lines

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.

Quoted 16 lines
Quoted 16 lines
Quoted 16 lines
Quoted 10 lines

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.

Quoted 3 lines

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?

Quoted 7 lines
Quoted 3 lines

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.

Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 2 lines

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.

Quoted 8 lines
Quoted 4 lines

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.

Quoted 17 lines
Quoted 17 lines
Quoted 17 lines
Quoted 17 lines

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/[email protected]/
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.

Quoted 8 lines
Quoted 7 lines
Quoted 5 lines
Quoted 3 lines

Changes from v1:
https://lore.kernel.org/lkml/[email protected]/
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.

#66 lore raw
Quoted 79 lines · Alexander Duyck
Quoted 37 lines · Nitesh Narayan Lal
Quoted 36 lines · Alexander Duyck
Quoted 11 lines · Nitesh Narayan Lal
Quoted 9 lines · 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,

Shouldn't we configure this to a lower number such as 16?

Yes, we could do 16.

Quoted 11 lines
Quoted 11 lines

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.

Quoted 3 lines
Quoted 2 lines

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.

Quoted 3 lines
Quoted 3 lines

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.

Quoted 7 lines
Quoted 6 lines
Quoted 2 lines

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.

Quoted 16 lines
Quoted 16 lines
Quoted 16 lines
Quoted 10 lines

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.

Quoted 3 lines

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?

Quoted 7 lines
Quoted 3 lines

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.

Quoted 5 lines

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.

Quoted 41 lines

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.

Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 2 lines

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.

Quoted 8 lines
Quoted 4 lines

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.

Quoted 22 lines
Quoted 22 lines
Quoted 22 lines
Quoted 17 lines

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/[email protected]/
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.

Quoted 3 lines

Changes from v1:
https://lore.kernel.org/lkml/[email protected]/
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.

Quoted 7 lines
Quoted 3 lines
Quoted 2 lines

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.

Quoted 1 line
Signature · 2 lines
Thanks
Nitesh
#67 lore raw
In reply to Alexander Duyck
Quoted 60 lines · Alexander Duyck
Quoted 11 lines · Nitesh Narayan Lal
Quoted 9 lines · 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,

Shouldn't we configure this to a lower number such as 16?

Yes, we could do 16.

Quoted 11 lines
Quoted 11 lines

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.

Quoted 3 lines
Quoted 2 lines

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.

Quoted 5 lines
Quoted 3 lines

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.

Quoted 14 lines
Quoted 10 lines

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.

Quoted 3 lines

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.

Quoted 6 lines
Quoted 2 lines

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.

Quoted 35 lines
Quoted 4 lines
Quoted 2 lines

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.

Quoted 17 lines
Quoted 17 lines

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/[email protected]/
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.

Quoted 5 lines
Quoted 3 lines

Changes from v1:
https://lore.kernel.org/lkml/[email protected]/
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.