[PATCH v11 0/6] mm / virtio: Provide support for unused page reporting

[PATCH v11 0/6] mm / virtio: Provide support for unused page reporting

[Alexander Duyck]

This series provides an asynchronous means of reporting 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 unused page reporting. The advantage of
unused page reporting is that we can support a significant amount of
memory over-commit with improved performance as we can avoid having to
write/read memory from swap as the VM will instead actively participate
in freeing unused memory so it doesn't have to be written.

The functionality for this is fairly simple. When enabled it will allocate
statistics to track the number of reported 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 reporting which consists of
pulling non-reported pages off of the free lists of a given zone and
placing them into a scatterlist. The scatterlist is then given to the page
reporting device and it will perform the required action to make the pages
"reported", in the case of virtio-balloon this results in the pages being
madvised as MADV_DONTNEED. After this they are placed back on their
original free list. If they are not merged in freeing an additional bit is
set indicating that they are a "reported" buddy page instead of a standard
buddy page. The cycle then repeats with additional non-reported pages
being pulled until the free areas all consist of reported pages.

In order to try and keep the time needed to find a non-reported page to
a minimum we maintain a "reported_boundary" pointer. This pointer is used
by the get_unreported_pages iterator to determine at what point it should
resume searching for non-reported pages. In order to guarantee pages do
not get past the scan I have modified add_to_free_list_tail so that it
will not insert pages behind the reported_boundary. Doing this allows us
to keep the overhead to a minimum as re-walking the list without the
boundary will result in as much as 18% additional overhead on a 32G VM.

If another process needs to perform a massive manipulation of the free
list, such as compaction, it can either reset a given individual boundary
which will push the boundary back to the list_head, or it can clear the
bit indicating the zone is actively processing which will result in the
reporting process resetting all of the boundaries for a given zone.

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. The upper limit for this is based on the size of the
queue used to store the scatterlist.

I wanted to avoid gaming the performance testing for this. As far as
possible gain a significant performance improvement should be visible in
cases where guests are forced to write/read from swap. As such, testing
it would be more of a benchmark of copying a page from swap versus just
allocating a zero page. I have been verifying that the memory is being
freed using memhog to allocate all the memory on the guest, and then
watching /proc/meminfo to verify the host sees the memory returned after
the test completes.

As far as possible regressions I have focused on cases where performing
the hinting would be non-optimal, such as cases where the code isn't
needed as memory is not over-committed, or the functionality is not in
use. I have been using the will-it-scale/page_fault1 test running with 16
vcpus and have modified it to use Transparent Huge Pages. With this I see
almost no difference with the patches applied and the feature disabled.
Likewise I see almost no difference with the feature enabled, but the
madvise disabled in the hypervisor due to a device being assigned. With
the feature fully enabled in both guest and hypervisor I see a regression
between -1.86% and -8.84% versus the baseline. I found that most of the
overhead was due to the page faulting/zeroing that comes as a result of
the pages having been evicted from the guest.

For info on earlier versions you will need to follow the links provided
with the respective versions.

Changes from v9:
https://lore.kernel.org/lkml/20190907172225.10910.34302.stgit@localhost.localdomain/
Updated cover page
Dropped per-cpu page randomization entropy patch
Added "to_tail" boolean value to __free_one_page to improve readability
Renamed __shuffle_pick_tail to shuffle_pick_tail, avoiding extra inline function
Dropped arm64 HUGLE_TLB_ORDER movement patch since it is no longer needed
Significant rewrite of page reporting functionality
  Updated logic to support interruptions from compaction
  get_unreported_page will now walk through reported sections
  Moved free_list manipulators out of mmzone.h and into page_alloc.c
  Removed page_reporting.h include from mmzone.h
  Split page_reporting.h between include/linux/ and mm/
  Added #include <asm/pgtable.h>" to mm/page_reporting.h
  Renamed page_reporting_startup/shutdown to page_reporting_register/unregister
Updated comments related to virtio page poison tracking feature

Changes from v10:
https://lore.kernel.org/lkml/20190918175109.23474.67039.stgit@localhost.localdomain/
Rebased on "Add linux-next specific files for 20190930"
Added page_is_reported() macro to prevent unneeded testing of PageReported bit
Fixed several spots where comments referred to older aeration naming
Set upper limit for phdev->capacity to page reporting high water mark
Updated virtio page poison detection logic to also cover init_on_free
Tweaked page_reporting_notify_free to reduce code size
Removed dead code in non-reporting path

---

Alexander Duyck (6):
      mm: Adjust shuffle code to allow for future coalescing
      mm: Use zone and order instead of free area in free_list manipulators
      mm: Introduce Reported pages
      mm: Add device side and notifier for unused page reporting
      virtio-balloon: Pull page poisoning config out of free page hinting
      virtio-balloon: Add support for providing unused page reports to host


 drivers/virtio/Kconfig              |    1 
 drivers/virtio/virtio_balloon.c     |   88 ++++++++-
 include/linux/mmzone.h              |   60 ++----
 include/linux/page-flags.h          |   11 +
 include/linux/page_reporting.h      |   31 +++
 include/uapi/linux/virtio_balloon.h |    1 
 mm/Kconfig                          |   11 +
 mm/Makefile                         |    1 
 mm/compaction.c                     |    5 +
 mm/memory_hotplug.c                 |    2 
 mm/page_alloc.c                     |  194 +++++++++++++++----
 mm/page_reporting.c                 |  350 +++++++++++++++++++++++++++++++++++
 mm/page_reporting.h                 |  225 +++++++++++++++++++++++
 mm/shuffle.c                        |   12 +
 mm/shuffle.h                        |    6 +
 15 files changed, 896 insertions(+), 102 deletions(-)
 create mode 100644 include/linux/page_reporting.h
 create mode 100644 mm/page_reporting.c
 create mode 100644 mm/page_reporting.h

--

[PATCH v11 1/6] mm: Adjust shuffle code to allow for future coalescing

[Alexander Duyck]

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

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.

Acked-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
---
 include/linux/mmzone.h |   12 --------
 mm/page_alloc.c        |   71 ++++++++++++++++++++++++++++--------------------
 mm/shuffle.c           |   12 ++++----
 mm/shuffle.h           |    6 ++++
 4 files changed, 54 insertions(+), 47 deletions(-)

diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index bda20282746b..125f300981c6 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -116,18 +116,6 @@ static inline void add_to_free_area_tail(struct page *page, struct free_area *ar
 	area->nr_free++;
 }
 
-#ifdef CONFIG_SHUFFLE_PAGE_ALLOCATOR
-/* Used to preserve page allocation order entropy */
-void add_to_free_area_random(struct page *page, struct free_area *area,
-		int migratetype);
-#else
-static inline void add_to_free_area_random(struct page *page,
-		struct free_area *area, int migratetype)
-{
-	add_to_free_area(page, area, migratetype);
-}
-#endif
-
 /* Used for pages which are on another list */
 static inline void move_to_free_area(struct page *page, struct free_area *area,
 			     int migratetype)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 15c2050c629b..bc8de8d9416d 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -878,6 +878,36 @@ static inline struct capture_control *task_capc(struct zone *zone)
 #endif /* CONFIG_COMPACTION */
 
 /*
+ * If this is not the largest possible page, check if the buddy
+ * of the next-highest order is free. If it is, it's possible
+ * that pages are being freed that will coalesce soon. In case,
+ * that is happening, add the free page to the tail of the list
+ * so it's less likely to be used soon and more likely to be merged
+ * as a higher order page
+ */
+static inline bool
+buddy_merge_likely(unsigned long pfn, unsigned long buddy_pfn,
+		   struct page *page, unsigned int order)
+{
+	struct page *higher_page, *higher_buddy;
+	unsigned long combined_pfn;
+
+	if (order >= MAX_ORDER - 2)
+		return false;
+
+	if (!pfn_valid_within(buddy_pfn))
+		return false;
+
+	combined_pfn = buddy_pfn & pfn;
+	higher_page = page + (combined_pfn - pfn);
+	buddy_pfn = __find_buddy_pfn(combined_pfn, order + 1);
+	higher_buddy = higher_page + (buddy_pfn - combined_pfn);
+
+	return pfn_valid_within(buddy_pfn) &&
+	       page_is_buddy(higher_page, higher_buddy, order + 1);
+}
+
+/*
  * Freeing function for a buddy system allocator.
  *
  * The concept of a buddy system is to maintain direct-mapped table
@@ -906,11 +936,13 @@ static inline void __free_one_page(struct page *page,
 		struct zone *zone, unsigned int order,
 		int migratetype)
 {
-	unsigned long combined_pfn;
+	struct capture_control *capc = task_capc(zone);
 	unsigned long uninitialized_var(buddy_pfn);
-	struct page *buddy;
+	unsigned long combined_pfn;
+	struct free_area *area;
 	unsigned int max_order;
-	struct capture_control *capc = task_capc(zone);
+	struct page *buddy;
+	bool to_tail;
 
 	max_order = min_t(unsigned int, MAX_ORDER, pageblock_order + 1);
 
@@ -979,35 +1011,16 @@ static inline void __free_one_page(struct page *page,
 done_merging:
 	set_page_order(page, order);
 
-	/*
-	 * If this is not the largest possible page, check if the buddy
-	 * of the next-highest order is free. If it is, it's possible
-	 * that pages are being freed that will coalesce soon. In case,
-	 * that is happening, add the free page to the tail of the list
-	 * so it's less likely to be used soon and more likely to be merged
-	 * as a higher order page
-	 */
-	if ((order < MAX_ORDER-2) && pfn_valid_within(buddy_pfn)
-			&& !is_shuffle_order(order)) {
-		struct page *higher_page, *higher_buddy;
-		combined_pfn = buddy_pfn & pfn;
-		higher_page = page + (combined_pfn - pfn);
-		buddy_pfn = __find_buddy_pfn(combined_pfn, order + 1);
-		higher_buddy = higher_page + (buddy_pfn - combined_pfn);
-		if (pfn_valid_within(buddy_pfn) &&
-		    page_is_buddy(higher_page, higher_buddy, order + 1)) {
-			add_to_free_area_tail(page, &zone->free_area[order],
-					      migratetype);
-			return;
-		}
-	}
-
+	area = &zone->free_area[order];
 	if (is_shuffle_order(order))
-		add_to_free_area_random(page, &zone->free_area[order],
-				migratetype);
+		to_tail = shuffle_pick_tail();
 	else
-		add_to_free_area(page, &zone->free_area[order], migratetype);
+		to_tail = buddy_merge_likely(pfn, buddy_pfn, page, order);
 
+	if (to_tail)
+		add_to_free_area_tail(page, area, migratetype);
+	else
+		add_to_free_area(page, area, migratetype);
 }
 
 /*
diff --git a/mm/shuffle.c b/mm/shuffle.c
index b3fe97fd6654..e65d57f39486 100644
--- a/mm/shuffle.c
+++ b/mm/shuffle.c
@@ -183,11 +183,11 @@ void __meminit __shuffle_free_memory(pg_data_t *pgdat)
 		shuffle_zone(z);
 }
 
-void add_to_free_area_random(struct page *page, struct free_area *area,
-		int migratetype)
+bool shuffle_pick_tail(void)
 {
 	static u64 rand;
 	static u8 rand_bits;
+	bool ret;
 
 	/*
 	 * The lack of locking is deliberate. If 2 threads race to
@@ -198,10 +198,10 @@ void add_to_free_area_random(struct page *page, struct free_area *area,
 		rand = get_random_u64();
 	}
 
-	if (rand & 1)
-		add_to_free_area(page, area, migratetype);
-	else
-		add_to_free_area_tail(page, area, migratetype);
+	ret = rand & 1;
+
 	rand_bits--;
 	rand >>= 1;
+
+	return ret;
 }
diff --git a/mm/shuffle.h b/mm/shuffle.h
index 777a257a0d2f..4d79f03b6658 100644
--- a/mm/shuffle.h
+++ b/mm/shuffle.h
@@ -22,6 +22,7 @@ enum mm_shuffle_ctl {
 DECLARE_STATIC_KEY_FALSE(page_alloc_shuffle_key);
 extern void page_alloc_shuffle(enum mm_shuffle_ctl ctl);
 extern void __shuffle_free_memory(pg_data_t *pgdat);
+extern bool shuffle_pick_tail(void);
 static inline void shuffle_free_memory(pg_data_t *pgdat)
 {
 	if (!static_branch_unlikely(&page_alloc_shuffle_key))
@@ -44,6 +45,11 @@ static inline bool is_shuffle_order(int order)
 	return order >= SHUFFLE_ORDER;
 }
 #else
+static inline bool shuffle_pick_tail(void)
+{
+	return false;
+}
+
 static inline void shuffle_free_memory(pg_data_t *pgdat)
 {
 }

[PATCH v11 2/6] mm: Use zone and order instead of free area in free_list manipulators

[Alexander Duyck]

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

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

In order to be able to reference the zone we need to move the declaration
of the functions down so that we have the zone defined before we define the
list manipulation functions. Since the functions are only used in the file
mm/page_alloc.c we can just move them there to reduce noise in the header.

Reviewed-by: Dan Williams <dan.j.williams@intel.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Pankaj Gupta <pagupta@redhat.com>
Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
---
 include/linux/mmzone.h |   32 -----------------------
 mm/page_alloc.c        |   68 +++++++++++++++++++++++++++++++++++-------------
 2 files changed, 49 insertions(+), 51 deletions(-)

diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index 125f300981c6..270a7b493174 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -100,29 +100,6 @@ struct free_area {
 	unsigned long		nr_free;
 };
 
-/* Used for pages not on another list */
-static inline void add_to_free_area(struct page *page, struct free_area *area,
-			     int migratetype)
-{
-	list_add(&page->lru, &area->free_list[migratetype]);
-	area->nr_free++;
-}
-
-/* Used for pages not on another list */
-static inline void add_to_free_area_tail(struct page *page, struct free_area *area,
-				  int migratetype)
-{
-	list_add_tail(&page->lru, &area->free_list[migratetype]);
-	area->nr_free++;
-}
-
-/* Used for pages which are on another list */
-static inline void move_to_free_area(struct page *page, struct free_area *area,
-			     int migratetype)
-{
-	list_move(&page->lru, &area->free_list[migratetype]);
-}
-
 static inline struct page *get_page_from_free_area(struct free_area *area,
 					    int migratetype)
 {
@@ -130,15 +107,6 @@ static inline struct page *get_page_from_free_area(struct free_area *area,
 					struct page, lru);
 }
 
-static inline void del_page_from_free_area(struct page *page,
-		struct free_area *area)
-{
-	list_del(&page->lru);
-	__ClearPageBuddy(page);
-	set_page_private(page, 0);
-	area->nr_free--;
-}
-
 static inline bool free_area_empty(struct free_area *area, int migratetype)
 {
 	return list_empty(&area->free_list[migratetype]);
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index bc8de8d9416d..5e142047f730 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -877,6 +877,44 @@ static inline struct capture_control *task_capc(struct zone *zone)
 }
 #endif /* CONFIG_COMPACTION */
 
+/* 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--;
+}
+
 /*
  * If this is not the largest possible page, check if the buddy
  * of the next-highest order is free. If it is, it's possible
@@ -939,7 +977,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;
 	bool to_tail;
@@ -977,7 +1014,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;
@@ -1011,16 +1048,15 @@ 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))
 		to_tail = shuffle_pick_tail();
 	else
 		to_tail = buddy_merge_likely(pfn, buddy_pfn, page, order);
 
 	if (to_tail)
-		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);
 }
 
 /*
@@ -2024,13 +2060,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]);
@@ -2044,7 +2078,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);
 	}
 }
@@ -2202,8 +2236,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;
 	}
@@ -2211,7 +2245,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
@@ -2277,7 +2310,7 @@ static int move_freepages(struct zone *zone,
 		VM_BUG_ON_PAGE(page_zone(page) != zone, page);
 
 		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;
 	}
@@ -2393,7 +2426,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;
 
@@ -2464,8 +2496,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);
 }
 
 /*
@@ -3136,7 +3167,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;
@@ -3162,7 +3192,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
@@ -8605,7 +8635,7 @@ void zone_pcp_reset(struct zone *zone)
 		pr_info("remove from free list %lx %d %lx\n",
 			pfn, 1 << order, end_pfn);
 #endif
-		del_page_from_free_area(page, &zone->free_area[order]);
+		del_page_from_free_list(page, zone, order);
 		for (i = 0; i < (1 << order); i++)
 			SetPageReserved((page+i));
 		pfn += (1 << order);

[PATCH v11 3/6] mm: Introduce Reported pages

[Alexander Duyck]

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

In order to pave the way for free page reporting 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 Reported Buddy, which is essentially
meant to just be the Uptodate flag used in conjunction with the Buddy
page type.

It adds a set of pointers we shall call "reported_boundary" which
represent the upper boundary between the unreported and reported 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 verify that it went through the
reporting 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. Without this we would have to manually walk the
entire page list until we have find a page that hasn't been reported. In my
testing this adds as much as 18% additional overhead which would make this
unattractive as a solution.

One limitation to this approach is that it is essentially a linear search
and in the case of the free lists we can have pages added to either the
head or the tail of the list. In order to place limits on this we only
allow pages to be added before the reported_boundary instead of adding
to the tail itself. 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 reported pages
that were likely evicted from the guest memory.

Since we will only be reporting one zone at a time we keep the boundary
limited to being defined for just the zone we are currently reporting pages
from. 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 reporting and the boundaries are active.

We store the index of the boundary pointer used to track the reported page
in the page->index value. Doing this we can avoid unnecessary computation
to determine the index value again. There should be no issues with this as
the value is unused when the page is in the buddy allocator, and is reset
as soon as the page is removed from the free list.

Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
---
 include/linux/mmzone.h     |   16 ++++
 include/linux/page-flags.h |   11 +++
 mm/Kconfig                 |   11 +++
 mm/compaction.c            |    5 +
 mm/memory_hotplug.c        |    2 +
 mm/page_alloc.c            |   67 +++++++++++++++--
 mm/page_reporting.h        |  176 ++++++++++++++++++++++++++++++++++++++++++++
 7 files changed, 281 insertions(+), 7 deletions(-)
 create mode 100644 mm/page_reporting.h

diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index 270a7b493174..53922c30b8d8 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -463,6 +463,14 @@ struct zone {
 	seqlock_t		span_seqlock;
 #endif
 
+#ifdef CONFIG_PAGE_REPORTING
+	/*
+	 * Pointer to reported page tracking statistics array. The size of
+	 * the array is MAX_ORDER - PAGE_REPORTING_MIN_ORDER. NULL when
+	 * unused page reporting is not present.
+	 */
+	unsigned long		*reported_pages;
+#endif
 	int initialized;
 
 	/* Write-intensive fields used from the page allocator */
@@ -538,6 +546,14 @@ enum zone_flags {
 	ZONE_BOOSTED_WATERMARK,		/* zone recently boosted watermarks.
 					 * Cleared when kswapd is woken.
 					 */
+	ZONE_PAGE_REPORTING_ACTIVE,	/* zone enabled page reporting and is
+					 * activly flushing the data out of
+					 * higher order pages.
+					 */
+	ZONE_PAGE_REPORTING_REQUESTED,	/* zone enabled page reporting and has
+					 * requested flushing the data out of
+					 * higher order pages.
+					 */
 };
 
 static inline unsigned long zone_managed_pages(struct zone *zone)
diff --git a/include/linux/page-flags.h b/include/linux/page-flags.h
index f91cb8898ff0..759a3b3956f2 100644
--- a/include/linux/page-flags.h
+++ b/include/linux/page-flags.h
@@ -163,6 +163,9 @@ enum pageflags {
 
 	/* non-lru isolated movable page */
 	PG_isolated = PG_reclaim,
+
+	/* Buddy pages. Used to track which pages have been reported */
+	PG_reported = PG_uptodate,
 };
 
 #ifndef __GENERATING_BOUNDS_H
@@ -432,6 +435,14 @@ static inline bool set_hwpoison_free_buddy_page(struct page *page)
 #endif
 
 /*
+ * PageReported() is used to track reported free pages within the Buddy
+ * allocator. We can use the non-atomic version of the test and set
+ * operations as both should be shielded with the zone lock to prevent
+ * any possible races on the setting or clearing of the bit.
+ */
+__PAGEFLAG(Reported, reported, PF_NO_COMPOUND)
+
+/*
  * On an anonymous page mapped into a user virtual memory area,
  * page->mapping points to its anon_vma, not to a struct address_space;
  * with the PAGE_MAPPING_ANON bit set to distinguish it.  See rmap.h.
diff --git a/mm/Kconfig b/mm/Kconfig
index a5dae9a7eb51..0419b2a9be3e 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -237,6 +237,17 @@ config COMPACTION
           linux-mm@kvack.org.
 
 #
+# support for unused page reporting
+config PAGE_REPORTING
+	bool "Allow for reporting of unused pages"
+	def_bool n
+	help
+	  Unused page reporting allows for the incremental acquisition of
+	  unused pages from the buddy allocator for the purpose of reporting
+	  those pages to another entity, such as a hypervisor, so that the
+	  memory can be freed up for other uses.
+
+#
 # support for page migration
 #
 config MIGRATION
diff --git a/mm/compaction.c b/mm/compaction.c
index ce08b39d85d4..60e064330b3a 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -24,6 +24,7 @@
 #include <linux/page_owner.h>
 #include <linux/psi.h>
 #include "internal.h"
+#include "page_reporting.h"
 
 #ifdef CONFIG_COMPACTION
 static inline void count_compact_event(enum vm_event_item item)
@@ -1325,6 +1326,8 @@ static int next_search_order(struct compact_control *cc, int order)
 			continue;
 
 		spin_lock_irqsave(&cc->zone->lock, flags);
+		page_reporting_free_area_release(cc->zone, order,
+						 MIGRATE_MOVABLE);
 		freelist = &area->free_list[MIGRATE_MOVABLE];
 		list_for_each_entry_reverse(freepage, freelist, lru) {
 			unsigned long pfn;
@@ -1681,6 +1684,8 @@ static unsigned long fast_find_migrateblock(struct compact_control *cc)
 			continue;
 
 		spin_lock_irqsave(&cc->zone->lock, flags);
+		page_reporting_free_area_release(cc->zone, order,
+						 MIGRATE_MOVABLE);
 		freelist = &area->free_list[MIGRATE_MOVABLE];
 		list_for_each_entry(freepage, freelist, lru) {
 			unsigned long free_pfn;
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index 680b4b3e57d9..be9634819218 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -41,6 +41,7 @@
 
 #include "internal.h"
 #include "shuffle.h"
+#include "page_reporting.h"
 
 /*
  * online_page_callback contains pointer to current page onlining function.
@@ -1624,6 +1625,7 @@ static int __ref __offline_pages(unsigned long start_pfn,
 	if (!populated_zone(zone)) {
 		zone_pcp_reset(zone);
 		build_all_zonelists(NULL);
+		page_reporting_reset_zone(zone);
 	} else
 		zone_pcp_update(zone);
 
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 5e142047f730..c82c00ea1f5c 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -74,6 +74,7 @@
 #include <asm/div64.h>
 #include "internal.h"
 #include "shuffle.h"
+#include "page_reporting.h"
 
 /* prevent >1 _updater_ of zone percpu pageset ->high and ->batch fields */
 static DEFINE_MUTEX(pcp_batch_high_lock);
@@ -891,10 +892,15 @@ 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_unreported_tail(zone, order, migratetype);
 
-	list_add_tail(&page->lru, &area->free_list[migratetype]);
-	area->nr_free++;
+	/*
+	 * To prevent the unreported pages from slipping behind our iterator
+	 * we will force them to be inserted in front of it. By doing this
+	 * we should only need to make one pass through the freelist.
+	 */
+	list_add_tail(&page->lru, tail);
+	zone->free_area[order].nr_free++;
 }
 
 /* Used for pages which are on another list */
@@ -903,12 +909,20 @@ static inline void move_to_free_list(struct page *page, struct zone *zone,
 {
 	struct free_area *area = &zone->free_area[order];
 
+	/* Make certain the page isn't occupying the boundary */
+	if (page_is_reported(page))
+		__del_page_from_reported_list(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)
 {
+	/* remove page from reported list, and clear reported state */
+	if (page_is_reported(page))
+		del_page_from_reported_list(page, zone, order);
+
 	list_del(&page->lru);
 	__ClearPageBuddy(page);
 	set_page_private(page, 0);
@@ -972,7 +986,7 @@ static inline void del_page_from_free_list(struct page *page, 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 reported)
 {
 	struct capture_control *capc = task_capc(zone);
 	unsigned long uninitialized_var(buddy_pfn);
@@ -1048,7 +1062,9 @@ static inline void __free_one_page(struct page *page,
 done_merging:
 	set_page_order(page, order);
 
-	if (is_shuffle_order(order))
+	if (reported)
+		to_tail = true;
+	else if (is_shuffle_order(order))
 		to_tail = shuffle_pick_tail();
 	else
 		to_tail = buddy_merge_likely(pfn, buddy_pfn, page, order);
@@ -1367,7 +1383,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);
@@ -1383,7 +1399,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);
 }
 
@@ -2245,6 +2261,43 @@ struct page *__rmqueue_smallest(struct zone *zone, unsigned int order,
 	return NULL;
 }
 
+#ifdef CONFIG_PAGE_REPORTING
+struct list_head **reported_boundary __read_mostly;
+
+/**
+ * free_reported_page - Return a now-reported page back where we got it
+ * @page: Page that was reported
+ * @order: Order of the reported page
+ *
+ * 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
+ * reported.
+ */
+void free_reported_page(struct page *page, unsigned int order)
+{
+	struct zone *zone = page_zone(page);
+	unsigned long pfn;
+	unsigned int mt;
+
+	/* zone lock should be held when this function is called */
+	lockdep_assert_held(&zone->lock);
+
+	pfn = page_to_pfn(page);
+	mt = get_pfnblock_migratetype(page, pfn);
+	__free_one_page(page, pfn, zone, order, mt, true);
+
+	/*
+	 * If page was not comingled with another page we can consider
+	 * the result to be "reported" since part of the page hasn't been
+	 * modified, otherwise we would need to report on the new larger
+	 * page.
+	 */
+	if (PageBuddy(page) && page_order(page) == order)
+		add_page_to_reported_list(page, zone, order, mt);
+}
+#endif /* CONFIG_PAGE_REPORTING */
+
 /*
  * This array describes the order lists are fallen back to when
  * the free lists for the desirable migrate type are depleted
diff --git a/mm/page_reporting.h b/mm/page_reporting.h
new file mode 100644
index 000000000000..ee4d86daa089
--- /dev/null
+++ b/mm/page_reporting.h
@@ -0,0 +1,176 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _MM_PAGE_REPORTING_H
+#define _MM_PAGE_REPORTING_H
+
+#include <linux/mmzone.h>
+#include <linux/pageblock-flags.h>
+#include <linux/page-isolation.h>
+#include <linux/jump_label.h>
+#include <linux/slab.h>
+#include <asm/pgtable.h>
+
+#define PAGE_REPORTING_MIN_ORDER	pageblock_order
+
+#ifdef CONFIG_PAGE_REPORTING
+/* Reported page accessors, defined in page_alloc.c */
+void free_reported_page(struct page *page, unsigned int order);
+
+#define page_is_reported(_page)	unlikely(PageReported(_page))
+
+/* Free reported_pages and reset reported page tracking count to 0 */
+static inline void page_reporting_reset_zone(struct zone *zone)
+{
+	kfree(zone->reported_pages);
+	zone->reported_pages = NULL;
+}
+
+/* Boundary functions */
+static inline pgoff_t
+get_reporting_index(unsigned int order, unsigned int migratetype)
+{
+	/*
+	 * We will only ever be dealing with pages greater-than or equal to
+	 * PAGE_REPORTING_MIN_ORDER. Since that is the case we can avoid
+	 * allocating unused space by limiting our index range to only the
+	 * orders that are supported for page reporting.
+	 */
+	return (order - PAGE_REPORTING_MIN_ORDER) * MIGRATE_TYPES + migratetype;
+}
+
+extern struct list_head **reported_boundary __read_mostly;
+
+static inline void
+page_reporting_reset_boundary(struct zone *zone, unsigned int order, int mt)
+{
+	int index;
+
+	if (order < PAGE_REPORTING_MIN_ORDER)
+		return;
+	if (!test_bit(ZONE_PAGE_REPORTING_ACTIVE, &zone->flags))
+		return;
+
+	index = get_reporting_index(order, mt);
+	reported_boundary[index] = &zone->free_area[order].free_list[mt];
+}
+
+static inline void page_reporting_disable_boundaries(struct zone *zone)
+{
+	/* zone lock should be held when this function is called */
+	lockdep_assert_held(&zone->lock);
+
+	__clear_bit(ZONE_PAGE_REPORTING_ACTIVE, &zone->flags);
+}
+
+static inline void
+page_reporting_free_area_release(struct zone *zone, unsigned int order, int mt)
+{
+	page_reporting_reset_boundary(zone, order, mt);
+}
+
+/*
+ * Method for obtaining the tail of the free list. Using this allows for
+ * tail insertions of unreported pages into the region that is currently
+ * being scanned so as to avoid interleaving reported and unreported pages.
+ */
+static inline struct list_head *
+get_unreported_tail(struct zone *zone, unsigned int order, int migratetype)
+{
+	if (order >= PAGE_REPORTING_MIN_ORDER &&
+	    test_bit(ZONE_PAGE_REPORTING_ACTIVE, &zone->flags))
+		return reported_boundary[get_reporting_index(order,
+							     migratetype)];
+
+	return &zone->free_area[order].free_list[migratetype];
+}
+
+/*
+ * Functions for adding/removing reported pages to the freelist.
+ * All of them expect the zone lock to be held to maintain
+ * consistency of the reported list as a subset of the free list.
+ */
+static inline void
+add_page_to_reported_list(struct page *page, struct zone *zone,
+			  unsigned int order, unsigned int mt)
+{
+	/*
+	 * Default to using index 0, this will be updated later if the zone
+	 * is still being processed.
+	 */
+	page->index = 0;
+
+	/* flag page as reported */
+	__SetPageReported(page);
+
+	/* update areated page accounting */
+	zone->reported_pages[order - PAGE_REPORTING_MIN_ORDER]++;
+}
+
+static inline void page_reporting_pull_boundary(struct page *page)
+{
+	struct list_head **tail = &reported_boundary[page->index];
+
+	if (*tail == &page->lru)
+		*tail = page->lru.next;
+}
+
+static inline void
+__del_page_from_reported_list(struct page *page, struct zone *zone)
+{
+	/*
+	 * Since the page is being pulled from the list we need to update
+	 * the boundary, after that we can just update the index so that
+	 * the correct boundary will be checked in the future.
+	 */
+	if (test_bit(ZONE_PAGE_REPORTING_ACTIVE, &zone->flags))
+		page_reporting_pull_boundary(page);
+}
+
+static inline void
+del_page_from_reported_list(struct page *page, struct zone *zone,
+			    unsigned int order)
+{
+	__del_page_from_reported_list(page, zone);
+
+	/* page_private will contain the page order, so just use it directly */
+	zone->reported_pages[order - PAGE_REPORTING_MIN_ORDER]--;
+
+	/* clear the flag so we can report on it when it returns */
+	__ClearPageReported(page);
+}
+
+#else /* CONFIG_PAGE_REPORTING */
+#define page_is_reported(_page)	false
+
+static inline void page_reporting_reset_zone(struct zone *zone)
+{
+}
+
+static inline void
+page_reporting_free_area_release(struct zone *zone, unsigned int order, int mt)
+{
+}
+
+static inline struct list_head *
+get_unreported_tail(struct zone *zone, unsigned int order, int migratetype)
+{
+	return &zone->free_area[order].free_list[migratetype];
+}
+
+static inline void
+add_page_to_reported_list(struct page *page, struct zone *zone,
+			  int order, int migratetype)
+{
+}
+
+static inline void
+__del_page_from_reported_list(struct page *page, struct zone *zone)
+{
+}
+
+static inline void
+del_page_from_reported_list(struct page *page, struct zone *zone,
+			    unsigned int order)
+{
+}
+#endif /* CONFIG_PAGE_REPORTING */
+#endif /*_MM_PAGE_REPORTING_H */

[PATCH v11 4/6] mm: Add device side and notifier for unused page reporting

[Alexander Duyck]

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

With this patch we are adding the pieces needed to enable the reporting of
pages to a specific device. That device needs to register a page reporting
device that can be used to handle notifications that that pages are unused.

Registering the device will in turn enable the notifications and allow page
reporting to be active. When the the device is unregistered it will disable
page reporting notifications. For now we only allow one page reporting
device to be registered at a time.

The determination of when to start reporting is based on the tracking of
the number of free pages in a given area versus the number of reported
pages in that area. We keep track of the number of reported 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.

Once reporting has started get_unreported_pages will use the
reported_boundary pointers to track where it should resume processing the
free lists. It will go through and either set the index if it finds a
reported page, or it will attempt to isolate the page so that it can be
reported.

Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
---
 include/linux/page_reporting.h |   31 ++++
 mm/Makefile                    |    1 
 mm/page_alloc.c                |   10 +
 mm/page_reporting.c            |  350 ++++++++++++++++++++++++++++++++++++++++
 mm/page_reporting.h            |   49 ++++++
 5 files changed, 439 insertions(+), 2 deletions(-)
 create mode 100644 include/linux/page_reporting.h
 create mode 100644 mm/page_reporting.c

diff --git a/include/linux/page_reporting.h b/include/linux/page_reporting.h
new file mode 100644
index 000000000000..155006fc9911
--- /dev/null
+++ b/include/linux/page_reporting.h
@@ -0,0 +1,31 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _LINUX_PAGE_REPORTING_H
+#define _LINUX_PAGE_REPORTING_H
+
+#include <linux/mmzone.h>
+
+struct page_reporting_dev_info {
+	/* function that alters pages to make them "reported" */
+	void (*report)(struct page_reporting_dev_info *phdev,
+		       unsigned int nents);
+
+	/* scatterlist containing pages to be processed */
+	struct scatterlist *sg;
+
+	/*
+	 * Upper limit on the number of pages that the report function
+	 * expects to be placed into the scatterlist to be processed.
+	 */
+	unsigned long capacity;
+
+	/* work struct for processing reports */
+	struct delayed_work work;
+
+	/* The number of zones requesting reporting */
+	atomic_t refcnt;
+};
+
+/* Tear-down and bring-up for page reporting devices */
+void page_reporting_unregister(struct page_reporting_dev_info *phdev);
+int page_reporting_register(struct page_reporting_dev_info *phdev);
+#endif /*_LINUX_PAGE_REPORTING_H */
diff --git a/mm/Makefile b/mm/Makefile
index d996846697ef..fc4fa17b6c83 100644
--- a/mm/Makefile
+++ b/mm/Makefile
@@ -107,3 +107,4 @@ obj-$(CONFIG_PERCPU_STATS) += percpu-stats.o
 obj-$(CONFIG_ZONE_DEVICE) += memremap.o
 obj-$(CONFIG_HMM_MIRROR) += hmm.o
 obj-$(CONFIG_MEMFD_CREATE) += memfd.o
+obj-$(CONFIG_PAGE_REPORTING) += page_reporting.o
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index c82c00ea1f5c..c3dc03d3095a 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -1073,6 +1073,14 @@ static inline void __free_one_page(struct page *page,
 		add_to_free_list_tail(page, zone, order, migratetype);
 	else
 		add_to_free_list(page, zone, order, migratetype);
+
+	/*
+	 * No need to notify on a reported page as the total count of
+	 * unreported pages will not have increased since we have essentially
+	 * merged the reported page with one or more unreported pages.
+	 */
+	if (!reported)
+		page_reporting_notify_free(zone, order);
 }
 
 /*
@@ -2262,8 +2270,6 @@ struct page *__rmqueue_smallest(struct zone *zone, unsigned int order,
 }
 
 #ifdef CONFIG_PAGE_REPORTING
-struct list_head **reported_boundary __read_mostly;
-
 /**
  * free_reported_page - Return a now-reported page back where we got it
  * @page: Page that was reported
diff --git a/mm/page_reporting.c b/mm/page_reporting.c
new file mode 100644
index 000000000000..b7c9ed9289c2
--- /dev/null
+++ b/mm/page_reporting.c
@@ -0,0 +1,350 @@
+// SPDX-License-Identifier: GPL-2.0
+#include <linux/mm.h>
+#include <linux/mmzone.h>
+#include <linux/page_reporting.h>
+#include <linux/gfp.h>
+#include <linux/export.h>
+#include <linux/delay.h>
+#include <linux/scatterlist.h>
+
+#include "page_reporting.h"
+#include "internal.h"
+
+static struct page_reporting_dev_info __rcu *ph_dev_info __read_mostly;
+struct list_head **reported_boundary __read_mostly;
+
+#define for_each_reporting_migratetype_order(_order, _type) \
+	for (_order = MAX_ORDER; _order-- != PAGE_REPORTING_MIN_ORDER;) \
+		for (_type = MIGRATE_TYPES; _type--;) \
+			if (!is_migrate_isolate(_type))
+
+static void page_reporting_populate_metadata(struct zone *zone)
+{
+	size_t size;
+	int node;
+
+	/*
+	 * We need to make sure we have somewhere to store the tracking
+	 * data for how many reported pages are in the zone. To do that
+	 * we need to make certain zone->reported_pages is populated.
+	 */
+	if (zone->reported_pages)
+		return;
+
+	node = zone_to_nid(zone);
+	size = (MAX_ORDER - PAGE_REPORTING_MIN_ORDER) * sizeof(unsigned long);
+	zone->reported_pages = kzalloc_node(size, GFP_KERNEL, node);
+}
+
+static void page_reporting_reset_all_boundaries(struct zone *zone)
+{
+	unsigned int order, mt;
+
+	/* Update boundary data to reflect the zone we are currently working */
+	for_each_reporting_migratetype_order(order, mt)
+		page_reporting_reset_boundary(zone, order, mt);
+}
+
+static struct page *
+get_unreported_page(struct zone *zone, unsigned int order, int mt)
+{
+	struct list_head *list = &zone->free_area[order].free_list[mt];
+	struct list_head *tail = get_unreported_tail(zone, order, mt);
+	unsigned long index = get_reporting_index(order, mt);
+	struct page *page;
+
+	/* 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 */
+
+		/*
+		 * We are going to skip over the reported pages. Make
+		 * certain that the index of those pages are correct
+		 * as we will later be moving the boundary into place
+		 * above them.
+		 */
+		if (PageReported(page)) {
+			page->index = index;
+			tail = &page->lru;
+			continue;
+		}
+
+		/* Drop reference to page if isolate fails */
+		if (__isolate_free_page(page, order))
+			goto out;
+
+		break;
+	}
+
+	page = NULL;
+out:
+	/* Update the boundary */
+	reported_boundary[index] = tail;
+
+	return page;
+}
+
+static void
+__page_reporting_cancel(struct zone *zone,
+			struct page_reporting_dev_info *phdev)
+{
+	/* processing of the zone is complete, we can disable boundaries */
+	page_reporting_disable_boundaries(zone);
+
+	/*
+	 * 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_REPORTING_REQUESTED, &zone->flags);
+	atomic_dec(&phdev->refcnt);
+}
+
+static unsigned int
+page_reporting_fill(struct zone *zone, struct page_reporting_dev_info *phdev)
+{
+	struct scatterlist *sg = phdev->sg;
+	unsigned int order, mt, count = 0;
+
+	sg_init_table(phdev->sg, phdev->capacity);
+
+	/* Make sure the boundaries are enabled */
+	if (!__test_and_set_bit(ZONE_PAGE_REPORTING_ACTIVE, &zone->flags))
+		page_reporting_reset_all_boundaries(zone);
+
+	for_each_reporting_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_unreported_page(zone, order, mt))) {
+			sg_set_page(&sg[count], page, PAGE_SIZE << order, 0);
+
+			if (++count == phdev->capacity)
+				return phdev->capacity;
+		}
+	}
+
+	/* mark end of scatterlist due to underflow */
+	if (count)
+		sg_mark_end(&sg[count - 1]);
+
+	/* We ran out of pages so we can stop now */
+	__page_reporting_cancel(zone, phdev);
+
+	return count;
+}
+
+static void page_reporting_drain(struct page_reporting_dev_info *phdev)
+{
+	struct scatterlist *sg = phdev->sg;
+
+	/*
+	 * Drain the now reported pages back into their respective
+	 * free lists/areas. We assume at least one page is populated.
+	 */
+	do {
+		free_reported_page(sg_page(sg), get_order(sg->length));
+	} while (!sg_is_last(sg++));
+}
+
+/*
+ * The page reporting cycle consists of 4 stages, fill, report, 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_reporting_cycle(struct zone *zone, struct page_reporting_dev_info *phdev)
+{
+	/*
+	 * Guarantee boundaries and stats are populated before we
+	 * start placing reported pages in the zone.
+	 */
+	page_reporting_populate_metadata(zone);
+
+	spin_lock_irq(&zone->lock);
+
+	/* Cancel the request if we failed to populate zone metadata */
+	if (!zone->reported_pages) {
+		__page_reporting_cancel(zone, phdev);
+		goto zone_not_ready;
+	}
+
+	do {
+		/* Pull pages out of allocator into a scaterlist */
+		unsigned int nents = page_reporting_fill(zone, phdev);
+
+		/* no pages were acquired, give up */
+		if (!nents)
+			break;
+
+		spin_unlock_irq(&zone->lock);
+
+		/* begin processing pages in local list */
+		phdev->report(phdev, nents);
+
+		spin_lock_irq(&zone->lock);
+
+		/*
+		 * We should have a scatterlist of pages that have been
+		 * processed. Return them to their original free lists.
+		 */
+		page_reporting_drain(phdev);
+
+		/* keep pulling pages till there are none to pull */
+	} while (test_bit(ZONE_PAGE_REPORTING_REQUESTED, &zone->flags));
+zone_not_ready:
+	spin_unlock_irq(&zone->lock);
+}
+
+static void page_reporting_process(struct work_struct *work)
+{
+	struct delayed_work *d_work = to_delayed_work(work);
+	struct page_reporting_dev_info *phdev =
+		container_of(d_work, struct page_reporting_dev_info, work);
+	struct zone *zone = first_online_pgdat()->node_zones;
+
+	do {
+		if (test_bit(ZONE_PAGE_REPORTING_REQUESTED, &zone->flags))
+			page_reporting_cycle(zone, phdev);
+
+		/* Move to next zone, if at end of list start over */
+		zone = next_zone(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 reporting on this zone */
+void __page_reporting_request(struct zone *zone)
+{
+	struct page_reporting_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))
+		goto out;
+
+	/*
+	 * 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_REPORTING_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);
+out:
+	rcu_read_unlock();
+}
+
+static DEFINE_MUTEX(page_reporting_mutex);
+DEFINE_STATIC_KEY_FALSE(page_reporting_notify_enabled);
+
+void page_reporting_unregister(struct page_reporting_dev_info *phdev)
+{
+	mutex_lock(&page_reporting_mutex);
+
+	if (rcu_access_pointer(ph_dev_info) == phdev) {
+		/* Disable page reporting notification */
+		static_branch_disable(&page_reporting_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;
+
+		/* Free boundaries */
+		kfree(reported_boundary);
+		reported_boundary = NULL;
+	}
+
+	mutex_unlock(&page_reporting_mutex);
+}
+EXPORT_SYMBOL_GPL(page_reporting_unregister);
+
+int page_reporting_register(struct page_reporting_dev_info *phdev)
+{
+	struct zone *zone;
+	int err = 0;
+
+	/* No point in enabling this if it cannot handle any pages */
+	if (WARN_ON(!phdev->capacity || phdev->capacity > PAGE_REPORTING_HWM))
+		return -EINVAL;
+
+	mutex_lock(&page_reporting_mutex);
+
+	/* nothing to do if already in use */
+	if (rcu_access_pointer(ph_dev_info)) {
+		err = -EBUSY;
+		goto err_out;
+	}
+
+	/*
+	 * Allocate space to store the boundaries for the zone we are
+	 * actively reporting on. We will need to store one boundary
+	 * pointer per migratetype, and then we need to have one of these
+	 * arrays per order for orders greater than or equal to
+	 * PAGE_REPORTING_MIN_ORDER.
+	 */
+	reported_boundary = kcalloc(get_reporting_index(MAX_ORDER, 0),
+				    sizeof(struct list_head *), GFP_KERNEL);
+	if (!reported_boundary) {
+		err = -ENOMEM;
+		goto err_out;
+	}
+
+	/* allocate scatterlist to store pages being reported on */
+	phdev->sg = kcalloc(phdev->capacity, sizeof(*phdev->sg), GFP_KERNEL);
+	if (!phdev->sg) {
+		err = -ENOMEM;
+
+		kfree(reported_boundary);
+		reported_boundary = NULL;
+
+		goto err_out;
+	}
+
+
+	/* initialize refcnt and work structures */
+	atomic_set(&phdev->refcnt, 0);
+	INIT_DELAYED_WORK(&phdev->work, &page_reporting_process);
+
+	/* assign device, and begin initial flush of populated zones */
+	rcu_assign_pointer(ph_dev_info, phdev);
+	for_each_populated_zone(zone) {
+		spin_lock_irq(&zone->lock);
+		__page_reporting_request(zone);
+		spin_unlock_irq(&zone->lock);
+	}
+
+	/* enable page reporting notification */
+	static_branch_enable(&page_reporting_notify_enabled);
+err_out:
+	mutex_unlock(&page_reporting_mutex);
+
+	return err;
+}
+EXPORT_SYMBOL_GPL(page_reporting_register);
diff --git a/mm/page_reporting.h b/mm/page_reporting.h
index ee4d86daa089..7aaa1d9a42e8 100644
--- a/mm/page_reporting.h
+++ b/mm/page_reporting.h
@@ -10,6 +10,7 @@
 #include <asm/pgtable.h>
 
 #define PAGE_REPORTING_MIN_ORDER	pageblock_order
+#define PAGE_REPORTING_HWM		32
 
 #ifdef CONFIG_PAGE_REPORTING
 /* Reported page accessors, defined in page_alloc.c */
@@ -24,6 +25,50 @@ static inline void page_reporting_reset_zone(struct zone *zone)
 	zone->reported_pages = NULL;
 }
 
+DECLARE_STATIC_KEY_FALSE(page_reporting_notify_enabled);
+void __page_reporting_request(struct zone *zone);
+
+/**
+ * page_reporting_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_reporting_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_reporting_notify_free(struct zone *zone, int order)
+{
+	unsigned long next_report = PAGE_REPORTING_HWM;
+	int report_order;
+
+	/* Called from hot path in __free_one_page() */
+	if (!static_branch_unlikely(&page_reporting_notify_enabled))
+		return;
+
+	/* Limit notifications only to higher order pages */
+	report_order = order - PAGE_REPORTING_MIN_ORDER;
+	if (report_order < 0)
+		return;
+
+	/* Do not bother with tests if we have already requested reporting */
+	if (test_bit(ZONE_PAGE_REPORTING_REQUESTED, &zone->flags))
+		return;
+
+	/* Add reported_pages count if it is present */
+	if (zone->reported_pages)
+		next_report += zone->reported_pages[report_order];
+
+	/* Determine if we have crossed reporting threshold */
+	if (zone->free_area[order].nr_free < next_report)
+		return;
+
+	/* This is slow, but should be called very rarely */
+	__page_reporting_request(zone);
+}
+
 /* Boundary functions */
 static inline pgoff_t
 get_reporting_index(unsigned int order, unsigned int migratetype)
@@ -145,6 +190,10 @@ static inline void page_reporting_reset_zone(struct zone *zone)
 {
 }
 
+static inline void page_reporting_notify_free(struct zone *zone, int order)
+{
+}
+
 static inline void
 page_reporting_free_area_release(struct zone *zone, unsigned int order, int mt)
 {

[PATCH v11 5/6] virtio-balloon: Pull page poisoning config out of free page hinting

[Alexander Duyck]

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

Currently the page poisoning setting wasn't being enabled unless free page
hinting was enabled. However we will need the page poisoning tracking logic
as well for unused page reporting. As such pull it out and make it a
separate bit of config in the probe function.

In addition we need to add support for the more recent init_on_free feature
which expects a behavior similar to page poisoning in that we expect the
page to be pre-zeroed.

Reviewed-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
---
 drivers/virtio/virtio_balloon.c |   23 +++++++++++++++++------
 1 file changed, 17 insertions(+), 6 deletions(-)

diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
index 226fbb995fb0..92099298bc16 100644
--- a/drivers/virtio/virtio_balloon.c
+++ b/drivers/virtio/virtio_balloon.c
@@ -842,7 +842,6 @@ static int virtio_balloon_register_shrinker(struct virtio_balloon *vb)
 static int virtballoon_probe(struct virtio_device *vdev)
 {
 	struct virtio_balloon *vb;
-	__u32 poison_val;
 	int err;
 
 	if (!vdev->config->get) {
@@ -909,11 +908,20 @@ static int virtballoon_probe(struct virtio_device *vdev)
 						  VIRTIO_BALLOON_CMD_ID_STOP);
 		spin_lock_init(&vb->free_page_list_lock);
 		INIT_LIST_HEAD(&vb->free_page_list);
-		if (virtio_has_feature(vdev, VIRTIO_BALLOON_F_PAGE_POISON)) {
+	}
+	if (virtio_has_feature(vdev, VIRTIO_BALLOON_F_PAGE_POISON)) {
+		/* Start with poison val of 0 representing general init */
+		__u32 poison_val = 0;
+
+		/*
+		 * Let the hypervisor know that we are expecting a
+		 * specific value to be written back in unused pages.
+		 */
+		if (!want_init_on_free())
 			memset(&poison_val, PAGE_POISON, sizeof(poison_val));
-			virtio_cwrite(vb->vdev, struct virtio_balloon_config,
-				      poison_val, &poison_val);
-		}
+
+		virtio_cwrite(vb->vdev, struct virtio_balloon_config,
+			      poison_val, &poison_val);
 	}
 	/*
 	 * We continue to use VIRTIO_BALLOON_F_DEFLATE_ON_OOM to decide if a
@@ -1014,7 +1022,10 @@ static int virtballoon_restore(struct virtio_device *vdev)
 
 static int virtballoon_validate(struct virtio_device *vdev)
 {
-	if (!page_poisoning_enabled())
+	/* Tell the host whether we care about poisoned pages. */
+	if (!want_init_on_free() &&
+	    (IS_ENABLED(CONFIG_PAGE_POISONING_NO_SANITY) ||
+	     !page_poisoning_enabled()))
 		__virtio_clear_bit(vdev, VIRTIO_BALLOON_F_PAGE_POISON);
 
 	__virtio_clear_bit(vdev, VIRTIO_F_IOMMU_PLATFORM);

[PATCH v11 6/6] virtio-balloon: Add support for providing unused page reports to host

[Alexander Duyck]

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

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

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

diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig
index 078615cf2afc..4b2dd8259ff5 100644
--- a/drivers/virtio/Kconfig
+++ b/drivers/virtio/Kconfig
@@ -58,6 +58,7 @@ config VIRTIO_BALLOON
 	tristate "Virtio balloon driver"
 	depends on VIRTIO
 	select MEMORY_BALLOON
+	select PAGE_REPORTING
 	---help---
 	 This driver supports increasing and decreasing the amount
 	 of memory within a KVM guest.
diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
index 92099298bc16..b56ca35482bc 100644
--- a/drivers/virtio/virtio_balloon.c
+++ b/drivers/virtio/virtio_balloon.c
@@ -19,6 +19,7 @@
 #include <linux/mount.h>
 #include <linux/magic.h>
 #include <linux/pseudo_fs.h>
+#include <linux/page_reporting.h>
 
 /*
  * Balloon device works in 4K page units.  So each page is pointed to by
@@ -37,6 +38,9 @@
 #define VIRTIO_BALLOON_FREE_PAGE_SIZE \
 	(1 << (VIRTIO_BALLOON_FREE_PAGE_ORDER + PAGE_SHIFT))
 
+/*  limit on the number of pages that can be on the reporting vq */
+#define VIRTIO_BALLOON_VRING_HINTS_MAX	16
+
 #ifdef CONFIG_BALLOON_COMPACTION
 static struct vfsmount *balloon_mnt;
 #endif
@@ -46,6 +50,7 @@ enum virtio_balloon_vq {
 	VIRTIO_BALLOON_VQ_DEFLATE,
 	VIRTIO_BALLOON_VQ_STATS,
 	VIRTIO_BALLOON_VQ_FREE_PAGE,
+	VIRTIO_BALLOON_VQ_REPORTING,
 	VIRTIO_BALLOON_VQ_MAX
 };
 
@@ -113,6 +118,10 @@ struct virtio_balloon {
 
 	/* To register a shrinker to shrink memory upon memory pressure */
 	struct shrinker shrinker;
+
+	/* Unused page reporting device */
+	struct virtqueue *reporting_vq;
+	struct page_reporting_dev_info ph_dev_info;
 };
 
 static struct virtio_device_id id_table[] = {
@@ -152,6 +161,32 @@ static void tell_host(struct virtio_balloon *vb, struct virtqueue *vq)
 
 }
 
+void virtballoon_unused_page_report(struct page_reporting_dev_info *ph_dev_info,
+				    unsigned int nents)
+{
+	struct virtio_balloon *vb =
+		container_of(ph_dev_info, struct virtio_balloon, ph_dev_info);
+	struct virtqueue *vq = vb->reporting_vq;
+	unsigned int unused, err;
+
+	/* We should always be able to add these buffers to an empty queue. */
+	err = virtqueue_add_inbuf(vq, ph_dev_info->sg, nents, vb,
+				  GFP_NOWAIT | __GFP_NOWARN);
+
+	/*
+	 * In the extremely unlikely case that something has changed and we
+	 * are able to trigger an error we will simply display a warning
+	 * and exit without actually processing the pages.
+	 */
+	if (WARN_ON(err))
+		return;
+
+	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 +511,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_REPORTING] = NULL;
 
 	if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_STATS_VQ)) {
 		names[VIRTIO_BALLOON_VQ_STATS] = "stats";
@@ -487,11 +523,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_REPORTING)) {
+		names[VIRTIO_BALLOON_VQ_REPORTING] = "reporting_vq";
+		callbacks[VIRTIO_BALLOON_VQ_REPORTING] = 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_REPORTING))
+		vb->reporting_vq = vqs[VIRTIO_BALLOON_VQ_REPORTING];
+
 	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)) {
@@ -932,12 +976,30 @@ static int virtballoon_probe(struct virtio_device *vdev)
 		if (err)
 			goto out_del_balloon_wq;
 	}
+
+	vb->ph_dev_info.report = virtballoon_unused_page_report;
+	if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_REPORTING)) {
+		unsigned int capacity;
+
+		capacity = min_t(unsigned int,
+				 virtqueue_get_vring_size(vb->reporting_vq),
+				 VIRTIO_BALLOON_VRING_HINTS_MAX);
+		vb->ph_dev_info.capacity = capacity;
+
+		err = page_reporting_register(&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);
@@ -966,6 +1028,8 @@ static void virtballoon_remove(struct virtio_device *vdev)
 {
 	struct virtio_balloon *vb = vdev->priv;
 
+	if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_REPORTING))
+		page_reporting_unregister(&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);
@@ -1038,6 +1102,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_REPORTING,
 };
 
 static struct virtio_driver virtio_balloon_driver = {
diff --git a/include/uapi/linux/virtio_balloon.h b/include/uapi/linux/virtio_balloon.h
index a1966cd7b677..19974392d324 100644
--- a/include/uapi/linux/virtio_balloon.h
+++ b/include/uapi/linux/virtio_balloon.h
@@ -36,6 +36,7 @@
 #define VIRTIO_BALLOON_F_DEFLATE_ON_OOM	2 /* Deflate balloon on OOM */
 #define VIRTIO_BALLOON_F_FREE_PAGE_HINT	3 /* VQ to report free pages */
 #define VIRTIO_BALLOON_F_PAGE_POISON	4 /* Guest is using page poisoning */
+#define VIRTIO_BALLOON_F_REPORTING	5 /* Page reporting virtqueue */
 
 /* Size of a PFN in the balloon interface. */
 #define VIRTIO_BALLOON_PFN_SHIFT 12

[PATCH v11 QEMU 1/3] virtio-ballon: Implement support for page poison tracking feature

[Alexander Duyck]

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

We need to make certain to advertise support for page poison tracking if
we want to actually get data on if the guest will be poisoning pages. So
if free page hinting is active we should add page poisoning support and
let the guest disable it if it isn't using it.

Page poisoning will result in a page being dirtied on free. As such we
cannot really avoid having to copy the page at least one more time since
we will need to write the poison value to the destination. As such we can
just ignore free page hinting if page poisoning is enabled as it will
actually reduce the work we have to do.

Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
---
 hw/virtio/virtio-balloon.c         |   25 +++++++++++++++++++++----
 include/hw/virtio/virtio-balloon.h |    1 +
 2 files changed, 22 insertions(+), 4 deletions(-)

diff --git a/hw/virtio/virtio-balloon.c b/hw/virtio/virtio-balloon.c
index 40b04f518028..6ecfec422309 100644
--- a/hw/virtio/virtio-balloon.c
+++ b/hw/virtio/virtio-balloon.c
@@ -531,6 +531,15 @@ static void virtio_balloon_free_page_start(VirtIOBalloon *s)
         return;
     }
 
+    /*
+     * If page poisoning is enabled then we probably shouldn't bother with
+     * the hinting since the poisoning will dirty the page and invalidate
+     * the work we are doing anyway.
+     */
+    if (virtio_vdev_has_feature(vdev, VIRTIO_BALLOON_F_PAGE_POISON)) {
+        return;
+    }
+
     if (s->free_page_report_cmd_id == UINT_MAX) {
         s->free_page_report_cmd_id =
                        VIRTIO_BALLOON_FREE_PAGE_REPORT_CMD_ID_MIN;
@@ -618,12 +627,10 @@ static size_t virtio_balloon_config_size(VirtIOBalloon *s)
     if (s->qemu_4_0_config_size) {
         return sizeof(struct virtio_balloon_config);
     }
-    if (virtio_has_feature(features, VIRTIO_BALLOON_F_PAGE_POISON)) {
+    if (virtio_has_feature(features, VIRTIO_BALLOON_F_PAGE_POISON) ||
+        virtio_has_feature(features, VIRTIO_BALLOON_F_FREE_PAGE_HINT)) {
         return sizeof(struct virtio_balloon_config);
     }
-    if (virtio_has_feature(features, VIRTIO_BALLOON_F_FREE_PAGE_HINT)) {
-        return offsetof(struct virtio_balloon_config, poison_val);
-    }
     return offsetof(struct virtio_balloon_config, free_page_report_cmd_id);
 }
 
@@ -634,6 +641,7 @@ static void virtio_balloon_get_config(VirtIODevice *vdev, uint8_t *config_data)
 
     config.num_pages = cpu_to_le32(dev->num_pages);
     config.actual = cpu_to_le32(dev->actual);
+    config.poison_val = cpu_to_le32(dev->poison_val);
 
     if (dev->free_page_report_status == FREE_PAGE_REPORT_S_REQUESTED) {
         config.free_page_report_cmd_id =
@@ -697,6 +705,8 @@ static void virtio_balloon_set_config(VirtIODevice *vdev,
         qapi_event_send_balloon_change(vm_ram_size -
                         ((ram_addr_t) dev->actual << VIRTIO_BALLOON_PFN_SHIFT));
     }
+    dev->poison_val = virtio_vdev_has_feature(vdev, VIRTIO_BALLOON_F_PAGE_POISON) ? 
+                      le32_to_cpu(config.poison_val) : 0;
     trace_virtio_balloon_set_config(dev->actual, oldactual);
 }
 
@@ -706,6 +716,9 @@ static uint64_t virtio_balloon_get_features(VirtIODevice *vdev, uint64_t f,
     VirtIOBalloon *dev = VIRTIO_BALLOON(vdev);
     f |= dev->host_features;
     virtio_add_feature(&f, VIRTIO_BALLOON_F_STATS_VQ);
+    if (virtio_has_feature(f, VIRTIO_BALLOON_F_FREE_PAGE_HINT)) {
+        virtio_add_feature(&f, VIRTIO_BALLOON_F_PAGE_POISON);
+    }
 
     return f;
 }
@@ -847,6 +860,8 @@ static void virtio_balloon_device_reset(VirtIODevice *vdev)
         g_free(s->stats_vq_elem);
         s->stats_vq_elem = NULL;
     }
+
+    s->poison_val = 0;
 }
 
 static void virtio_balloon_set_status(VirtIODevice *vdev, uint8_t status)
@@ -909,6 +924,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("x-page-poison", VirtIOBalloon, host_features,
+                    VIRTIO_BALLOON_F_PAGE_POISON, false),
     /* QEMU 4.0 accidentally changed the config size even when free-page-hint
      * is disabled, resulting in QEMU 3.1 migration incompatibility.  This
      * property retains this quirk for QEMU 4.1 machine types.
diff --git a/include/hw/virtio/virtio-balloon.h b/include/hw/virtio/virtio-balloon.h
index d1c968d2376e..7fe78e5c14d7 100644
--- a/include/hw/virtio/virtio-balloon.h
+++ b/include/hw/virtio/virtio-balloon.h
@@ -70,6 +70,7 @@ typedef struct VirtIOBalloon {
     uint32_t host_features;
 
     bool qemu_4_0_config_size;
+    uint32_t poison_val;
 } VirtIOBalloon;
 
 #endif

[PATCH v11 QEMU 2/3] virtio-balloon: Add bit to notify guest of unused page reporting

[Alexander Duyck]

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

Add a bit for the page reporting feature provided by virtio-balloon.

This patch should be replaced once the feature is added to the Linux kernel
and the bit is backported into this exported kernel header.

Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
---
 include/standard-headers/linux/virtio_balloon.h |    1 +
 1 file changed, 1 insertion(+)

diff --git a/include/standard-headers/linux/virtio_balloon.h b/include/standard-headers/linux/virtio_balloon.h
index 9375ca2a70de..1c5f6d6f2de6 100644
--- a/include/standard-headers/linux/virtio_balloon.h
+++ b/include/standard-headers/linux/virtio_balloon.h
@@ -36,6 +36,7 @@
 #define VIRTIO_BALLOON_F_DEFLATE_ON_OOM	2 /* Deflate balloon on OOM */
 #define VIRTIO_BALLOON_F_FREE_PAGE_HINT	3 /* VQ to report free pages */
 #define VIRTIO_BALLOON_F_PAGE_POISON	4 /* Guest is using page poisoning */
+#define VIRTIO_BALLOON_F_REPORTING	5 /* Page reporting virtqueue */
 
 /* Size of a PFN in the balloon interface. */
 #define VIRTIO_BALLOON_PFN_SHIFT 12

[PATCH v11 QEMU 3/3] virtio-balloon: Provide a interface for unused page reporting

[Alexander Duyck]

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

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

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

Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
---
 hw/virtio/virtio-balloon.c         |   46 ++++++++++++++++++++++++++++++++++--
 include/hw/virtio/virtio-balloon.h |    2 +-
 2 files changed, 45 insertions(+), 3 deletions(-)

diff --git a/hw/virtio/virtio-balloon.c b/hw/virtio/virtio-balloon.c
index 6ecfec422309..47f253d016db 100644
--- a/hw/virtio/virtio-balloon.c
+++ b/hw/virtio/virtio-balloon.c
@@ -321,6 +321,40 @@ static void balloon_stats_set_poll_interval(Object *obj, Visitor *v,
     balloon_stats_change_timer(s, 0);
 }
 
+static void virtio_balloon_handle_report(VirtIODevice *vdev, VirtQueue *vq)
+{
+    VirtIOBalloon *dev = VIRTIO_BALLOON(vdev);
+    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() || dev->poison_val)
+                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);
@@ -628,7 +662,8 @@ static size_t virtio_balloon_config_size(VirtIOBalloon *s)
         return sizeof(struct virtio_balloon_config);
     }
     if (virtio_has_feature(features, VIRTIO_BALLOON_F_PAGE_POISON) ||
-        virtio_has_feature(features, VIRTIO_BALLOON_F_FREE_PAGE_HINT)) {
+        virtio_has_feature(features, VIRTIO_BALLOON_F_FREE_PAGE_HINT) ||
+        virtio_has_feature(features, VIRTIO_BALLOON_F_REPORTING)) {
         return sizeof(struct virtio_balloon_config);
     }
     return offsetof(struct virtio_balloon_config, free_page_report_cmd_id);
@@ -716,7 +751,8 @@ static uint64_t virtio_balloon_get_features(VirtIODevice *vdev, uint64_t f,
     VirtIOBalloon *dev = VIRTIO_BALLOON(vdev);
     f |= dev->host_features;
     virtio_add_feature(&f, VIRTIO_BALLOON_F_STATS_VQ);
-    if (virtio_has_feature(f, VIRTIO_BALLOON_F_FREE_PAGE_HINT)) {
+    if (virtio_has_feature(f, VIRTIO_BALLOON_F_FREE_PAGE_HINT) ||
+        virtio_has_feature(f, VIRTIO_BALLOON_F_REPORTING)) {
         virtio_add_feature(&f, VIRTIO_BALLOON_F_PAGE_POISON);
     }
 
@@ -806,6 +842,10 @@ static void virtio_balloon_device_realize(DeviceState *dev, Error **errp)
     s->dvq = virtio_add_queue(vdev, 128, virtio_balloon_handle_output);
     s->svq = virtio_add_queue(vdev, 128, virtio_balloon_receive_stats);
 
+    if (virtio_has_feature(s->host_features, VIRTIO_BALLOON_F_REPORTING)) {
+        s->rvq = virtio_add_queue(vdev, 32, virtio_balloon_handle_report);
+    }
+
     if (virtio_has_feature(s->host_features,
                            VIRTIO_BALLOON_F_FREE_PAGE_HINT)) {
         s->free_page_vq = virtio_add_queue(vdev, VIRTQUEUE_MAX_SIZE,
@@ -932,6 +972,8 @@ static Property virtio_balloon_properties[] = {
      */
     DEFINE_PROP_BOOL("qemu-4-0-config-size", VirtIOBalloon,
                      qemu_4_0_config_size, false),
+    DEFINE_PROP_BIT("unused-page-reporting", VirtIOBalloon, host_features,
+                    VIRTIO_BALLOON_F_REPORTING, true),
     DEFINE_PROP_LINK("iothread", VirtIOBalloon, iothread, TYPE_IOTHREAD,
                      IOThread *),
     DEFINE_PROP_END_OF_LIST(),
diff --git a/include/hw/virtio/virtio-balloon.h b/include/hw/virtio/virtio-balloon.h
index 7fe78e5c14d7..db5bf7127112 100644
--- a/include/hw/virtio/virtio-balloon.h
+++ b/include/hw/virtio/virtio-balloon.h
@@ -42,7 +42,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, *rvq;
     uint32_t free_page_report_status;
     uint32_t num_pages;
     uint32_t actual;

Re: [PATCH v11 0/6] mm / virtio: Provide support for unused page reporting

[David Hildenbrand]

On 01.10.19 17:29, Alexander Duyck wrote:
> This series provides an asynchronous means of reporting 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 unused page reporting. The advantage of
> unused page reporting is that we can support a significant amount of
> memory over-commit with improved performance as we can avoid having to
> write/read memory from swap as the VM will instead actively participate
> in freeing unused memory so it doesn't have to be written.
> 
> The functionality for this is fairly simple. When enabled it will allocate
> statistics to track the number of reported 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 reporting which consists of
> pulling non-reported pages off of the free lists of a given zone and
> placing them into a scatterlist. The scatterlist is then given to the page
> reporting device and it will perform the required action to make the pages
> "reported", in the case of virtio-balloon this results in the pages being
> madvised as MADV_DONTNEED. After this they are placed back on their
> original free list. If they are not merged in freeing an additional bit is
> set indicating that they are a "reported" buddy page instead of a standard
> buddy page. The cycle then repeats with additional non-reported pages
> being pulled until the free areas all consist of reported pages.
> 
> In order to try and keep the time needed to find a non-reported page to
> a minimum we maintain a "reported_boundary" pointer. This pointer is used
> by the get_unreported_pages iterator to determine at what point it should
> resume searching for non-reported pages. In order to guarantee pages do
> not get past the scan I have modified add_to_free_list_tail so that it
> will not insert pages behind the reported_boundary. Doing this allows us
> to keep the overhead to a minimum as re-walking the list without the
> boundary will result in as much as 18% additional overhead on a 32G VM.
> 
> If another process needs to perform a massive manipulation of the free
> list, such as compaction, it can either reset a given individual boundary
> which will push the boundary back to the list_head, or it can clear the
> bit indicating the zone is actively processing which will result in the
> reporting process resetting all of the boundaries for a given zone.
> 
> 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. The upper limit for this is based on the size of the
> queue used to store the scatterlist.
> 
> I wanted to avoid gaming the performance testing for this. As far as
> possible gain a significant performance improvement should be visible in
> cases where guests are forced to write/read from swap. As such, testing
> it would be more of a benchmark of copying a page from swap versus just
> allocating a zero page. I have been verifying that the memory is being
> freed using memhog to allocate all the memory on the guest, and then
> watching /proc/meminfo to verify the host sees the memory returned after
> the test completes.
> 
> As far as possible regressions I have focused on cases where performing
> the hinting would be non-optimal, such as cases where the code isn't
> needed as memory is not over-committed, or the functionality is not in
> use. I have been using the will-it-scale/page_fault1 test running with 16
> vcpus and have modified it to use Transparent Huge Pages. With this I see
> almost no difference with the patches applied and the feature disabled.
> Likewise I see almost no difference with the feature enabled, but the
> madvise disabled in the hypervisor due to a device being assigned. With
> the feature fully enabled in both guest and hypervisor I see a regression
> between -1.86% and -8.84% versus the baseline. I found that most of the
> overhead was due to the page faulting/zeroing that comes as a result of
> the pages having been evicted from the guest.

I think Michal asked for a performance comparison against Nitesh's
approach, to evaluate if keeping the reported state + tracking inside
the buddy is really worth it. Do you have any such numbers already? (or
did my tired eyes miss them in this cover letter? :/)

-- 

Thanks,

David / dhildenb

Re: [PATCH v11 0/6] mm / virtio: Provide support for unused page reporting

[Alexander Duyck]

On Tue, 2019-10-01 at 17:35 +0200, David Hildenbrand wrote:
> On 01.10.19 17:29, Alexander Duyck wrote:
> > This series provides an asynchronous means of reporting 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 unused page reporting. The advantage of
> > unused page reporting is that we can support a significant amount of
> > memory over-commit with improved performance as we can avoid having to
> > write/read memory from swap as the VM will instead actively participate
> > in freeing unused memory so it doesn't have to be written.
> > 
> > The functionality for this is fairly simple. When enabled it will allocate
> > statistics to track the number of reported 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 reporting which consists of
> > pulling non-reported pages off of the free lists of a given zone and
> > placing them into a scatterlist. The scatterlist is then given to the page
> > reporting device and it will perform the required action to make the pages
> > "reported", in the case of virtio-balloon this results in the pages being
> > madvised as MADV_DONTNEED. After this they are placed back on their
> > original free list. If they are not merged in freeing an additional bit is
> > set indicating that they are a "reported" buddy page instead of a standard
> > buddy page. The cycle then repeats with additional non-reported pages
> > being pulled until the free areas all consist of reported pages.
> > 
> > In order to try and keep the time needed to find a non-reported page to
> > a minimum we maintain a "reported_boundary" pointer. This pointer is used
> > by the get_unreported_pages iterator to determine at what point it should
> > resume searching for non-reported pages. In order to guarantee pages do
> > not get past the scan I have modified add_to_free_list_tail so that it
> > will not insert pages behind the reported_boundary. Doing this allows us
> > to keep the overhead to a minimum as re-walking the list without the
> > boundary will result in as much as 18% additional overhead on a 32G VM.
> > 
> > 

<snip>

> > As far as possible regressions I have focused on cases where performing
> > the hinting would be non-optimal, such as cases where the code isn't
> > needed as memory is not over-committed, or the functionality is not in
> > use. I have been using the will-it-scale/page_fault1 test running with 16
> > vcpus and have modified it to use Transparent Huge Pages. With this I see
> > almost no difference with the patches applied and the feature disabled.
> > Likewise I see almost no difference with the feature enabled, but the
> > madvise disabled in the hypervisor due to a device being assigned. With
> > the feature fully enabled in both guest and hypervisor I see a regression
> > between -1.86% and -8.84% versus the baseline. I found that most of the
> > overhead was due to the page faulting/zeroing that comes as a result of
> > the pages having been evicted from the guest.
> 
> I think Michal asked for a performance comparison against Nitesh's
> approach, to evaluate if keeping the reported state + tracking inside
> the buddy is really worth it. Do you have any such numbers already? (or
> did my tired eyes miss them in this cover letter? :/)
> 

I thought what Michal was asking for was what was the benefit of using the
boundary pointer. I added a bit up above and to the description for patch
3 as on a 32G VM it adds up to about a 18% difference without factoring in
the page faulting and zeroing logic that occurs when we actually do the
madvise.

Do we have a working patch set for Nitesh's code? The last time I tried
running his patch set I ran into issues with kernel panics. If we have a
known working/stable patch set I can give it a try.

- Alex

Re: [PATCH v11 0/6] mm / virtio: Provide support for unused page reporting

[David Hildenbrand]

>> I think Michal asked for a performance comparison against Nitesh's
>> approach, to evaluate if keeping the reported state + tracking inside
>> the buddy is really worth it. Do you have any such numbers already? (or
>> did my tired eyes miss them in this cover letter? :/)
>>
> 
> I thought what Michal was asking for was what was the benefit of using the
> boundary pointer. I added a bit up above and to the description for patch
> 3 as on a 32G VM it adds up to about a 18% difference without factoring in
> the page faulting and zeroing logic that occurs when we actually do the
> madvise.

"I would still be happier if the allocator wouldn't really have to
bother about somebody snooping its internal state to do its own thing.
So make sure to describe why and how much this really matters.
[...]
if you gave some rough numbers to quantify how much overhead for
different solutions we are talking about here.
"

Could be that I'm misreading Michals comment, but I'd be interested in
the "how much" as well.

> 
> Do we have a working patch set for Nitesh's code? The last time I tried
> running his patch set I ran into issues with kernel panics. If we have a
> known working/stable patch set I can give it a try.

@Nitesh, is there a working branch?


-- 

Thanks,

David / dhildenb

Re: [PATCH v11 0/6] mm / virtio: Provide support for unused page reporting

[Michael S. Tsirkin]

On Tue, Oct 01, 2019 at 09:21:46AM -0700, Alexander Duyck wrote:
> I thought what Michal was asking for was what was the benefit of using the
> boundary pointer. I added a bit up above and to the description for patch
> 3 as on a 32G VM it adds up to about a 18% difference without factoring in
> the page faulting and zeroing logic that occurs when we actually do the
> madvise.

Something maybe worth adding to the log:

one disadvantage of the tight integration with the mm core is
that only a single reporting device is supported.
It's not obvious that more than one is useful though.

-- 
MST

Re: [PATCH v11 0/6] mm / virtio: Provide support for unused page reporting

[Nitesh Narayan Lal]

On 10/1/19 12:21 PM, Alexander Duyck wrote:
> On Tue, 2019-10-01 at 17:35 +0200, David Hildenbrand wrote:
>> On 01.10.19 17:29, Alexander Duyck wrote:
>>> This series provides an asynchronous means of reporting 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 unused page reporting. The advantage of
>>> unused page reporting is that we can support a significant amount of
>>> memory over-commit with improved performance as we can avoid having to
>>> write/read memory from swap as the VM will instead actively participate
>>> in freeing unused memory so it doesn't have to be written.
>>>
>>> The functionality for this is fairly simple. When enabled it will allocate
>>> statistics to track the number of reported 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 reporting which consists of
>>> pulling non-reported pages off of the free lists of a given zone and
>>> placing them into a scatterlist. The scatterlist is then given to the page
>>> reporting device and it will perform the required action to make the pages
>>> "reported", in the case of virtio-balloon this results in the pages being
>>> madvised as MADV_DONTNEED. After this they are placed back on their
>>> original free list. If they are not merged in freeing an additional bit is
>>> set indicating that they are a "reported" buddy page instead of a standard
>>> buddy page. The cycle then repeats with additional non-reported pages
>>> being pulled until the free areas all consist of reported pages.
>>>
>>> In order to try and keep the time needed to find a non-reported page to
>>> a minimum we maintain a "reported_boundary" pointer. This pointer is used
>>> by the get_unreported_pages iterator to determine at what point it should
>>> resume searching for non-reported pages. In order to guarantee pages do
>>> not get past the scan I have modified add_to_free_list_tail so that it
>>> will not insert pages behind the reported_boundary. Doing this allows us
>>> to keep the overhead to a minimum as re-walking the list without the
>>> boundary will result in as much as 18% additional overhead on a 32G VM.
>>>
>>>
> <snip>
>
>>> As far as possible regressions I have focused on cases where performing
>>> the hinting would be non-optimal, such as cases where the code isn't
>>> needed as memory is not over-committed, or the functionality is not in
>>> use. I have been using the will-it-scale/page_fault1 test running with 16
>>> vcpus and have modified it to use Transparent Huge Pages. With this I see
>>> almost no difference with the patches applied and the feature disabled.
>>> Likewise I see almost no difference with the feature enabled, but the
>>> madvise disabled in the hypervisor due to a device being assigned. With
>>> the feature fully enabled in both guest and hypervisor I see a regression
>>> between -1.86% and -8.84% versus the baseline. I found that most of the
>>> overhead was due to the page faulting/zeroing that comes as a result of
>>> the pages having been evicted from the guest.
>> I think Michal asked for a performance comparison against Nitesh's
>> approach, to evaluate if keeping the reported state + tracking inside
>> the buddy is really worth it. Do you have any such numbers already? (or
>> did my tired eyes miss them in this cover letter? :/)
>>
> I thought what Michal was asking for was what was the benefit of using the
> boundary pointer. I added a bit up above and to the description for patch
> 3 as on a 32G VM it adds up to about a 18% difference without factoring in
> the page faulting and zeroing logic that occurs when we actually do the
> madvise.
>
> Do we have a working patch set for Nitesh's code? The last time I tried
> running his patch set I ran into issues with kernel panics. If we have a
> known working/stable patch set I can give it a try.

Did you try the v12 patch-set [1]?
I remember that you reported the CPU stall issue, which I fixed in the v12.

[1] https://lkml.org/lkml/2019/8/12/593

>
> - Alex
>
-- 
Thanks
Nitesh

Re: [PATCH v11 0/6] mm / virtio: Provide support for unused page reporting

[Nitesh Narayan Lal]

On 10/1/19 2:41 PM, David Hildenbrand wrote:
>>> I think Michal asked for a performance comparison against Nitesh's
>>> approach, to evaluate if keeping the reported state + tracking inside
>>> the buddy is really worth it. Do you have any such numbers already? (or
>>> did my tired eyes miss them in this cover letter? :/)
>>>
>> I thought what Michal was asking for was what was the benefit of using the
>> boundary pointer. I added a bit up above and to the description for patch
>> 3 as on a 32G VM it adds up to about a 18% difference without factoring in
>> the page faulting and zeroing logic that occurs when we actually do the
>> madvise.
> "I would still be happier if the allocator wouldn't really have to
> bother about somebody snooping its internal state to do its own thing.
> So make sure to describe why and how much this really matters.
> [...]
> if you gave some rough numbers to quantify how much overhead for
> different solutions we are talking about here.
> "
>
> Could be that I'm misreading Michals comment, but I'd be interested in
> the "how much" as well.
>
>> Do we have a working patch set for Nitesh's code? The last time I tried
>> running his patch set I ran into issues with kernel panics. If we have a
>> known working/stable patch set I can give it a try.
> @Nitesh, is there a working branch?

For some unknown reason, I received these set of emails just now :)
That's why couldn't respond earlier.

>
>
-- 
Thanks
Nitesh

Re: [PATCH v11 0/6] mm / virtio: Provide support for unused page reporting

[Alexander Duyck]

On Tue, 2019-10-01 at 15:16 -0400, Nitesh Narayan Lal wrote:
> On 10/1/19 12:21 PM, Alexander Duyck wrote:
> > On Tue, 2019-10-01 at 17:35 +0200, David Hildenbrand wrote:
> > > On 01.10.19 17:29, Alexander Duyck wrote:

<snip>

> > > > 
> > > > As far as possible regressions I have focused on cases where performing
> > > > the hinting would be non-optimal, such as cases where the code isn't
> > > > needed as memory is not over-committed, or the functionality is not in
> > > > use. I have been using the will-it-scale/page_fault1 test running with 16
> > > > vcpus and have modified it to use Transparent Huge Pages. With this I see
> > > > almost no difference with the patches applied and the feature disabled.
> > > > Likewise I see almost no difference with the feature enabled, but the
> > > > madvise disabled in the hypervisor due to a device being assigned. With
> > > > the feature fully enabled in both guest and hypervisor I see a regression
> > > > between -1.86% and -8.84% versus the baseline. I found that most of the
> > > > overhead was due to the page faulting/zeroing that comes as a result of
> > > > the pages having been evicted from the guest.
> > > I think Michal asked for a performance comparison against Nitesh's
> > > approach, to evaluate if keeping the reported state + tracking inside
> > > the buddy is really worth it. Do you have any such numbers already? (or
> > > did my tired eyes miss them in this cover letter? :/)
> > > 
> > I thought what Michal was asking for was what was the benefit of using the
> > boundary pointer. I added a bit up above and to the description for patch
> > 3 as on a 32G VM it adds up to about a 18% difference without factoring in
> > the page faulting and zeroing logic that occurs when we actually do the
> > madvise.
> > 
> > Do we have a working patch set for Nitesh's code? The last time I tried
> > running his patch set I ran into issues with kernel panics. If we have a
> > known working/stable patch set I can give it a try.
> 
> Did you try the v12 patch-set [1]?
> I remember that you reported the CPU stall issue, which I fixed in the v12.
> 
> [1] https://lkml.org/lkml/2019/8/12/593
> 
> > - Alex
> > 

I haven't tested it. I will pull the patches and give it a try. It works
with the same QEMU changes that mine does right? If so we should be able
to get an apples-to-apples comparison.

Also, instead of providing lkml.org links to your patches in the future it
might be better to provide a link to the lore.kernel.org version of the
thread. So for example the v12 set would be:
https://lore.kernel.org/lkml/20190812131235.27244-1-nitesh@redhat.com/

The advantage is you can just look up the message ID in your own inbox to
figure out the link, and it provides raw access to the email if needed.

Thanks.

- Alex

Re: [PATCH v11 0/6] mm / virtio: Provide support for unused page reporting

[Alexander Duyck]

On Tue, 2019-10-01 at 13:25 -0700, Alexander Duyck wrote:
> On Tue, 2019-10-01 at 15:16 -0400, Nitesh Narayan Lal wrote:
> > On 10/1/19 12:21 PM, Alexander Duyck wrote:
> > > On Tue, 2019-10-01 at 17:35 +0200, David Hildenbrand wrote:
> > > > On 01.10.19 17:29, Alexander Duyck wrote:
> 
> <snip>
> 
> > > > > As far as possible regressions I have focused on cases where performing
> > > > > the hinting would be non-optimal, such as cases where the code isn't
> > > > > needed as memory is not over-committed, or the functionality is not in
> > > > > use. I have been using the will-it-scale/page_fault1 test running with 16
> > > > > vcpus and have modified it to use Transparent Huge Pages. With this I see
> > > > > almost no difference with the patches applied and the feature disabled.
> > > > > Likewise I see almost no difference with the feature enabled, but the
> > > > > madvise disabled in the hypervisor due to a device being assigned. With
> > > > > the feature fully enabled in both guest and hypervisor I see a regression
> > > > > between -1.86% and -8.84% versus the baseline. I found that most of the
> > > > > overhead was due to the page faulting/zeroing that comes as a result of
> > > > > the pages having been evicted from the guest.
> > > > I think Michal asked for a performance comparison against Nitesh's
> > > > approach, to evaluate if keeping the reported state + tracking inside
> > > > the buddy is really worth it. Do you have any such numbers already? (or
> > > > did my tired eyes miss them in this cover letter? :/)
> > > > 
> > > I thought what Michal was asking for was what was the benefit of using the
> > > boundary pointer. I added a bit up above and to the description for patch
> > > 3 as on a 32G VM it adds up to about a 18% difference without factoring in
> > > the page faulting and zeroing logic that occurs when we actually do the
> > > madvise.
> > > 
> > > Do we have a working patch set for Nitesh's code? The last time I tried
> > > running his patch set I ran into issues with kernel panics. If we have a
> > > known working/stable patch set I can give it a try.
> > 
> > Did you try the v12 patch-set [1]?
> > I remember that you reported the CPU stall issue, which I fixed in the v12.
> > 
> > [1] https://lkml.org/lkml/2019/8/12/593
> > 
> > > - Alex
> > > 
> 
> I haven't tested it. I will pull the patches and give it a try. It works
> with the same QEMU changes that mine does right? If so we should be able
> to get an apples-to-apples comparison.
> 
> Also, instead of providing lkml.org links to your patches in the future it
> might be better to provide a link to the lore.kernel.org version of the
> thread. So for example the v12 set would be:
> https://lore.kernel.org/lkml/20190812131235.27244-1-nitesh@redhat.com/
> 
> The advantage is you can just look up the message ID in your own inbox to
> figure out the link, and it provides raw access to the email if needed.
> 
> Thanks.
> 
> - Alex

So it looks like v12 still has issues. I'm pretty sure you should be using
spin_lock_irq(), not spin_lock() in page_reporting.c to avoid the
possibility of an IRQ firing and causing lock recursion on the zone lock.

I'm trying to work around it now, but it needs to be addressed for future
versions.

Here is the lock-up my guest reported.

[  127.869086] rcu: INFO: rcu_sched detected stalls on CPUs/tasks:
[  127.872219] rcu: 	0-...0: (0 ticks this GP) idle=94e/1/0x4000000000000002 softirq=5354/5354 fqs=15000 
[  127.874915] rcu: 	1-...0: (0 ticks this GP) idle=3b6/1/0x4000000000000000 softirq=3359/3359 fqs=15000 
[  127.877616] 	(detected by 2, t=60004 jiffies, g=8153, q=8)
[  127.879229] Sending NMI from CPU 2 to CPUs 0:
[  127.881523] NMI backtrace for cpu 0
[  127.881524] CPU: 0 PID: 658 Comm: kworker/0:6 Not tainted 5.3.0-next-20190930nshuffle+ #2
[  127.881524] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
[  127.881525] Workqueue: events page_reporting_wq
[  127.881526] RIP: 0010:queued_spin_lock_slowpath+0x21/0x1f0
[  127.881526] Code: c0 75 ec c3 90 90 90 90 90 0f 1f 44 00 00 0f 1f 44 00 00 ba 01 00 00 00 8b 07 85 c0 75 0a f0 0f b1 17 85 c0 75 f2 f3 c3 f3 90 <eb> ec 81 fe 00 01 00 00 0f 84 44 01 00 00 81 e6 00 ff ff ff 75 3e
[  127.881527] RSP: 0018:ffffb77480003df0 EFLAGS: 00000002
[  127.881527] RAX: 0000000000000001 RBX: 0000000000000001 RCX: dead000000000122
[  127.881528] RDX: 0000000000000001 RSI: 0000000000000001 RDI: ffff992a3fffd240
[  127.881528] RBP: 0000000000000006 R08: 0000000000000000 R09: ffffdd9c508cf948
[  127.881528] R10: 0000000000000000 R11: 0000000000000000 R12: ffff992a3fffcd00
[  127.881529] R13: ffffdd9c508cf900 R14: ffff992a2fa2e380 R15: 0000000000000001
[  127.881529] FS:  0000000000000000(0000) GS:ffff992a2fa00000(0000) knlGS:0000000000000000
[  127.881529] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  127.881530] CR2: 00007ffff7c50000 CR3: 000000042c6b8004 CR4: 0000000000160ef0
[  127.881530] Call Trace:
[  127.881530]  <IRQ>
[  127.881531]  free_pcppages_bulk+0x15f/0x7d0
[  127.881531]  free_unref_page+0x54/0x70
[  127.881531]  tlb_remove_table_rcu+0x23/0x40
[  127.881531]  rcu_do_batch+0x139/0x3f0
[  127.881532]  rcu_core+0x1b9/0x2d0
[  127.881532]  __do_softirq+0xe2/0x2bb
[  127.881532]  irq_exit+0xd5/0xe0
[  127.881532]  smp_apic_timer_interrupt+0x74/0x140
[  127.881533]  apic_timer_interrupt+0xf/0x20
[  127.881533]  </IRQ>
[  127.881533] RIP: 0010:__list_del_entry_valid+0x31/0x90
[  127.881534] Code: 00 00 00 00 ad de 48 8b 57 08 48 39 c8 74 26 48 b9 22 01 00 00 00 00 ad de 48 39 ca 74 53 48 8b 12 48 39 d7 75 38 48 8b 50 08 <48> 39 d7 75 1c b8 01 00 00 00 c3 48 89 c2 48 89 fe 31 c0 48 c7 c7
[  127.881534] RSP: 0018:ffffb774837cfdf8 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff13
[  127.881535] RAX: ffffdd9c50858008 RBX: ffffdd9c50798000 RCX: dead000000000122
[  127.881535] RDX: ffffdd9c50798008 RSI: 0000000000000000 RDI: ffffdd9c50798008
[  127.881536] RBP: ffff992a3fffcd00 R08: 0000000000000000 R09: 00000000003241ad
[  127.881536] R10: 0000000000000000 R11: 00000000000025c4 R12: 0000000000000009
[  127.881536] R13: fffffffffffffe00 R14: 0000000000000001 R15: ffff992a3fffcd00
[  127.881537]  __isolate_free_page+0xe9/0x1d0
[  127.881537]  page_reporting_wq+0x1ba/0x290
[  127.881537]  process_one_work+0x16c/0x370
[  127.881538]  worker_thread+0x49/0x3e0
[  127.881538]  kthread+0xf8/0x130
[  127.881538]  ? apply_wqattrs_commit+0x100/0x100
[  127.881538]  ? kthread_bind+0x10/0x10
[  127.881539]  ret_from_fork+0x35/0x40
[  127.881543] Sending NMI from CPU 2 to CPUs 1:
[  127.921299] NMI backtrace for cpu 1
[  127.921300] CPU: 1 PID: 1257 Comm: page_fault4_pro Not tainted 5.3.0-next-20190930nshuffle+ #2
[  127.921300] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
[  127.921300] RIP: 0010:queued_spin_lock_slowpath+0x21/0x1f0
[  127.921301] Code: c0 75 ec c3 90 90 90 90 90 0f 1f 44 00 00 0f 1f 44 00 00 ba 01 00 00 00 8b 07 85 c0 75 0a f0 0f b1 17 85 c0 75 f2 f3 c3 f3 90 <eb> ec 81 fe 00 01 00 00 0f 84 44 01 00 00 81 e6 00 ff ff ff 75 3e
[  127.921301] RSP: 0000:ffffb7748378bbd8 EFLAGS: 00000002
[  127.921302] RAX: 0000000000000001 RBX: 0000000000000246 RCX: 0000000000000001
[  127.921302] RDX: 0000000000000001 RSI: 0000000000000001 RDI: ffff992a3fffd240
[  127.921303] RBP: 0000000000000009 R08: 0000000000000080 R09: 0000000000323dae
[  127.921303] R10: 0000000000000009 R11: 00000000000030d1 R12: 0000000000000081
[  127.921304] R13: 00000000003c24ca R14: 0000000000000000 R15: ffff992a3fffcd00
[  127.921304] FS:  00007ffff7c52540(0000) GS:ffff992a2fa40000(0000) knlGS:0000000000000000
[  127.921304] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  127.921305] CR2: 00007ffff1e00000 CR3: 000000042f17c001 CR4: 0000000000160ee0
[  127.921305] Call Trace:
[  127.921305]  _raw_spin_lock_irqsave+0x35/0x40
[  127.921305]  get_page_from_freelist+0xba0/0x13c0
[  127.921306]  ? prep_new_page+0xad/0xf0
[  127.921306]  __alloc_pages_nodemask+0x197/0x350
[  127.921306]  alloc_pages_vma+0x160/0x1b0
[  127.921307]  do_huge_pmd_anonymous_page+0x123/0x8a0
[  127.921307]  __handle_mm_fault+0xcbe/0x15f0
[  127.921307]  ? do_mmap+0x47b/0x5e0
[  127.921307]  handle_mm_fault+0xe2/0x1f0
[  127.921308]  __do_page_fault+0x234/0x4c0
[  127.921308]  do_page_fault+0x31/0x120
[  127.921308]  async_page_fault+0x3e/0x50
[  127.921308] RIP: 0033:0x401c30
[  127.921309] Code: 00 00 00 08 e8 d1 f4 ff ff 48 89 c5 48 83 f8 ff 74 40 ba 0e 00 00 00 be 00 00 00 08 48 89 c7 e8 e6 f5 ff ff 31 c0 0f 1f 40 00 <c6> 44 05 00 00 4c 01 e0 48 83 03 01 48 3d ff ff ff 07 76 ec be 00
[  127.921309] RSP: 002b:00007fffffffc8f0 EFLAGS: 00010293
[  127.921310] RAX: 00000000021af000 RBX: 00007ffff7ffb080 RCX: 00007ffff7eaf2eb
[  127.921310] RDX: 000000000000000e RSI: 0000000008000000 RDI: 00007fffefc51000
[  127.921311] RBP: 00007fffefc51000 R08: 00000000ffffffff R09: 0000000000000000
[  127.921311] R10: 0000000000000022 R11: 0000000000000213 R12: 0000000000001000
[  127.921311] R13: 000000000044de20 R14: 000000000040d890 R15: 0000000000408d20

Re: [PATCH v11 0/6] mm / virtio: Provide support for unused page reporting

[Dave Hansen]

On 10/1/19 1:49 PM, Alexander Duyck wrote:
> So it looks like v12 still has issues. I'm pretty sure you should be using
> spin_lock_irq(), not spin_lock() in page_reporting.c to avoid the
> possibility of an IRQ firing and causing lock recursion on the zone lock.

Lockdep should make all of this a lot easier to find.  Is it being used?

Re: [PATCH v11 0/6] mm / virtio: Provide support for unused page reporting

[Alexander Duyck]

On Tue, Oct 1, 2019 at 12:16 PM Nitesh Narayan Lal <nitesh@redhat.com> wrote:
>
>
> On 10/1/19 12:21 PM, Alexander Duyck wrote:
> > On Tue, 2019-10-01 at 17:35 +0200, David Hildenbrand wrote:
> >> On 01.10.19 17:29, Alexander Duyck wrote:
> >>> This series provides an asynchronous means of reporting 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 unused page reporting. The advantage of
> >>> unused page reporting is that we can support a significant amount of
> >>> memory over-commit with improved performance as we can avoid having to
> >>> write/read memory from swap as the VM will instead actively participate
> >>> in freeing unused memory so it doesn't have to be written.
> >>>
> >>> The functionality for this is fairly simple. When enabled it will allocate
> >>> statistics to track the number of reported 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 reporting which consists of
> >>> pulling non-reported pages off of the free lists of a given zone and
> >>> placing them into a scatterlist. The scatterlist is then given to the page
> >>> reporting device and it will perform the required action to make the pages
> >>> "reported", in the case of virtio-balloon this results in the pages being
> >>> madvised as MADV_DONTNEED. After this they are placed back on their
> >>> original free list. If they are not merged in freeing an additional bit is
> >>> set indicating that they are a "reported" buddy page instead of a standard
> >>> buddy page. The cycle then repeats with additional non-reported pages
> >>> being pulled until the free areas all consist of reported pages.
> >>>
> >>> In order to try and keep the time needed to find a non-reported page to
> >>> a minimum we maintain a "reported_boundary" pointer. This pointer is used
> >>> by the get_unreported_pages iterator to determine at what point it should
> >>> resume searching for non-reported pages. In order to guarantee pages do
> >>> not get past the scan I have modified add_to_free_list_tail so that it
> >>> will not insert pages behind the reported_boundary. Doing this allows us
> >>> to keep the overhead to a minimum as re-walking the list without the
> >>> boundary will result in as much as 18% additional overhead on a 32G VM.
> >>>
> >>>
> > <snip>
> >
> >>> As far as possible regressions I have focused on cases where performing
> >>> the hinting would be non-optimal, such as cases where the code isn't
> >>> needed as memory is not over-committed, or the functionality is not in
> >>> use. I have been using the will-it-scale/page_fault1 test running with 16
> >>> vcpus and have modified it to use Transparent Huge Pages. With this I see
> >>> almost no difference with the patches applied and the feature disabled.
> >>> Likewise I see almost no difference with the feature enabled, but the
> >>> madvise disabled in the hypervisor due to a device being assigned. With
> >>> the feature fully enabled in both guest and hypervisor I see a regression
> >>> between -1.86% and -8.84% versus the baseline. I found that most of the
> >>> overhead was due to the page faulting/zeroing that comes as a result of
> >>> the pages having been evicted from the guest.
> >> I think Michal asked for a performance comparison against Nitesh's
> >> approach, to evaluate if keeping the reported state + tracking inside
> >> the buddy is really worth it. Do you have any such numbers already? (or
> >> did my tired eyes miss them in this cover letter? :/)
> >>
> > I thought what Michal was asking for was what was the benefit of using the
> > boundary pointer. I added a bit up above and to the description for patch
> > 3 as on a 32G VM it adds up to about a 18% difference without factoring in
> > the page faulting and zeroing logic that occurs when we actually do the
> > madvise.
> >
> > Do we have a working patch set for Nitesh's code? The last time I tried
> > running his patch set I ran into issues with kernel panics. If we have a
> > known working/stable patch set I can give it a try.
>
> Did you try the v12 patch-set [1]?
> I remember that you reported the CPU stall issue, which I fixed in the v12.
>
> [1] https://lkml.org/lkml/2019/8/12/593

So I tried testing with the spin_lock calls replaced with spin_lock
_irq to resolve the IRQ issue. I also had shuffle enabled in order to
increase the number of pages being dirtied.

With that setup the bitmap approach is running significantly worse
then my approach, even with the boundary removed. Since I had to
modify the code to even getting working I am not comfortable posting
numbers. My suggestion would be to look at reworking the patch set and
post numbers for my patch set versus the bitmap approach and we can
look at them then. I would prefer not to spend my time fixing and
tuning a patch set that I am still not convinced is viable.

Thanks.

- Alex

Re: [PATCH v11 0/6] mm / virtio: Provide support for unused page reporting

[David Hildenbrand]

On 02.10.19 02:55, Alexander Duyck wrote:
> On Tue, Oct 1, 2019 at 12:16 PM Nitesh Narayan Lal <nitesh@redhat.com> wrote:
>>
>>
>> On 10/1/19 12:21 PM, Alexander Duyck wrote:
>>> On Tue, 2019-10-01 at 17:35 +0200, David Hildenbrand wrote:
>>>> On 01.10.19 17:29, Alexander Duyck wrote:
>>>>> This series provides an asynchronous means of reporting 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 unused page reporting. The advantage of
>>>>> unused page reporting is that we can support a significant amount of
>>>>> memory over-commit with improved performance as we can avoid having to
>>>>> write/read memory from swap as the VM will instead actively participate
>>>>> in freeing unused memory so it doesn't have to be written.
>>>>>
>>>>> The functionality for this is fairly simple. When enabled it will allocate
>>>>> statistics to track the number of reported 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 reporting which consists of
>>>>> pulling non-reported pages off of the free lists of a given zone and
>>>>> placing them into a scatterlist. The scatterlist is then given to the page
>>>>> reporting device and it will perform the required action to make the pages
>>>>> "reported", in the case of virtio-balloon this results in the pages being
>>>>> madvised as MADV_DONTNEED. After this they are placed back on their
>>>>> original free list. If they are not merged in freeing an additional bit is
>>>>> set indicating that they are a "reported" buddy page instead of a standard
>>>>> buddy page. The cycle then repeats with additional non-reported pages
>>>>> being pulled until the free areas all consist of reported pages.
>>>>>
>>>>> In order to try and keep the time needed to find a non-reported page to
>>>>> a minimum we maintain a "reported_boundary" pointer. This pointer is used
>>>>> by the get_unreported_pages iterator to determine at what point it should
>>>>> resume searching for non-reported pages. In order to guarantee pages do
>>>>> not get past the scan I have modified add_to_free_list_tail so that it
>>>>> will not insert pages behind the reported_boundary. Doing this allows us
>>>>> to keep the overhead to a minimum as re-walking the list without the
>>>>> boundary will result in as much as 18% additional overhead on a 32G VM.
>>>>>
>>>>>
>>> <snip>
>>>
>>>>> As far as possible regressions I have focused on cases where performing
>>>>> the hinting would be non-optimal, such as cases where the code isn't
>>>>> needed as memory is not over-committed, or the functionality is not in
>>>>> use. I have been using the will-it-scale/page_fault1 test running with 16
>>>>> vcpus and have modified it to use Transparent Huge Pages. With this I see
>>>>> almost no difference with the patches applied and the feature disabled.
>>>>> Likewise I see almost no difference with the feature enabled, but the
>>>>> madvise disabled in the hypervisor due to a device being assigned. With
>>>>> the feature fully enabled in both guest and hypervisor I see a regression
>>>>> between -1.86% and -8.84% versus the baseline. I found that most of the
>>>>> overhead was due to the page faulting/zeroing that comes as a result of
>>>>> the pages having been evicted from the guest.
>>>> I think Michal asked for a performance comparison against Nitesh's
>>>> approach, to evaluate if keeping the reported state + tracking inside
>>>> the buddy is really worth it. Do you have any such numbers already? (or
>>>> did my tired eyes miss them in this cover letter? :/)
>>>>
>>> I thought what Michal was asking for was what was the benefit of using the
>>> boundary pointer. I added a bit up above and to the description for patch
>>> 3 as on a 32G VM it adds up to about a 18% difference without factoring in
>>> the page faulting and zeroing logic that occurs when we actually do the
>>> madvise.
>>>
>>> Do we have a working patch set for Nitesh's code? The last time I tried
>>> running his patch set I ran into issues with kernel panics. If we have a
>>> known working/stable patch set I can give it a try.
>>
>> Did you try the v12 patch-set [1]?
>> I remember that you reported the CPU stall issue, which I fixed in the v12.
>>
>> [1] https://lkml.org/lkml/2019/8/12/593
> 
> So I tried testing with the spin_lock calls replaced with spin_lock
> _irq to resolve the IRQ issue. I also had shuffle enabled in order to
> increase the number of pages being dirtied.
> 
> With that setup the bitmap approach is running significantly worse
> then my approach, even with the boundary removed. Since I had to

It would make sense to share the setup+benchmark+performance indication
that you measured. You don't have to share the actual numbers.

> modify the code to even getting working I am not comfortable posting
> numbers. My suggestion would be to look at reworking the patch set and
> post numbers for my patch set versus the bitmap approach and we can
> look at them then. I would prefer not to spend my time fixing and
> tuning a patch set that I am still not convinced is viable.

I agree, I think Nitesh should work on his patch set and try to
reproduce what you are seeing.

Also, I think to make a precise statement of "which overhead comes with
external tracking", Nitesh should switch to an approach (motivated by
Michal) like

1. Sense lockless if a page is still free
2. start_isolate_page_range()
-> Failed? Skip
3. test_pages_isolated()
-> No? undo_isolate_page_range(), skip
4. Repeat for multiple pages + report
5. undo_isolate_page_range()

That is the bare minimum any external tracking will need = some overhead
for the tracking data. As a nice side effect, it get's rid of taking the
zone lock manually AFAIKS.

But that's unrelated to your series, only to quantify "how much" does
external tracking actually cost.

-- 

Thanks,

David / dhildenb

Re: [PATCH v11 0/6] mm / virtio: Provide support for unused page reporting

[Nitesh Narayan Lal]

On 10/1/19 8:55 PM, Alexander Duyck wrote:
> On Tue, Oct 1, 2019 at 12:16 PM Nitesh Narayan Lal <nitesh@redhat.com> wrote:
>>
>> On 10/1/19 12:21 PM, Alexander Duyck wrote:
>>> On Tue, 2019-10-01 at 17:35 +0200, David Hildenbrand wrote:
>>>> On 01.10.19 17:29, Alexander Duyck wrote:
>>>>> This series provides an asynchronous means of reporting 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 unused page reporting. The advantage of
>>>>> unused page reporting is that we can support a significant amount of
>>>>> memory over-commit with improved performance as we can avoid having to
>>>>> write/read memory from swap as the VM will instead actively participate
>>>>> in freeing unused memory so it doesn't have to be written.
>>>>>
>>>>> The functionality for this is fairly simple. When enabled it will allocate
>>>>> statistics to track the number of reported 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 reporting which consists of
>>>>> pulling non-reported pages off of the free lists of a given zone and
>>>>> placing them into a scatterlist. The scatterlist is then given to the page
>>>>> reporting device and it will perform the required action to make the pages
>>>>> "reported", in the case of virtio-balloon this results in the pages being
>>>>> madvised as MADV_DONTNEED. After this they are placed back on their
>>>>> original free list. If they are not merged in freeing an additional bit is
>>>>> set indicating that they are a "reported" buddy page instead of a standard
>>>>> buddy page. The cycle then repeats with additional non-reported pages
>>>>> being pulled until the free areas all consist of reported pages.
>>>>>
>>>>> In order to try and keep the time needed to find a non-reported page to
>>>>> a minimum we maintain a "reported_boundary" pointer. This pointer is used
>>>>> by the get_unreported_pages iterator to determine at what point it should
>>>>> resume searching for non-reported pages. In order to guarantee pages do
>>>>> not get past the scan I have modified add_to_free_list_tail so that it
>>>>> will not insert pages behind the reported_boundary. Doing this allows us
>>>>> to keep the overhead to a minimum as re-walking the list without the
>>>>> boundary will result in as much as 18% additional overhead on a 32G VM.
>>>>>
>>>>>
>>> <snip>
>>>
>>>>> As far as possible regressions I have focused on cases where performing
>>>>> the hinting would be non-optimal, such as cases where the code isn't
>>>>> needed as memory is not over-committed, or the functionality is not in
>>>>> use. I have been using the will-it-scale/page_fault1 test running with 16
>>>>> vcpus and have modified it to use Transparent Huge Pages. With this I see
>>>>> almost no difference with the patches applied and the feature disabled.
>>>>> Likewise I see almost no difference with the feature enabled, but the
>>>>> madvise disabled in the hypervisor due to a device being assigned. With
>>>>> the feature fully enabled in both guest and hypervisor I see a regression
>>>>> between -1.86% and -8.84% versus the baseline. I found that most of the
>>>>> overhead was due to the page faulting/zeroing that comes as a result of
>>>>> the pages having been evicted from the guest.
>>>> I think Michal asked for a performance comparison against Nitesh's
>>>> approach, to evaluate if keeping the reported state + tracking inside
>>>> the buddy is really worth it. Do you have any such numbers already? (or
>>>> did my tired eyes miss them in this cover letter? :/)
>>>>
>>> I thought what Michal was asking for was what was the benefit of using the
>>> boundary pointer. I added a bit up above and to the description for patch
>>> 3 as on a 32G VM it adds up to about a 18% difference without factoring in
>>> the page faulting and zeroing logic that occurs when we actually do the
>>> madvise.
>>>
>>> Do we have a working patch set for Nitesh's code? The last time I tried
>>> running his patch set I ran into issues with kernel panics. If we have a
>>> known working/stable patch set I can give it a try.
>> Did you try the v12 patch-set [1]?
>> I remember that you reported the CPU stall issue, which I fixed in the v12.
>>
>> [1] https://lkml.org/lkml/2019/8/12/593
> So I tried testing with the spin_lock calls replaced with spin_lock
> _irq to resolve the IRQ issue. I also had shuffle enabled in order to
> increase the number of pages being dirtied.
>
> With that setup the bitmap approach is running significantly worse
> then my approach, even with the boundary removed. Since I had to
> modify the code to even getting working I am not comfortable posting
> numbers. 

I didn't face any issue in getting the code work or compile.
Before my v12 posting, I did try your previously suggested test
(will-it-scale/page_fault1 for 12 hours on a 60 GB) and didn't see any issues.
I think it would help more if you can share the setup which you are running.

> My suggestion would be to look at reworking the patch set and
> post numbers for my patch set versus the bitmap approach and we can
> look at them then.

Agreed. However, in order to fix an issue I have to reproduce it first.

>  I would prefer not to spend my time fixing and
> tuning a patch set that I am still not convinced is viable.

You  don't have to, I can fix the issues in my patch-set. :)

>
> Thanks.
>
> - Alex
-- 
Nitesh

Re: [PATCH v11 0/6] mm / virtio: Provide support for unused page reporting

[Nitesh Narayan Lal]

On 10/2/19 3:13 AM, David Hildenbrand wrote:
> On 02.10.19 02:55, Alexander Duyck wrote:
>> On Tue, Oct 1, 2019 at 12:16 PM Nitesh Narayan Lal <nitesh@redhat.com> wrote:
>>>
>>> On 10/1/19 12:21 PM, Alexander Duyck wrote:
>>>> On Tue, 2019-10-01 at 17:35 +0200, David Hildenbrand wrote:
>>>>> On 01.10.19 17:29, Alexander Duyck wrote:
>>>>>> This series provides an asynchronous means of reporting 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 unused page reporting. The advantage of
>>>>>> unused page reporting is that we can support a significant amount of
>>>>>> memory over-commit with improved performance as we can avoid having to
>>>>>> write/read memory from swap as the VM will instead actively participate
>>>>>> in freeing unused memory so it doesn't have to be written.
>>>>>>
>>>>>> The functionality for this is fairly simple. When enabled it will allocate
>>>>>> statistics to track the number of reported 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 reporting which consists of
>>>>>> pulling non-reported pages off of the free lists of a given zone and
>>>>>> placing them into a scatterlist. The scatterlist is then given to the page
>>>>>> reporting device and it will perform the required action to make the pages
>>>>>> "reported", in the case of virtio-balloon this results in the pages being
>>>>>> madvised as MADV_DONTNEED. After this they are placed back on their
>>>>>> original free list. If they are not merged in freeing an additional bit is
>>>>>> set indicating that they are a "reported" buddy page instead of a standard
>>>>>> buddy page. The cycle then repeats with additional non-reported pages
>>>>>> being pulled until the free areas all consist of reported pages.
>>>>>>
>>>>>> In order to try and keep the time needed to find a non-reported page to
>>>>>> a minimum we maintain a "reported_boundary" pointer. This pointer is used
>>>>>> by the get_unreported_pages iterator to determine at what point it should
>>>>>> resume searching for non-reported pages. In order to guarantee pages do
>>>>>> not get past the scan I have modified add_to_free_list_tail so that it
>>>>>> will not insert pages behind the reported_boundary. Doing this allows us
>>>>>> to keep the overhead to a minimum as re-walking the list without the
>>>>>> boundary will result in as much as 18% additional overhead on a 32G VM.
>>>>>>
>>>>>>
>>>> <snip>
>>>>
>>>>>> As far as possible regressions I have focused on cases where performing
>>>>>> the hinting would be non-optimal, such as cases where the code isn't
>>>>>> needed as memory is not over-committed, or the functionality is not in
>>>>>> use. I have been using the will-it-scale/page_fault1 test running with 16
>>>>>> vcpus and have modified it to use Transparent Huge Pages. With this I see
>>>>>> almost no difference with the patches applied and the feature disabled.
>>>>>> Likewise I see almost no difference with the feature enabled, but the
>>>>>> madvise disabled in the hypervisor due to a device being assigned. With
>>>>>> the feature fully enabled in both guest and hypervisor I see a regression
>>>>>> between -1.86% and -8.84% versus the baseline. I found that most of the
>>>>>> overhead was due to the page faulting/zeroing that comes as a result of
>>>>>> the pages having been evicted from the guest.
>>>>> I think Michal asked for a performance comparison against Nitesh's
>>>>> approach, to evaluate if keeping the reported state + tracking inside
>>>>> the buddy is really worth it. Do you have any such numbers already? (or
>>>>> did my tired eyes miss them in this cover letter? :/)
>>>>>
>>>> I thought what Michal was asking for was what was the benefit of using the
>>>> boundary pointer. I added a bit up above and to the description for patch
>>>> 3 as on a 32G VM it adds up to about a 18% difference without factoring in
>>>> the page faulting and zeroing logic that occurs when we actually do the
>>>> madvise.
>>>>
>>>> Do we have a working patch set for Nitesh's code? The last time I tried
>>>> running his patch set I ran into issues with kernel panics. If we have a
>>>> known working/stable patch set I can give it a try.
>>> Did you try the v12 patch-set [1]?
>>> I remember that you reported the CPU stall issue, which I fixed in the v12.
>>>
>>> [1] https://lkml.org/lkml/2019/8/12/593
>> So I tried testing with the spin_lock calls replaced with spin_lock
>> _irq to resolve the IRQ issue. I also had shuffle enabled in order to
>> increase the number of pages being dirtied.
>>
>> With that setup the bitmap approach is running significantly worse
>> then my approach, even with the boundary removed. Since I had to
> It would make sense to share the setup+benchmark+performance indication
> that you measured. You don't have to share the actual numbers.

+1

>
>> modify the code to even getting working I am not comfortable posting
>> numbers. My suggestion would be to look at reworking the patch set and
>> post numbers for my patch set versus the bitmap approach and we can
>> look at them then. I would prefer not to spend my time fixing and
>> tuning a patch set that I am still not convinced is viable.
> I agree, I think Nitesh should work on his patch set and try to
> reproduce what you are seeing.

Sure.
I am always open to suggestions of different benchmarks/setup
where I can run my patch-set.

>
> Also, I think to make a precise statement of "which overhead comes with
> external tracking", Nitesh should switch to an approach (motivated by
> Michal) like
>
> 1. Sense lockless if a page is still free
> 2. start_isolate_page_range()
> -> Failed? Skip
> 3. test_pages_isolated()
> -> No? undo_isolate_page_range(), skip
> 4. Repeat for multiple pages + report
> 5. undo_isolate_page_range()
>
> That is the bare minimum any external tracking will need = some overhead
> for the tracking data. As a nice side effect, it get's rid of taking the
> zone lock manually AFAIKS.
>
> But that's unrelated to your series, only to quantify "how much" does
> external tracking actually cost.

Exactly, first, we need to be sure that the overhead caused by bitmap
scanning is not significant. If we are fine with the approach, I will
certainly look into this as this would be an excellent enhancement.

-- 
Thanks
Nitesh

Re: [PATCH v11 0/6] mm / virtio: Provide support for unused page reporting

[Alexander Duyck]

On Wed, Oct 2, 2019 at 3:37 AM Nitesh Narayan Lal <nitesh@redhat.com> wrote:
>
>
> On 10/1/19 8:55 PM, Alexander Duyck wrote:
> > On Tue, Oct 1, 2019 at 12:16 PM Nitesh Narayan Lal <nitesh@redhat.com> wrote:
> >>
> >> On 10/1/19 12:21 PM, Alexander Duyck wrote:
> >>> On Tue, 2019-10-01 at 17:35 +0200, David Hildenbrand wrote:
> >>>> On 01.10.19 17:29, Alexander Duyck wrote:

<snip>

> >>> Do we have a working patch set for Nitesh's code? The last time I tried
> >>> running his patch set I ran into issues with kernel panics. If we have a
> >>> known working/stable patch set I can give it a try.
> >> Did you try the v12 patch-set [1]?
> >> I remember that you reported the CPU stall issue, which I fixed in the v12.
> >>
> >> [1] https://lkml.org/lkml/2019/8/12/593
> > So I tried testing with the spin_lock calls replaced with spin_lock
> > _irq to resolve the IRQ issue. I also had shuffle enabled in order to
> > increase the number of pages being dirtied.
> >
> > With that setup the bitmap approach is running significantly worse
> > then my approach, even with the boundary removed. Since I had to
> > modify the code to even getting working I am not comfortable posting
> > numbers.
>
> I didn't face any issue in getting the code work or compile.
> Before my v12 posting, I did try your previously suggested test
> (will-it-scale/page_fault1 for 12 hours on a 60 GB) and didn't see any issues.
> I think it would help more if you can share the setup which you are running.

So one issue with the standard page_fault1 is that it is only
operating at the 4K page level. You won't see much impact from you
patches with that as the overhead of splitting a MAX_ORDER - 2 page
down to a 4K page will end up being the biggest thing you are
benchmarking.

I think I have brought it up before but I am running with the
page_fault1 modified to use THP. Making the change is pretty
straightforward as  all you have to do is add an madvise to the test
code. All that is needed is to add "madvise(c, MEMSIZE,
MADV_HUGEPAGE);" between the assert and the for loop in the
page_fault1 code and then rebuild the test. I actually copied
page_fault1.c into a file I named page_fault4.c and added the line. As
a result it seems like the code will build it as an additional test.

The only other alteration I can think of that might have much impact
would be to enable the page shuffling. The idea is that it will cause
us to use more pages because half of the pages freed are dumped to the
tail of the list so we are constantly churning the memory.

> > My suggestion would be to look at reworking the patch set and
> > post numbers for my patch set versus the bitmap approach and we can
> > look at them then.
>
> Agreed. However, in order to fix an issue I have to reproduce it first.

With the tweak I have suggested above it should make it much easier to
reproduce. Basically all you need is to have the allocation competing
against hinting. Currently the hinting isn't doing this because the
allocations are mostly coming out of 4K pages instead of higher order
ones.

Alternatively you could just make the suggestion I had proposed about
using spin_lock/unlock_irq in your worker thread and that resolved it
for me.

> >  I would prefer not to spend my time fixing and
> > tuning a patch set that I am still not convinced is viable.
>
> You  don't have to, I can fix the issues in my patch-set. :)

Sounds good. Hopefully the stuff I pointed out above helps you to get
a reproduction and resolve the issues.

- Alex

Re: [PATCH v11 0/6] mm / virtio: Provide support for unused page reporting

[Nitesh Narayan Lal]

On 10/2/19 10:25 AM, Alexander Duyck wrote:
> On Wed, Oct 2, 2019 at 3:37 AM Nitesh Narayan Lal <nitesh@redhat.com> wrote:
>>
>> On 10/1/19 8:55 PM, Alexander Duyck wrote:
>>> On Tue, Oct 1, 2019 at 12:16 PM Nitesh Narayan Lal <nitesh@redhat.com> wrote:
>>>> On 10/1/19 12:21 PM, Alexander Duyck wrote:
>>>>> On Tue, 2019-10-01 at 17:35 +0200, David Hildenbrand wrote:
>>>>>> On 01.10.19 17:29, Alexander Duyck wrote:
> <snip>
>
>>>>> Do we have a working patch set for Nitesh's code? The last time I tried
>>>>> running his patch set I ran into issues with kernel panics. If we have a
>>>>> known working/stable patch set I can give it a try.
>>>> Did you try the v12 patch-set [1]?
>>>> I remember that you reported the CPU stall issue, which I fixed in the v12.
>>>>
>>>> [1] https://lkml.org/lkml/2019/8/12/593
>>> So I tried testing with the spin_lock calls replaced with spin_lock
>>> _irq to resolve the IRQ issue. I also had shuffle enabled in order to
>>> increase the number of pages being dirtied.
>>>
>>> With that setup the bitmap approach is running significantly worse
>>> then my approach, even with the boundary removed. Since I had to
>>> modify the code to even getting working I am not comfortable posting
>>> numbers.
>> I didn't face any issue in getting the code work or compile.
>> Before my v12 posting, I did try your previously suggested test
>> (will-it-scale/page_fault1 for 12 hours on a 60 GB) and didn't see any issues.
>> I think it would help more if you can share the setup which you are running.
> So one issue with the standard page_fault1 is that it is only
> operating at the 4K page level. You won't see much impact from you
> patches with that as the overhead of splitting a MAX_ORDER - 2 page
> down to a 4K page will end up being the biggest thing you are
> benchmarking.
>
> I think I have brought it up before but I am running with the
> page_fault1 modified to use THP. Making the change is pretty
> straightforward as  all you have to do is add an madvise to the test
> code. All that is needed is to add "madvise(c, MEMSIZE,
> MADV_HUGEPAGE);" between the assert and the for loop in the
> page_fault1 code and then rebuild the test. I actually copied
> page_fault1.c into a file I named page_fault4.c and added the line. As
> a result it seems like the code will build it as an additional test.

Thanks for explaining.

>
> The only other alteration I can think of that might have much impact
> would be to enable the page shuffling. The idea is that it will cause
> us to use more pages because half of the pages freed are dumped to the
> tail of the list so we are constantly churning the memory.
>
>>> My suggestion would be to look at reworking the patch set and
>>> post numbers for my patch set versus the bitmap approach and we can
>>> look at them then.
>> Agreed. However, in order to fix an issue I have to reproduce it first.
> With the tweak I have suggested above it should make it much easier to
> reproduce. Basically all you need is to have the allocation competing
> against hinting. Currently the hinting isn't doing this because the
> allocations are mostly coming out of 4K pages instead of higher order
> ones.

Understood.

>
> Alternatively you could just make the suggestion I had proposed about
> using spin_lock/unlock_irq in your worker thread and that resolved it
> for me.

I will first reproduce as you suggested and then make the change.
That will help me to understand the issue in a better way.

>
>>>  I would prefer not to spend my time fixing and
>>> tuning a patch set that I am still not convinced is viable.
>> You  don't have to, I can fix the issues in my patch-set. :)
> Sounds good. Hopefully the stuff I pointed out above helps you to get
> a reproduction and resolve the issues.

Indeed, I will try these suggestions and fix this issue.
Did you run into any other issues while building or running?

>
> - Alex

-- 
Thanks
Nitesh

Re: [virtio-dev] Re: [PATCH v11 0/6] mm / virtio: Provide support for unused page reporting

[Nitesh Narayan Lal]

On 10/1/19 4:25 PM, Alexander Duyck wrote:
> On Tue, 2019-10-01 at 15:16 -0400, Nitesh Narayan Lal wrote:
>> On 10/1/19 12:21 PM, Alexander Duyck wrote:
>>> On Tue, 2019-10-01 at 17:35 +0200, David Hildenbrand wrote:
>>>> On 01.10.19 17:29, Alexander Duyck wrote:
> <snip>
>
>>>>> As far as possible regressions I have focused on cases where performing
>>>>> the hinting would be non-optimal, such as cases where the code isn't
>>>>> needed as memory is not over-committed, or the functionality is not in
>>>>> use. I have been using the will-it-scale/page_fault1 test running with 16
>>>>> vcpus and have modified it to use Transparent Huge Pages. With this I see
>>>>> almost no difference with the patches applied and the feature disabled.
>>>>> Likewise I see almost no difference with the feature enabled, but the
>>>>> madvise disabled in the hypervisor due to a device being assigned. With
>>>>> the feature fully enabled in both guest and hypervisor I see a regression
>>>>> between -1.86% and -8.84% versus the baseline. I found that most of the
>>>>> overhead was due to the page faulting/zeroing that comes as a result of
>>>>> the pages having been evicted from the guest.
>>>> I think Michal asked for a performance comparison against Nitesh's
>>>> approach, to evaluate if keeping the reported state + tracking inside
>>>> the buddy is really worth it. Do you have any such numbers already? (or
>>>> did my tired eyes miss them in this cover letter? :/)
>>>>
>>> I thought what Michal was asking for was what was the benefit of using the
>>> boundary pointer. I added a bit up above and to the description for patch
>>> 3 as on a 32G VM it adds up to about a 18% difference without factoring in
>>> the page faulting and zeroing logic that occurs when we actually do the
>>> madvise.
>>>
>>> Do we have a working patch set for Nitesh's code? The last time I tried
>>> running his patch set I ran into issues with kernel panics. If we have a
>>> known working/stable patch set I can give it a try.
>> Did you try the v12 patch-set [1]?
>> I remember that you reported the CPU stall issue, which I fixed in the v12.
>>
>> [1] https://lkml.org/lkml/2019/8/12/593
>>
>>> - Alex
>>>
> I haven't tested it. I will pull the patches and give it a try. It works
> with the same QEMU changes that mine does right? If so we should be able
> to get an apples-to-apples comparison.

Yes.

>
> Also, instead of providing lkml.org links to your patches in the future it
> might be better to provide a link to the lore.kernel.org version of the
> thread. So for example the v12 set would be:
> https://lore.kernel.org/lkml/20190812131235.27244-1-nitesh@redhat.com/

I see, I will keep that in mind. Thanks for pointing this out.

>
> The advantage is you can just look up the message ID in your own inbox to
> figure out the link, and it provides raw access to the email if needed.
>
> Thanks.
>
> - Alex
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
>
-- 
Thanks
Nitesh

Re: [PATCH v11 0/6] mm / virtio: Provide support for unused page reporting

[Nitesh Narayan Lal]

On 10/1/19 4:51 PM, Dave Hansen wrote:
> On 10/1/19 1:49 PM, Alexander Duyck wrote:
>> So it looks like v12 still has issues. I'm pretty sure you should be using
>> spin_lock_irq(), not spin_lock() in page_reporting.c to avoid the
>> possibility of an IRQ firing and causing lock recursion on the zone lock.
> Lockdep should make all of this a lot easier to find.  Is it being used?

I do have it in the function which returns the pages to the buddy but I missed
it in the function that isolates the pages.
I will correct this.


-- 
Thanks
Nitesh

Re: [PATCH v11 0/6] mm / virtio: Provide support for unused page reporting

[Nitesh Narayan Lal]

On 10/2/19 10:25 AM, Alexander Duyck wrote:

[...]
>>> My suggestion would be to look at reworking the patch set and
>>> post numbers for my patch set versus the bitmap approach and we can
>>> look at them then.
>> Agreed. However, in order to fix an issue I have to reproduce it first.
> With the tweak I have suggested above it should make it much easier to
> reproduce. Basically all you need is to have the allocation competing
> against hinting. Currently the hinting isn't doing this because the
> allocations are mostly coming out of 4K pages instead of higher order
> ones.
>
> Alternatively you could just make the suggestion I had proposed about
> using spin_lock/unlock_irq in your worker thread and that resolved it
> for me.
>
>>>  I would prefer not to spend my time fixing and
>>> tuning a patch set that I am still not convinced is viable.
>> You  don't have to, I can fix the issues in my patch-set. :)
> Sounds good. Hopefully the stuff I pointed out above helps you to get
> a reproduction and resolve the issues.


So I did observe a significant drop in running my v12 path-set [1] with the
suggested test setup. However, on making certain changes the performance
improved significantly.

I used my v12 patch-set which I have posted earlier and made the following
changes:
1. Started reporting only (MAX_ORDER - 1) pages and increased the number of
    pages that can be reported at a time to 32 from 16. The intent of making
    these changes was to bring my configuration closer to what Alexander is
    using.
2. I made an additional change in my bitmap scanning logic to prevent acquiring
    spinlock if the page is already allocated.


Setup:
On a 16 vCPU 30 GB single NUMA guest affined to a single host NUMA, I ran the
modified will-it-scale/page_fault number of times and calculated the average
of the number of process and threads launched on the 16th core to compare the
impact of my patch-set against an unmodified kernel.


Conclusion:
%Drop in number of processes launched on 16th vCPU =     1-2%
%Drop in number of threads launched on 16th vCPU     =     5-6%


Other observations:
- I also tried running Alexander's latest v11 page-reporting patch set and
  observe a similar amount of average degradation in the number of processes
  and threads.
- I didn't include the linear component recorded by will-it-scale because for
  some reason it was fluctuating too much even when I was using an unmodified
  kernel. If required I can investigate this further.

Note: If there is a better way to analyze the will-it-scale/page_fault results
then please do let me know.


Other setup details:
Following are the configurations which I enabled to run my tests:
- Enabled: CONFIG_SLAB_FREELIST_RANDOM & CONFIG_SHUFFLE_PAGE_ALLOCATOR
- Set host THP to always
- Set guest THP to madvise
- Added the suggested madvise call in page_fault source code.
@Alexander please let me know if I missed something.


The current state of my v13:
I still have to look into Michal's suggestion of using page-isolation API's
instead of isolating the page. However, I believe at this moment our objective
is to decide with which approach we can proceed and that's why I decided to
post the numbers by making small required changes in v12 instead of posting a
new series.


Following are the changes which I have made on top of my v12:

page_reporting.h change:
-#define PAGE_REPORTING_MIN_ORDER               (MAX_ORDER - 2)
-#define PAGE_REPORTING_MAX_PAGES               16
+#define PAGE_REPORTING_MIN_ORDER              (MAX_ORDER - 1)
+#define PAGE_REPORTING_MAX_PAGES              32

page_reporting.c change:
@@ -101,8 +101,12 @@ static void scan_zone_bitmap(struct page_reporting_config
*phconf,
                /* Process only if the page is still online */
                page = pfn_to_online_page((setbit << PAGE_REPORTING_MIN_ORDER) +
                                          zone->base_pfn);
-               if (!page)
+               if (!page || !PageBuddy(page)) {
+                       clear_bit(setbit, zone->bitmap);
+                       atomic_dec(&zone->free_pages);
                        continue;
+               }

@Alexander in case you decide to give it a try and find different results,
please do let me know.

[1] https://lore.kernel.org/lkml/20190812131235.27244-1-nitesh@redhat.com/


-- 
Thanks
Nitesh

Re: [PATCH v11 0/6] mm / virtio: Provide support for unused page reporting

[Alexander Duyck]

On Mon, 2019-10-07 at 08:29 -0400, Nitesh Narayan Lal wrote:
> On 10/2/19 10:25 AM, Alexander Duyck wrote:
> 
> [...]
> > > > My suggestion would be to look at reworking the patch set and
> > > > post numbers for my patch set versus the bitmap approach and we can
> > > > look at them then.
> > > Agreed. However, in order to fix an issue I have to reproduce it first.
> > With the tweak I have suggested above it should make it much easier to
> > reproduce. Basically all you need is to have the allocation competing
> > against hinting. Currently the hinting isn't doing this because the
> > allocations are mostly coming out of 4K pages instead of higher order
> > ones.
> > 
> > Alternatively you could just make the suggestion I had proposed about
> > using spin_lock/unlock_irq in your worker thread and that resolved it
> > for me.
> > 
> > > >  I would prefer not to spend my time fixing and
> > > > tuning a patch set that I am still not convinced is viable.
> > > You  don't have to, I can fix the issues in my patch-set. :)
> > Sounds good. Hopefully the stuff I pointed out above helps you to get
> > a reproduction and resolve the issues.
> 
> So I did observe a significant drop in running my v12 path-set [1] with the
> suggested test setup. However, on making certain changes the performance
> improved significantly.
> 
> I used my v12 patch-set which I have posted earlier and made the following
> changes:
> 1. Started reporting only (MAX_ORDER - 1) pages and increased the number of
>     pages that can be reported at a time to 32 from 16. The intent of making
>     these changes was to bring my configuration closer to what Alexander is
>     using.

The increase from 16 to 32 is valid. No point in working in too small of
batches. However tightening the order to only test for MAX_ORDER - 1 seems
like a step in the wrong direction. The bitmap approach doesn't have much
value if it can only work with the highest order page. I realize it is
probably necessary in order to make the trick for checking on page_buddy
work, but it seems very limiting.

> 2. I made an additional change in my bitmap scanning logic to prevent acquiring
>     spinlock if the page is already allocated.

Again, not a fan. It basically means you can only work with MAX_ORDER - 1
and there will be no ability to work with anything smaller.

> 
> Setup:
> On a 16 vCPU 30 GB single NUMA guest affined to a single host NUMA, I ran the
> modified will-it-scale/page_fault number of times and calculated the average
> of the number of process and threads launched on the 16th core to compare the
> impact of my patch-set against an unmodified kernel.
> 
> 
> Conclusion:
> %Drop in number of processes launched on 16th vCPU =     1-2%
> %Drop in number of threads launched on 16th vCPU     =     5-6%

These numbers don't make that much sense to me. Are you talking about a
fully functioning setup that is madvsing away the memory in the
hypervisor? If so I would have expected a much higher difference versus
baseline as zeroing/faulting the pages in the host gets expensive fairly
quick. What is the host kernel you are running your test on? I'm just
wondering if there is some additional overhead currently limiting your
setup. My host kernel was just the same kernel I was running in the guest,
just built without the patches applied.

> Other observations:
> - I also tried running Alexander's latest v11 page-reporting patch set and
>   observe a similar amount of average degradation in the number of processes
>   and threads.
> - I didn't include the linear component recorded by will-it-scale because for
>   some reason it was fluctuating too much even when I was using an unmodified
>   kernel. If required I can investigate this further.
> 
> Note: If there is a better way to analyze the will-it-scale/page_fault results
> then please do let me know.

Honestly I have mostly just focused on the processes performance. There is
usually a fair bit of variability but a pattern forms after a few runs so
you can generally tell if a configuration is an improvement or not.

> Other setup details:
> Following are the configurations which I enabled to run my tests:
> - Enabled: CONFIG_SLAB_FREELIST_RANDOM & CONFIG_SHUFFLE_PAGE_ALLOCATOR
> - Set host THP to always
> - Set guest THP to madvise
> - Added the suggested madvise call in page_fault source code.
> @Alexander please let me know if I missed something.

This seems about right.

> The current state of my v13:
> I still have to look into Michal's suggestion of using page-isolation API's
> instead of isolating the page. However, I believe at this moment our objective
> is to decide with which approach we can proceed and that's why I decided to
> post the numbers by making small required changes in v12 instead of posting a
> new series.
> 
> 
> Following are the changes which I have made on top of my v12:
> 
> page_reporting.h change:
> -#define PAGE_REPORTING_MIN_ORDER               (MAX_ORDER - 2)
> -#define PAGE_REPORTING_MAX_PAGES               16
> +#define PAGE_REPORTING_MIN_ORDER              (MAX_ORDER - 1)
> +#define PAGE_REPORTING_MAX_PAGES              32
> 
> page_reporting.c change:
> @@ -101,8 +101,12 @@ static void scan_zone_bitmap(struct page_reporting_config
> *phconf,
>                 /* Process only if the page is still online */
>                 page = pfn_to_online_page((setbit << PAGE_REPORTING_MIN_ORDER) +
>                                           zone->base_pfn);
> -               if (!page)
> +               if (!page || !PageBuddy(page)) {
> +                       clear_bit(setbit, zone->bitmap);
> +                       atomic_dec(&zone->free_pages);
>                         continue;
> +               }
> 

I suspect the zone->free_pages is going to be expensive for you to deal
with. It is a global atomic value and is going to have the cacheline
bouncing that it is contained in. As a result thinks like setting the
bitmap with be more expensive as every tome a CPU increments free_pages it
will likely have to take the cache line containing the bitmap pointer as
well.

> @Alexander in case you decide to give it a try and find different results,
> please do let me know.
> 
> [1] https://lore.kernel.org/lkml/20190812131235.27244-1-nitesh@redhat.com/
> 
> 

If I have some free time I will take a look. However one thing that
concerns me about this change is that it will limit things much further in
terms of how much memory can ultimately be freed since you are now only
working with the highest order page and that becomes a hard requirement
for your design.

Re: [PATCH v11 0/6] mm / virtio: Provide support for unused page reporting

[Nitesh Narayan Lal]

On 10/7/19 11:33 AM, Alexander Duyck wrote:
> On Mon, 2019-10-07 at 08:29 -0400, Nitesh Narayan Lal wrote:
>> On 10/2/19 10:25 AM, Alexander Duyck wrote:
>>
[...]
>> You  don't have to, I can fix the issues in my patch-set. :)
>>> Sounds good. Hopefully the stuff I pointed out above helps you to get
>>> a reproduction and resolve the issues.
>> So I did observe a significant drop in running my v12 path-set [1] with the
>> suggested test setup. However, on making certain changes the performance
>> improved significantly.
>>
>> I used my v12 patch-set which I have posted earlier and made the following
>> changes:
>> 1. Started reporting only (MAX_ORDER - 1) pages and increased the number of
>>     pages that can be reported at a time to 32 from 16. The intent of making
>>     these changes was to bring my configuration closer to what Alexander is
>>     using.
> The increase from 16 to 32 is valid. No point in working in too small of
> batches. However tightening the order to only test for MAX_ORDER - 1 seems
> like a step in the wrong direction. The bitmap approach doesn't have much
> value if it can only work with the highest order page. I realize it is
> probably necessary in order to make the trick for checking on page_buddy
> work, but it seems very limiting.

If using (pageblock_order - 1) is a better way to do this, then I can probably
switch to that.
I will agree with the fact that we have to make the reporting order
configurable, atleast to an extent.

>
>> 2. I made an additional change in my bitmap scanning logic to prevent acquiring
>>     spinlock if the page is already allocated.
> Again, not a fan. It basically means you can only work with MAX_ORDER - 1
> and there will be no ability to work with anything smaller.
>
>> Setup:
>> On a 16 vCPU 30 GB single NUMA guest affined to a single host NUMA, I ran the
>> modified will-it-scale/page_fault number of times and calculated the average
>> of the number of process and threads launched on the 16th core to compare the
>> impact of my patch-set against an unmodified kernel.
>>
>>
>> Conclusion:
>> %Drop in number of processes launched on 16th vCPU =     1-2%
>> %Drop in number of threads launched on 16th vCPU     =     5-6%
> These numbers don't make that much sense to me. Are you talking about a
> fully functioning setup that is madvsing away the memory in the
> hypervisor?


Without making this change I was observing a significant amount of drop
in the number of processes and specifically in the number of threads.
I did a double-check of the configuration which I have shared.
I was also observing the "AnonHugePages" via meminfo to check the THP usage.
Any more suggestions about what else I can do to verify?
I will be more than happy to try them out.

>  If so I would have expected a much higher difference versus
> baseline as zeroing/faulting the pages in the host gets expensive fairly
> quick. What is the host kernel you are running your test on? I'm just
> wondering if there is some additional overhead currently limiting your
> setup. My host kernel was just the same kernel I was running in the guest,
> just built without the patches applied.

Right now I have a different host-kernel. I can install the same kernel to the
host as well and see if that changes anything.

>
>> Other observations:
>> - I also tried running Alexander's latest v11 page-reporting patch set and
>>   observe a similar amount of average degradation in the number of processes
>>   and threads.
>> - I didn't include the linear component recorded by will-it-scale because for
>>   some reason it was fluctuating too much even when I was using an unmodified
>>   kernel. If required I can investigate this further.
>>
>> Note: If there is a better way to analyze the will-it-scale/page_fault results
>> then please do let me know.
> Honestly I have mostly just focused on the processes performance.

In my observation processes seems to be most consistent in general.

>  There is
> usually a fair bit of variability but a pattern forms after a few runs so
> you can generally tell if a configuration is an improvement or not.

Yeah, that's why I thought of taking the average of 5-6 runs.

>
>> Other setup details:
>> Following are the configurations which I enabled to run my tests:
>> - Enabled: CONFIG_SLAB_FREELIST_RANDOM & CONFIG_SHUFFLE_PAGE_ALLOCATOR
>> - Set host THP to always
>> - Set guest THP to madvise
>> - Added the suggested madvise call in page_fault source code.
>> @Alexander please let me know if I missed something.
> This seems about right.
>
>> The current state of my v13:
>> I still have to look into Michal's suggestion of using page-isolation API's
>> instead of isolating the page. However, I believe at this moment our objective
>> is to decide with which approach we can proceed and that's why I decided to
>> post the numbers by making small required changes in v12 instead of posting a
>> new series.
>>
>>
>> Following are the changes which I have made on top of my v12:
>>
>> page_reporting.h change:
>> -#define PAGE_REPORTING_MIN_ORDER               (MAX_ORDER - 2)
>> -#define PAGE_REPORTING_MAX_PAGES               16
>> +#define PAGE_REPORTING_MIN_ORDER              (MAX_ORDER - 1)
>> +#define PAGE_REPORTING_MAX_PAGES              32
>>
>> page_reporting.c change:
>> @@ -101,8 +101,12 @@ static void scan_zone_bitmap(struct page_reporting_config
>> *phconf,
>>                 /* Process only if the page is still online */
>>                 page = pfn_to_online_page((setbit << PAGE_REPORTING_MIN_ORDER) +
>>                                           zone->base_pfn);
>> -               if (!page)
>> +               if (!page || !PageBuddy(page)) {
>> +                       clear_bit(setbit, zone->bitmap);
>> +                       atomic_dec(&zone->free_pages);
>>                         continue;
>> +               }
>>
> I suspect the zone->free_pages is going to be expensive for you to deal
> with. It is a global atomic value and is going to have the cacheline
> bouncing that it is contained in. As a result thinks like setting the
> bitmap with be more expensive as every tome a CPU increments free_pages it
> will likely have to take the cache line containing the bitmap pointer as
> well.

I see I will have to explore this more. I am wondering if there is a way to
measure this If its effect is not visible in will-it-scale/page_fault1. If
there is a noticeable amount of degradation, I will have to address this.

>
>> @Alexander in case you decide to give it a try and find different results,
>> please do let me know.
>>
>> [1] https://lore.kernel.org/lkml/20190812131235.27244-1-nitesh@redhat.com/
>>
>>
> If I have some free time I will take a look.

That would be great, thanks.

>  However one thing that
> concerns me about this change is that it will limit things much further in
> terms of how much memory can ultimately be freed since you are now only
> working with the highest order page and that becomes a hard requirement
> for your design.

I would assume that should be resolved with (pageblock_order - 1).

>
-- 
Nitesh

Re: [PATCH v11 0/6] mm / virtio: Provide support for unused page reporting

[Alexander Duyck]

On Mon, 2019-10-07 at 12:19 -0400, Nitesh Narayan Lal wrote:
> On 10/7/19 11:33 AM, Alexander Duyck wrote:
> > On Mon, 2019-10-07 at 08:29 -0400, Nitesh Narayan Lal wrote:
> > > On 10/2/19 10:25 AM, Alexander Duyck wrote:
> > > 
> [...]
> > > You  don't have to, I can fix the issues in my patch-set. :)
> > > > Sounds good. Hopefully the stuff I pointed out above helps you to get
> > > > a reproduction and resolve the issues.
> > > So I did observe a significant drop in running my v12 path-set [1] with the
> > > suggested test setup. However, on making certain changes the performance
> > > improved significantly.
> > > 
> > > I used my v12 patch-set which I have posted earlier and made the following
> > > changes:
> > > 1. Started reporting only (MAX_ORDER - 1) pages and increased the number of
> > >     pages that can be reported at a time to 32 from 16. The intent of making
> > >     these changes was to bring my configuration closer to what Alexander is
> > >     using.
> > The increase from 16 to 32 is valid. No point in working in too small of
> > batches. However tightening the order to only test for MAX_ORDER - 1 seems
> > like a step in the wrong direction. The bitmap approach doesn't have much
> > value if it can only work with the highest order page. I realize it is
> > probably necessary in order to make the trick for checking on page_buddy
> > work, but it seems very limiting.
> 
> If using (pageblock_order - 1) is a better way to do this, then I can probably
> switch to that.
> I will agree with the fact that we have to make the reporting order
> configurable, atleast to an extent.

I think you mean pageblock_order, not pageblock_order - 1. The problem
with pageblock_order - 1 is that it will have a negative impact on
performance as it would disable THP.

> > > 2. I made an additional change in my bitmap scanning logic to prevent acquiring
> > >     spinlock if the page is already allocated.
> > Again, not a fan. It basically means you can only work with MAX_ORDER - 1
> > and there will be no ability to work with anything smaller.
> > 
> > > Setup:
> > > On a 16 vCPU 30 GB single NUMA guest affined to a single host NUMA, I ran the
> > > modified will-it-scale/page_fault number of times and calculated the average
> > > of the number of process and threads launched on the 16th core to compare the
> > > impact of my patch-set against an unmodified kernel.
> > > 
> > > 
> > > Conclusion:
> > > %Drop in number of processes launched on 16th vCPU =     1-2%
> > > %Drop in number of threads launched on 16th vCPU     =     5-6%
> > These numbers don't make that much sense to me. Are you talking about a
> > fully functioning setup that is madvsing away the memory in the
> > hypervisor?
> 
> Without making this change I was observing a significant amount of drop
> in the number of processes and specifically in the number of threads.
> I did a double-check of the configuration which I have shared.
> I was also observing the "AnonHugePages" via meminfo to check the THP usage.
> Any more suggestions about what else I can do to verify?
> I will be more than happy to try them out.

So what was the size of your guest? One thing that just occurred to me is
that you might be running a much smaller guest than I was.

> >  If so I would have expected a much higher difference versus
> > baseline as zeroing/faulting the pages in the host gets expensive fairly
> > quick. What is the host kernel you are running your test on? I'm just
> > wondering if there is some additional overhead currently limiting your
> > setup. My host kernel was just the same kernel I was running in the guest,
> > just built without the patches applied.
> 
> Right now I have a different host-kernel. I can install the same kernel to the
> host as well and see if that changes anything.

The host kernel will have a fairly significant impact as I recall. For
example running a stock CentOS kernel lowered the performance compared to
running a linux-next kernel. As a result the numbers looked better since
the overall baseline was lower to begin with as the host OS was
introducing additional overhead.

> > > Other observations:
> > > - I also tried running Alexander's latest v11 page-reporting patch set and
> > >   observe a similar amount of average degradation in the number of processes
> > >   and threads.
> > > - I didn't include the linear component recorded by will-it-scale because for
> > >   some reason it was fluctuating too much even when I was using an unmodified
> > >   kernel. If required I can investigate this further.
> > > 
> > > Note: If there is a better way to analyze the will-it-scale/page_fault results
> > > then please do let me know.
> > Honestly I have mostly just focused on the processes performance.
> 
> In my observation processes seems to be most consistent in general.

Agreed.

> >  There is
> > usually a fair bit of variability but a pattern forms after a few runs so
> > you can generally tell if a configuration is an improvement or not.
> 
> Yeah, that's why I thought of taking the average of 5-6 runs.

Same here. I am usually running about 5 iterations.

> > > Other setup details:
> > > Following are the configurations which I enabled to run my tests:
> > > - Enabled: CONFIG_SLAB_FREELIST_RANDOM & CONFIG_SHUFFLE_PAGE_ALLOCATOR
> > > - Set host THP to always
> > > - Set guest THP to madvise
> > > - Added the suggested madvise call in page_fault source code.
> > > @Alexander please let me know if I missed something.
> > This seems about right.
> > 
> > > The current state of my v13:
> > > I still have to look into Michal's suggestion of using page-isolation API's
> > > instead of isolating the page. However, I believe at this moment our objective
> > > is to decide with which approach we can proceed and that's why I decided to
> > > post the numbers by making small required changes in v12 instead of posting a
> > > new series.
> > > 
> > > 
> > > Following are the changes which I have made on top of my v12:
> > > 
> > > page_reporting.h change:
> > > -#define PAGE_REPORTING_MIN_ORDER               (MAX_ORDER - 2)
> > > -#define PAGE_REPORTING_MAX_PAGES               16
> > > +#define PAGE_REPORTING_MIN_ORDER              (MAX_ORDER - 1)
> > > +#define PAGE_REPORTING_MAX_PAGES              32
> > > 
> > > page_reporting.c change:
> > > @@ -101,8 +101,12 @@ static void scan_zone_bitmap(struct page_reporting_config
> > > *phconf,
> > >                 /* Process only if the page is still online */
> > >                 page = pfn_to_online_page((setbit << PAGE_REPORTING_MIN_ORDER) +
> > >                                           zone->base_pfn);
> > > -               if (!page)
> > > +               if (!page || !PageBuddy(page)) {
> > > +                       clear_bit(setbit, zone->bitmap);
> > > +                       atomic_dec(&zone->free_pages);
> > >                         continue;
> > > +               }
> > > 
> > I suspect the zone->free_pages is going to be expensive for you to deal
> > with. It is a global atomic value and is going to have the cacheline
> > bouncing that it is contained in. As a result thinks like setting the
> > bitmap with be more expensive as every tome a CPU increments free_pages it
> > will likely have to take the cache line containing the bitmap pointer as
> > well.
> 
> I see I will have to explore this more. I am wondering if there is a way to
> measure this If its effect is not visible in will-it-scale/page_fault1. If
> there is a noticeable amount of degradation, I will have to address this.

If nothing else you might look at seeing if you can split up the
structures so that the bitmap and nr_bits is in a different region
somewhere since those are read-mostly values.

Also you are now updating the bitmap and free_pages both inside and
outside of the zone lock so that will likely have some impact.

> > > @Alexander in case you decide to give it a try and find different results,
> > > please do let me know.
> > > 
> > > [1] https://lore.kernel.org/lkml/20190812131235.27244-1-nitesh@redhat.com/
> > > 
> > > 
> > If I have some free time I will take a look.
> 
> That would be great, thanks.
> 
> >  However one thing that
> > concerns me about this change is that it will limit things much further in
> > terms of how much memory can ultimately be freed since you are now only
> > working with the highest order page and that becomes a hard requirement
> > for your design.
> 
> I would assume that should be resolved with (pageblock_order - 1).

There is no need for the - 1. The pageblock_order value is the lowest you
can go before you start causing THP to be disabled. If you cross that
threshold the performance will drop significantly. 

Re: [PATCH v11 0/6] mm / virtio: Provide support for unused page reporting

[Nitesh Narayan Lal]

On 10/7/19 12:27 PM, Alexander Duyck wrote:
> On Mon, 2019-10-07 at 12:19 -0400, Nitesh Narayan Lal wrote:
>> On 10/7/19 11:33 AM, Alexander Duyck wrote:
>>> On Mon, 2019-10-07 at 08:29 -0400, Nitesh Narayan Lal wrote:
>>>> On 10/2/19 10:25 AM, Alexander Duyck wrote:
>>>>
>> [...]
>>>> You  don't have to, I can fix the issues in my patch-set. :)
>>>>> Sounds good. Hopefully the stuff I pointed out above helps you to get
>>>>> a reproduction and resolve the issues.
>>>> So I did observe a significant drop in running my v12 path-set [1] with the
>>>> suggested test setup. However, on making certain changes the performance
>>>> improved significantly.
>>>>
>>>> I used my v12 patch-set which I have posted earlier and made the following
>>>> changes:
>>>> 1. Started reporting only (MAX_ORDER - 1) pages and increased the number of
>>>>     pages that can be reported at a time to 32 from 16. The intent of making
>>>>     these changes was to bring my configuration closer to what Alexander is
>>>>     using.
>>> The increase from 16 to 32 is valid. No point in working in too small of
>>> batches. However tightening the order to only test for MAX_ORDER - 1 seems
>>> like a step in the wrong direction. The bitmap approach doesn't have much
>>> value if it can only work with the highest order page. I realize it is
>>> probably necessary in order to make the trick for checking on page_buddy
>>> work, but it seems very limiting.
>> If using (pageblock_order - 1) is a better way to do this, then I can probably
>> switch to that.
>> I will agree with the fact that we have to make the reporting order
>> configurable, atleast to an extent.
> I think you mean pageblock_order, not pageblock_order - 1. The problem
> with pageblock_order - 1 is that it will have a negative impact on
> performance as it would disable THP.

Ah, I see. Yes my bad.

>
>>>> 2. I made an additional change in my bitmap scanning logic to prevent acquiring
>>>>     spinlock if the page is already allocated.
>>> Again, not a fan. It basically means you can only work with MAX_ORDER - 1
>>> and there will be no ability to work with anything smaller.
>>>
>>>> Setup:
>>>> On a 16 vCPU 30 GB single NUMA guest affined to a single host NUMA, I ran the
>>>> modified will-it-scale/page_fault number of times and calculated the average
>>>> of the number of process and threads launched on the 16th core to compare the
>>>> impact of my patch-set against an unmodified kernel.
>>>>
>>>>
>>>> Conclusion:
>>>> %Drop in number of processes launched on 16th vCPU =     1-2%
>>>> %Drop in number of threads launched on 16th vCPU     =     5-6%
>>> These numbers don't make that much sense to me. Are you talking about a
>>> fully functioning setup that is madvsing away the memory in the
>>> hypervisor?
>> Without making this change I was observing a significant amount of drop
>> in the number of processes and specifically in the number of threads.
>> I did a double-check of the configuration which I have shared.
>> I was also observing the "AnonHugePages" via meminfo to check the THP usage.
>> Any more suggestions about what else I can do to verify?
>> I will be more than happy to try them out.
> So what was the size of your guest? One thing that just occurred to me is
> that you might be running a much smaller guest than I was.

I am running a 30 GB guest.

>
>>>  If so I would have expected a much higher difference versus
>>> baseline as zeroing/faulting the pages in the host gets expensive fairly
>>> quick. What is the host kernel you are running your test on? I'm just
>>> wondering if there is some additional overhead currently limiting your
>>> setup. My host kernel was just the same kernel I was running in the guest,
>>> just built without the patches applied.
>> Right now I have a different host-kernel. I can install the same kernel to the
>> host as well and see if that changes anything.
> The host kernel will have a fairly significant impact as I recall. For
> example running a stock CentOS kernel lowered the performance compared to
> running a linux-next kernel. As a result the numbers looked better since
> the overall baseline was lower to begin with as the host OS was
> introducing additional overhead.

I see in that case I will try by installing the same guest kernel
to the host as well.

>
>>>> Other observations:
>>>> - I also tried running Alexander's latest v11 page-reporting patch set and
>>>>   observe a similar amount of average degradation in the number of processes
>>>>   and threads.
>>>> - I didn't include the linear component recorded by will-it-scale because for
>>>>   some reason it was fluctuating too much even when I was using an unmodified
>>>>   kernel. If required I can investigate this further.
>>>>
>>>> Note: If there is a better way to analyze the will-it-scale/page_fault results
>>>> then please do let me know.
>>> Honestly I have mostly just focused on the processes performance.
>> In my observation processes seems to be most consistent in general.
> Agreed.
>
>>>  There is
>>> usually a fair bit of variability but a pattern forms after a few runs so
>>> you can generally tell if a configuration is an improvement or not.
>> Yeah, that's why I thought of taking the average of 5-6 runs.
> Same here. I am usually running about 5 iterations.
>
>>>> Other setup details:
>>>> Following are the configurations which I enabled to run my tests:
>>>> - Enabled: CONFIG_SLAB_FREELIST_RANDOM & CONFIG_SHUFFLE_PAGE_ALLOCATOR
>>>> - Set host THP to always
>>>> - Set guest THP to madvise
>>>> - Added the suggested madvise call in page_fault source code.
>>>> @Alexander please let me know if I missed something.
>>> This seems about right.
>>>
>>>> The current state of my v13:
>>>> I still have to look into Michal's suggestion of using page-isolation API's
>>>> instead of isolating the page. However, I believe at this moment our objective
>>>> is to decide with which approach we can proceed and that's why I decided to
>>>> post the numbers by making small required changes in v12 instead of posting a
>>>> new series.
>>>>
>>>>
>>>> Following are the changes which I have made on top of my v12:
>>>>
>>>> page_reporting.h change:
>>>> -#define PAGE_REPORTING_MIN_ORDER               (MAX_ORDER - 2)
>>>> -#define PAGE_REPORTING_MAX_PAGES               16
>>>> +#define PAGE_REPORTING_MIN_ORDER              (MAX_ORDER - 1)
>>>> +#define PAGE_REPORTING_MAX_PAGES              32
>>>>
>>>> page_reporting.c change:
>>>> @@ -101,8 +101,12 @@ static void scan_zone_bitmap(struct page_reporting_config
>>>> *phconf,
>>>>                 /* Process only if the page is still online */
>>>>                 page = pfn_to_online_page((setbit << PAGE_REPORTING_MIN_ORDER) +
>>>>                                           zone->base_pfn);
>>>> -               if (!page)
>>>> +               if (!page || !PageBuddy(page)) {
>>>> +                       clear_bit(setbit, zone->bitmap);
>>>> +                       atomic_dec(&zone->free_pages);
>>>>                         continue;
>>>> +               }
>>>>
>>> I suspect the zone->free_pages is going to be expensive for you to deal
>>> with. It is a global atomic value and is going to have the cacheline
>>> bouncing that it is contained in. As a result thinks like setting the
>>> bitmap with be more expensive as every tome a CPU increments free_pages it
>>> will likely have to take the cache line containing the bitmap pointer as
>>> well.
>> I see I will have to explore this more. I am wondering if there is a way to
>> measure this If its effect is not visible in will-it-scale/page_fault1. If
>> there is a noticeable amount of degradation, I will have to address this.
> If nothing else you might look at seeing if you can split up the
> structures so that the bitmap and nr_bits is in a different region
> somewhere since those are read-mostly values.

ok, I will try to understand the issue and your suggestion.
Thank you for bringing this up.

> Also you are now updating the bitmap and free_pages both inside and
> outside of the zone lock so that will likely have some impact.

So as per your previous suggestion, I have made the bitmap structure
object as a rcu protected pointer. So we are safe from that side.
The other downside which I can think of is a race where one page
trying to increment free_pages and other trying to decrements it.
However, being an atomic variable that should not be a problem.
Did I miss anything?    


>
>>>> @Alexander in case you decide to give it a try and find different results,
>>>> please do let me know.
>>>>
>>>> [1] https://lore.kernel.org/lkml/20190812131235.27244-1-nitesh@redhat.com/
>>>>
>>>>
>>> If I have some free time I will take a look.
>> That would be great, thanks.
>>
>>>  However one thing that
>>> concerns me about this change is that it will limit things much further in
>>> terms of how much memory can ultimately be freed since you are now only
>>> working with the highest order page and that becomes a hard requirement
>>> for your design.
>> I would assume that should be resolved with (pageblock_order - 1).
> There is no need for the - 1. The pageblock_order value is the lowest you
> can go before you start causing THP to be disabled. If you cross that
> threshold the performance will drop significantly. 


Makes sense.


--
Nitesh

Re: [PATCH v11 0/6] mm / virtio: Provide support for unused page reporting

[Alexander Duyck]

On Mon, Oct 7, 2019 at 10:07 AM Nitesh Narayan Lal <nitesh@redhat.com> wrote:
>
>
> On 10/7/19 12:27 PM, Alexander Duyck wrote:
> > On Mon, 2019-10-07 at 12:19 -0400, Nitesh Narayan Lal wrote:
> >> On 10/7/19 11:33 AM, Alexander Duyck wrote:
> >>> On Mon, 2019-10-07 at 08:29 -0400, Nitesh Narayan Lal wrote:
> >>>> On 10/2/19 10:25 AM, Alexander Duyck wrote:

<snip>

> >>>> page_reporting.c change:
> >>>> @@ -101,8 +101,12 @@ static void scan_zone_bitmap(struct page_reporting_config
> >>>> *phconf,
> >>>>                 /* Process only if the page is still online */
> >>>>                 page = pfn_to_online_page((setbit << PAGE_REPORTING_MIN_ORDER) +
> >>>>                                           zone->base_pfn);
> >>>> -               if (!page)
> >>>> +               if (!page || !PageBuddy(page)) {
> >>>> +                       clear_bit(setbit, zone->bitmap);
> >>>> +                       atomic_dec(&zone->free_pages);
> >>>>                         continue;
> >>>> +               }
> >>>>
> >>> I suspect the zone->free_pages is going to be expensive for you to deal
> >>> with. It is a global atomic value and is going to have the cacheline
> >>> bouncing that it is contained in. As a result thinks like setting the
> >>> bitmap with be more expensive as every tome a CPU increments free_pages it
> >>> will likely have to take the cache line containing the bitmap pointer as
> >>> well.
> >> I see I will have to explore this more. I am wondering if there is a way to
> >> measure this If its effect is not visible in will-it-scale/page_fault1. If
> >> there is a noticeable amount of degradation, I will have to address this.
> > If nothing else you might look at seeing if you can split up the
> > structures so that the bitmap and nr_bits is in a different region
> > somewhere since those are read-mostly values.
>
> ok, I will try to understand the issue and your suggestion.
> Thank you for bringing this up.
>
> > Also you are now updating the bitmap and free_pages both inside and
> > outside of the zone lock so that will likely have some impact.
>
> So as per your previous suggestion, I have made the bitmap structure
> object as a rcu protected pointer. So we are safe from that side.
> The other downside which I can think of is a race where one page
> trying to increment free_pages and other trying to decrements it.
> However, being an atomic variable that should not be a problem.
> Did I miss anything?

I'm not so much worried about a race as the cache line bouncing
effect. Basically your notifier combined within this hinting thread
will likely result in more time spent by the thread that holds the
lock since it will be trying to access the bitmap to set the bit and
the free_pages to report the bit, but at the same time you will have
this thread clearing bits and decrementing the free_pages values.

One thing you could consider in your worker thread would be to do
reallocate and replace the bitmap every time you plan to walk it. By
doing that you would avoid the cacheline bouncing on the bitmap since
you would only have to read it, and you would no longer have another
thread dirtying it. You could essentially reset the free_pages at the
same time you replace the bitmap. It would need to all happen with the
zone lock held though when you swap it out.

- Alex

Re: [PATCH v11 0/6] mm / virtio: Provide support for unused page reporting

[Nitesh Narayan Lal]

On 10/7/19 1:06 PM, Nitesh Narayan Lal wrote:
[...]
>> So what was the size of your guest? One thing that just occurred to me is
>> that you might be running a much smaller guest than I was.
> I am running a 30 GB guest.
>
>>>>  If so I would have expected a much higher difference versus
>>>> baseline as zeroing/faulting the pages in the host gets expensive fairly
>>>> quick. What is the host kernel you are running your test on? I'm just
>>>> wondering if there is some additional overhead currently limiting your
>>>> setup. My host kernel was just the same kernel I was running in the guest,
>>>> just built without the patches applied.
>>> Right now I have a different host-kernel. I can install the same kernel to the
>>> host as well and see if that changes anything.
>> The host kernel will have a fairly significant impact as I recall. For
>> example running a stock CentOS kernel lowered the performance compared to
>> running a linux-next kernel. As a result the numbers looked better since
>> the overall baseline was lower to begin with as the host OS was
>> introducing additional overhead.
> I see in that case I will try by installing the same guest kernel
> to the host as well.

As per your suggestion, I tried replacing the host kernel with an
upstream kernel without my patches i.e., my host has a kernel built on top
of the upstream kernel's master branch which has Sept 23rd commit and the guest
has the same kernel for the no-hinting case and same kernel + my patches
for the page reporting case.

With the changes reported earlier on top of v12, I am not seeing any further
degradation (other than what I have previously reported).

To be sure that THP is actively used, I did an experiment where I changed the
MEMSIZE in the page_fault. On doing so THP usage checked via /proc/meminfo also
increased as I expected.

In any case, if you find something else please let me know and I will look into it
again.


I am still looking into your suggestion about cache line bouncing and will reply
to it, if I have more questions.


[...]



-- 
Thanks
Nitesh

Re: [PATCH v11 0/6] mm / virtio: Provide support for unused page reporting

[Nitesh Narayan Lal]

On 10/7/19 1:20 PM, Alexander Duyck wrote:
> On Mon, Oct 7, 2019 at 10:07 AM Nitesh Narayan Lal <nitesh@redhat.com> wrote:
>>
>> On 10/7/19 12:27 PM, Alexander Duyck wrote:
>>> On Mon, 2019-10-07 at 12:19 -0400, Nitesh Narayan Lal wrote:
>>>> On 10/7/19 11:33 AM, Alexander Duyck wrote:
>>>>> On Mon, 2019-10-07 at 08:29 -0400, Nitesh Narayan Lal wrote:
>>>>>> On 10/2/19 10:25 AM, Alexander Duyck wrote:
> <snip>
>
>>>>>> page_reporting.c change:
>>>>>> @@ -101,8 +101,12 @@ static void scan_zone_bitmap(struct page_reporting_config
>>>>>> *phconf,
>>>>>>                 /* Process only if the page is still online */
>>>>>>                 page = pfn_to_online_page((setbit << PAGE_REPORTING_MIN_ORDER) +
>>>>>>                                           zone->base_pfn);
>>>>>> -               if (!page)
>>>>>> +               if (!page || !PageBuddy(page)) {
>>>>>> +                       clear_bit(setbit, zone->bitmap);
>>>>>> +                       atomic_dec(&zone->free_pages);
>>>>>>                         continue;
>>>>>> +               }
>>>>>>
>>>>> I suspect the zone->free_pages is going to be expensive for you to deal
>>>>> with. It is a global atomic value and is going to have the cacheline
>>>>> bouncing that it is contained in. As a result thinks like setting the
>>>>> bitmap with be more expensive as every tome a CPU increments free_pages it
>>>>> will likely have to take the cache line containing the bitmap pointer as
>>>>> well.
>>>> I see I will have to explore this more. I am wondering if there is a way to
>>>> measure this If its effect is not visible in will-it-scale/page_fault1. If
>>>> there is a noticeable amount of degradation, I will have to address this.
>>> If nothing else you might look at seeing if you can split up the
>>> structures so that the bitmap and nr_bits is in a different region
>>> somewhere since those are read-mostly values.
>> ok, I will try to understand the issue and your suggestion.
>> Thank you for bringing this up.
>>
>>> Also you are now updating the bitmap and free_pages both inside and
>>> outside of the zone lock so that will likely have some impact.
>> So as per your previous suggestion, I have made the bitmap structure
>> object as a rcu protected pointer. So we are safe from that side.
>> The other downside which I can think of is a race where one page
>> trying to increment free_pages and other trying to decrements it.
>> However, being an atomic variable that should not be a problem.
>> Did I miss anything?
> I'm not so much worried about a race as the cache line bouncing
> effect. Basically your notifier combined within this hinting thread
> will likely result in more time spent by the thread that holds the
> lock since it will be trying to access the bitmap to set the bit and
> the free_pages to report the bit, but at the same time you will have
> this thread clearing bits and decrementing the free_pages values.
>
> One thing you could consider in your worker thread would be to do
> reallocate and replace the bitmap every time you plan to walk it. By
> doing that you would avoid the cacheline bouncing on the bitmap since
> you would only have to read it, and you would no longer have another
> thread dirtying it. You could essentially reset the free_pages at the
> same time you replace the bitmap. It would need to all happen with the
> zone lock held though when you swap it out.

If I am not mistaken then from what you are suggesting, I will have to hold
the zone lock for the entire duration of swap & scan which would be costly if
the bitmap is large, isn't? Also, we might end up missing free pages that are
getting
freed while we are scanning.

As far as free_pages count is concerned, I am thinking if I should
replace it with zone->free_area[REPORTING_ORDER].nr_free which is already there
(I still need to explore this in a bit more depth).

>
> - Alex
-- 
Thanks
Nitesh

Re: [PATCH v11 0/6] mm / virtio: Provide support for unused page reporting

[Alexander Duyck]

On Wed, 2019-10-09 at 11:21 -0400, Nitesh Narayan Lal wrote:
> On 10/7/19 1:06 PM, Nitesh Narayan Lal wrote:
> [...]
> > > So what was the size of your guest? One thing that just occurred to me is
> > > that you might be running a much smaller guest than I was.
> > I am running a 30 GB guest.
> > 
> > > > >  If so I would have expected a much higher difference versus
> > > > > baseline as zeroing/faulting the pages in the host gets expensive fairly
> > > > > quick. What is the host kernel you are running your test on? I'm just
> > > > > wondering if there is some additional overhead currently limiting your
> > > > > setup. My host kernel was just the same kernel I was running in the guest,
> > > > > just built without the patches applied.
> > > > Right now I have a different host-kernel. I can install the same kernel to the
> > > > host as well and see if that changes anything.
> > > The host kernel will have a fairly significant impact as I recall. For
> > > example running a stock CentOS kernel lowered the performance compared to
> > > running a linux-next kernel. As a result the numbers looked better since
> > > the overall baseline was lower to begin with as the host OS was
> > > introducing additional overhead.
> > I see in that case I will try by installing the same guest kernel
> > to the host as well.
> 
> As per your suggestion, I tried replacing the host kernel with an
> upstream kernel without my patches i.e., my host has a kernel built on top
> of the upstream kernel's master branch which has Sept 23rd commit and the guest
> has the same kernel for the no-hinting case and same kernel + my patches
> for the page reporting case.
> 
> With the changes reported earlier on top of v12, I am not seeing any further
> degradation (other than what I have previously reported).
> 
> To be sure that THP is actively used, I did an experiment where I changed the
> MEMSIZE in the page_fault. On doing so THP usage checked via /proc/meminfo also
> increased as I expected.
> 
> In any case, if you find something else please let me know and I will look into it
> again.
> 
> 
> I am still looking into your suggestion about cache line bouncing and will reply
> to it, if I have more questions.
> 
> 
> [...]

I really feel like this discussion has gone off course. The idea here is
to review this patch set[1] and provide working alternatives if there are
issues with the current approach.

The bitmap based approach still has a number of outstanding issues
including sparse memory and hotplug which have yet to be addressed. We can
gloss over that, but there is a good chance that resolving those would
have potential performance implications. With this most recent change
there is now also the fact that it can only really support reporting at
one page order so the solution is now much more prone to issues with
memory fragmentation than it was before. I would consider the fact that my
solution works with multiple page orders while the bitmap approach
requires MAX_ORDER - 1 seems like another obvious win for my solution.
Until we can get back to the point where we are comparing apples to apples
I would prefer not to benchmark the bitmap solution as without the extra
order limitation it was over 20% worse then my solution performance wise.

Ideally I would like to get code review for patches 3 and 4, and spend my
time addressing issues reported there. The main things I need input on is
if the solution of allowing the list iterators to be reset is good enough
to address the compaction issues that were pointed out several releases
ago or if I have to look for another solution. Also I have changed things
so that page_reporting.h was split over two files with the new one now
living in the mm/ folder. By doing that I was hoping to reduce the
exposure of the internal state of the free-lists so that essentially all
we end up providing is an interface for the notifier to be used by virtio-
balloon.

Thanks.

- Alex

[1]: https://lore.kernel.org/lkml/20191001152441.27008.99285.stgit@localhost.localdomain/

Re: [PATCH v11 0/6] mm / virtio: Provide support for unused page reporting

[Alexander Duyck]

On Wed, 2019-10-09 at 12:25 -0400, Nitesh Narayan Lal wrote:
> On 10/7/19 1:20 PM, Alexander Duyck wrote:
> > On Mon, Oct 7, 2019 at 10:07 AM Nitesh Narayan Lal <nitesh@redhat.com> wrote:
> > > On 10/7/19 12:27 PM, Alexander Duyck wrote:
> > > > On Mon, 2019-10-07 at 12:19 -0400, Nitesh Narayan Lal wrote:
> > > > > On 10/7/19 11:33 AM, Alexander Duyck wrote:
> > > > > > On Mon, 2019-10-07 at 08:29 -0400, Nitesh Narayan Lal wrote:
> > > > > > > On 10/2/19 10:25 AM, Alexander Duyck wrote:
> > <snip>
> > 
> > > > > > > page_reporting.c change:
> > > > > > > @@ -101,8 +101,12 @@ static void scan_zone_bitmap(struct page_reporting_config
> > > > > > > *phconf,
> > > > > > >                 /* Process only if the page is still online */
> > > > > > >                 page = pfn_to_online_page((setbit << PAGE_REPORTING_MIN_ORDER) +
> > > > > > >                                           zone->base_pfn);
> > > > > > > -               if (!page)
> > > > > > > +               if (!page || !PageBuddy(page)) {
> > > > > > > +                       clear_bit(setbit, zone->bitmap);
> > > > > > > +                       atomic_dec(&zone->free_pages);
> > > > > > >                         continue;
> > > > > > > +               }
> > > > > > > 
> > > > > > I suspect the zone->free_pages is going to be expensive for you to deal
> > > > > > with. It is a global atomic value and is going to have the cacheline
> > > > > > bouncing that it is contained in. As a result thinks like setting the
> > > > > > bitmap with be more expensive as every tome a CPU increments free_pages it
> > > > > > will likely have to take the cache line containing the bitmap pointer as
> > > > > > well.
> > > > > I see I will have to explore this more. I am wondering if there is a way to
> > > > > measure this If its effect is not visible in will-it-scale/page_fault1. If
> > > > > there is a noticeable amount of degradation, I will have to address this.
> > > > If nothing else you might look at seeing if you can split up the
> > > > structures so that the bitmap and nr_bits is in a different region
> > > > somewhere since those are read-mostly values.
> > > ok, I will try to understand the issue and your suggestion.
> > > Thank you for bringing this up.
> > > 
> > > > Also you are now updating the bitmap and free_pages both inside and
> > > > outside of the zone lock so that will likely have some impact.
> > > So as per your previous suggestion, I have made the bitmap structure
> > > object as a rcu protected pointer. So we are safe from that side.
> > > The other downside which I can think of is a race where one page
> > > trying to increment free_pages and other trying to decrements it.
> > > However, being an atomic variable that should not be a problem.
> > > Did I miss anything?
> > I'm not so much worried about a race as the cache line bouncing
> > effect. Basically your notifier combined within this hinting thread
> > will likely result in more time spent by the thread that holds the
> > lock since it will be trying to access the bitmap to set the bit and
> > the free_pages to report the bit, but at the same time you will have
> > this thread clearing bits and decrementing the free_pages values.
> > 
> > One thing you could consider in your worker thread would be to do
> > reallocate and replace the bitmap every time you plan to walk it. By
> > doing that you would avoid the cacheline bouncing on the bitmap since
> > you would only have to read it, and you would no longer have another
> > thread dirtying it. You could essentially reset the free_pages at the
> > same time you replace the bitmap. It would need to all happen with the
> > zone lock held though when you swap it out.
> 
> If I am not mistaken then from what you are suggesting, I will have to hold
> the zone lock for the entire duration of swap & scan which would be costly if
> the bitmap is large, isn't? Also, we might end up missing free pages that are
> getting
> freed while we are scanning.

You would only need to hold the zone lock when you swap the bitmap. Once
it is swapped you wouldn't need to worry about the locking again for
bitmap access since your worker thread would be the only one holding the
current bitmap. Think of it as a batch clearing of the bits.

You already end up missing pages freed while scanning since you are doing
it linearly.

> As far as free_pages count is concerned, I am thinking if I should
> replace it with zone->free_area[REPORTING_ORDER].nr_free which is already there
> (I still need to explore this in a bit more depth).
> 
> > - Alex

So there ends up being two ways you could use nr_free. One is to track it
the way I did with the number of reported pages being tracked, however
that requires reducing the count when reported pages are pulled from the
free_area and identifying reported pages vs unreported ones.

The other option would be to look at converting nr_free into a pair of
free running counters, one tracking frees, and another tracking
allocations. Then you just need to record a snapshot of the nr_free values
when you do something like the bitmap swap, and then you would be able to
track churn, but it wouldn't give you an exact count of unreported pages
since it is possible to just alloc/free a single page multiple times to
make it look like you have freed a number of pages even though you really
haven't.

Re: [PATCH v11 0/6] mm / virtio: Provide support for unused page reporting

[Nitesh Narayan Lal]

On 10/9/19 12:50 PM, Alexander Duyck wrote:
> On Wed, 2019-10-09 at 12:25 -0400, Nitesh Narayan Lal wrote:
>> On 10/7/19 1:20 PM, Alexander Duyck wrote:
>>> On Mon, Oct 7, 2019 at 10:07 AM Nitesh Narayan Lal <nitesh@redhat.com> wrote:
>>>> On 10/7/19 12:27 PM, Alexander Duyck wrote:
>>>>> On Mon, 2019-10-07 at 12:19 -0400, Nitesh Narayan Lal wrote:
>>>>>> On 10/7/19 11:33 AM, Alexander Duyck wrote:
>>>>>>> On Mon, 2019-10-07 at 08:29 -0400, Nitesh Narayan Lal wrote:
>>>>>>>> On 10/2/19 10:25 AM, Alexander Duyck wrote:
>>> <snip>
>>>
>>>>>>>> page_reporting.c change:
>>>>>>>> @@ -101,8 +101,12 @@ static void scan_zone_bitmap(struct page_reporting_config
>>>>>>>> *phconf,
>>>>>>>>                 /* Process only if the page is still online */
>>>>>>>>                 page = pfn_to_online_page((setbit << PAGE_REPORTING_MIN_ORDER) +
>>>>>>>>                                           zone->base_pfn);
>>>>>>>> -               if (!page)
>>>>>>>> +               if (!page || !PageBuddy(page)) {
>>>>>>>> +                       clear_bit(setbit, zone->bitmap);
>>>>>>>> +                       atomic_dec(&zone->free_pages);
>>>>>>>>                         continue;
>>>>>>>> +               }
>>>>>>>>
>>>>>>> I suspect the zone->free_pages is going to be expensive for you to deal
>>>>>>> with. It is a global atomic value and is going to have the cacheline
>>>>>>> bouncing that it is contained in. As a result thinks like setting the
>>>>>>> bitmap with be more expensive as every tome a CPU increments free_pages it
>>>>>>> will likely have to take the cache line containing the bitmap pointer as
>>>>>>> well.
>>>>>> I see I will have to explore this more. I am wondering if there is a way to
>>>>>> measure this If its effect is not visible in will-it-scale/page_fault1. If
>>>>>> there is a noticeable amount of degradation, I will have to address this.
>>>>> If nothing else you might look at seeing if you can split up the
>>>>> structures so that the bitmap and nr_bits is in a different region
>>>>> somewhere since those are read-mostly values.
>>>> ok, I will try to understand the issue and your suggestion.
>>>> Thank you for bringing this up.
>>>>
>>>>> Also you are now updating the bitmap and free_pages both inside and
>>>>> outside of the zone lock so that will likely have some impact.
>>>> So as per your previous suggestion, I have made the bitmap structure
>>>> object as a rcu protected pointer. So we are safe from that side.
>>>> The other downside which I can think of is a race where one page
>>>> trying to increment free_pages and other trying to decrements it.
>>>> However, being an atomic variable that should not be a problem.
>>>> Did I miss anything?
>>> I'm not so much worried about a race as the cache line bouncing
>>> effect. Basically your notifier combined within this hinting thread
>>> will likely result in more time spent by the thread that holds the
>>> lock since it will be trying to access the bitmap to set the bit and
>>> the free_pages to report the bit, but at the same time you will have
>>> this thread clearing bits and decrementing the free_pages values.
>>>
>>> One thing you could consider in your worker thread would be to do
>>> reallocate and replace the bitmap every time you plan to walk it. By
>>> doing that you would avoid the cacheline bouncing on the bitmap since
>>> you would only have to read it, and you would no longer have another
>>> thread dirtying it. You could essentially reset the free_pages at the
>>> same time you replace the bitmap. It would need to all happen with the
>>> zone lock held though when you swap it out.
>> If I am not mistaken then from what you are suggesting, I will have to hold
>> the zone lock for the entire duration of swap & scan which would be costly if
>> the bitmap is large, isn't? Also, we might end up missing free pages that are
>> getting
>> freed while we are scanning.
> You would only need to hold the zone lock when you swap the bitmap. Once
> it is swapped you wouldn't need to worry about the locking again for
> bitmap access since your worker thread would be the only one holding the
> current bitmap. Think of it as a batch clearing of the bits.

I see.

>
> You already end up missing pages freed while scanning since you are doing
> it linearly.

I was referring to free pages for whom bits will not be set while we
are doing the batch clearing of the bits.

>
>> As far as free_pages count is concerned, I am thinking if I should
>> replace it with zone->free_area[REPORTING_ORDER].nr_free which is already there
>> (I still need to explore this in a bit more depth).
>>
>>> - Alex
> So there ends up being two ways you could use nr_free. One is to track it
> the way I did with the number of reported pages being tracked, however
> that requires reducing the count when reported pages are pulled from the
> free_area and identifying reported pages vs unreported ones.
>
> The other option would be to look at converting nr_free into a pair of
> free running counters, one tracking frees, and another tracking
> allocations. Then you just need to record a snapshot of the nr_free values
> when you do something like the bitmap swap, and then you would be able to
> track churn, but it wouldn't give you an exact count of unreported pages
> since it is possible to just alloc/free a single page multiple times to
> make it look like you have freed a number of pages even though you really
> haven't.

Yeah possibly. I will think about it a little bit more to see what
is the best way to do it.

-- 
Thanks
Nitesh

Re: [PATCH v11 0/6] mm / virtio: Provide support for unused page reporting

[Alexander Duyck]

On Wed, 2019-10-09 at 13:08 -0400, Nitesh Narayan Lal wrote:
> On 10/9/19 12:50 PM, Alexander Duyck wrote:
> > On Wed, 2019-10-09 at 12:25 -0400, Nitesh Narayan Lal wrote:
> > > On 10/7/19 1:20 PM, Alexander Duyck wrote:
> > > > On Mon, Oct 7, 2019 at 10:07 AM Nitesh Narayan Lal <nitesh@redhat.com> wrote:
> > > > > On 10/7/19 12:27 PM, Alexander Duyck wrote:
> > > > > > On Mon, 2019-10-07 at 12:19 -0400, Nitesh Narayan Lal wrote:
> > > > > > > On 10/7/19 11:33 AM, Alexander Duyck wrote:
> > > > > > > > On Mon, 2019-10-07 at 08:29 -0400, Nitesh Narayan Lal wrote:
> > > > > > > > > On 10/2/19 10:25 AM, Alexander Duyck wrote:
> > > > <snip>
> > > > 
> > > > > > > > > page_reporting.c change:
> > > > > > > > > @@ -101,8 +101,12 @@ static void scan_zone_bitmap(struct page_reporting_config
> > > > > > > > > *phconf,
> > > > > > > > >                 /* Process only if the page is still online */
> > > > > > > > >                 page = pfn_to_online_page((setbit << PAGE_REPORTING_MIN_ORDER) +
> > > > > > > > >                                           zone->base_pfn);
> > > > > > > > > -               if (!page)
> > > > > > > > > +               if (!page || !PageBuddy(page)) {
> > > > > > > > > +                       clear_bit(setbit, zone->bitmap);
> > > > > > > > > +                       atomic_dec(&zone->free_pages);
> > > > > > > > >                         continue;
> > > > > > > > > +               }
> > > > > > > > > 
> > > > > > > > I suspect the zone->free_pages is going to be expensive for you to deal
> > > > > > > > with. It is a global atomic value and is going to have the cacheline
> > > > > > > > bouncing that it is contained in. As a result thinks like setting the
> > > > > > > > bitmap with be more expensive as every tome a CPU increments free_pages it
> > > > > > > > will likely have to take the cache line containing the bitmap pointer as
> > > > > > > > well.
> > > > > > > I see I will have to explore this more. I am wondering if there is a way to
> > > > > > > measure this If its effect is not visible in will-it-scale/page_fault1. If
> > > > > > > there is a noticeable amount of degradation, I will have to address this.
> > > > > > If nothing else you might look at seeing if you can split up the
> > > > > > structures so that the bitmap and nr_bits is in a different region
> > > > > > somewhere since those are read-mostly values.
> > > > > ok, I will try to understand the issue and your suggestion.
> > > > > Thank you for bringing this up.
> > > > > 
> > > > > > Also you are now updating the bitmap and free_pages both inside and
> > > > > > outside of the zone lock so that will likely have some impact.
> > > > > So as per your previous suggestion, I have made the bitmap structure
> > > > > object as a rcu protected pointer. So we are safe from that side.
> > > > > The other downside which I can think of is a race where one page
> > > > > trying to increment free_pages and other trying to decrements it.
> > > > > However, being an atomic variable that should not be a problem.
> > > > > Did I miss anything?
> > > > I'm not so much worried about a race as the cache line bouncing
> > > > effect. Basically your notifier combined within this hinting thread
> > > > will likely result in more time spent by the thread that holds the
> > > > lock since it will be trying to access the bitmap to set the bit and
> > > > the free_pages to report the bit, but at the same time you will have
> > > > this thread clearing bits and decrementing the free_pages values.
> > > > 
> > > > One thing you could consider in your worker thread would be to do
> > > > reallocate and replace the bitmap every time you plan to walk it. By
> > > > doing that you would avoid the cacheline bouncing on the bitmap since
> > > > you would only have to read it, and you would no longer have another
> > > > thread dirtying it. You could essentially reset the free_pages at the
> > > > same time you replace the bitmap. It would need to all happen with the
> > > > zone lock held though when you swap it out.
> > > If I am not mistaken then from what you are suggesting, I will have to hold
> > > the zone lock for the entire duration of swap & scan which would be costly if
> > > the bitmap is large, isn't? Also, we might end up missing free pages that are
> > > getting
> > > freed while we are scanning.
> > You would only need to hold the zone lock when you swap the bitmap. Once
> > it is swapped you wouldn't need to worry about the locking again for
> > bitmap access since your worker thread would be the only one holding the
> > current bitmap. Think of it as a batch clearing of the bits.
> 
> I see.
> 
> > You already end up missing pages freed while scanning since you are doing
> > it linearly.
> 
> I was referring to free pages for whom bits will not be set while we
> are doing the batch clearing of the bits.

I think you missed the point. Your notifier is only setting bits while
holding the zone lock anyway. So if you do the swap while holding the zone
lock then you will miss nothing. An added advantage is that you could
switch over to a non-atomic __set_bit instead of having to do atomic set
and clear operations. 

Thanks.

- Alex

Re: [PATCH v11 0/6] mm / virtio: Provide support for unused page reporting

[Nitesh Narayan Lal]

On 10/9/19 12:35 PM, Alexander Duyck wrote:
> On Wed, 2019-10-09 at 11:21 -0400, Nitesh Narayan Lal wrote:
>> On 10/7/19 1:06 PM, Nitesh Narayan Lal wrote:
>> [...]
>>>> So what was the size of your guest? One thing that just occurred to me is
>>>> that you might be running a much smaller guest than I was.
>>> I am running a 30 GB guest.
>>>
>>>>>>  If so I would have expected a much higher difference versus
>>>>>> baseline as zeroing/faulting the pages in the host gets expensive fairly
>>>>>> quick. What is the host kernel you are running your test on? I'm just
>>>>>> wondering if there is some additional overhead currently limiting your
>>>>>> setup. My host kernel was just the same kernel I was running in the guest,
>>>>>> just built without the patches applied.
>>>>> Right now I have a different host-kernel. I can install the same kernel to the
>>>>> host as well and see if that changes anything.
>>>> The host kernel will have a fairly significant impact as I recall. For
>>>> example running a stock CentOS kernel lowered the performance compared to
>>>> running a linux-next kernel. As a result the numbers looked better since
>>>> the overall baseline was lower to begin with as the host OS was
>>>> introducing additional overhead.
>>> I see in that case I will try by installing the same guest kernel
>>> to the host as well.
>> As per your suggestion, I tried replacing the host kernel with an
>> upstream kernel without my patches i.e., my host has a kernel built on top
>> of the upstream kernel's master branch which has Sept 23rd commit and the guest
>> has the same kernel for the no-hinting case and same kernel + my patches
>> for the page reporting case.
>>
>> With the changes reported earlier on top of v12, I am not seeing any further
>> degradation (other than what I have previously reported).
>>
>> To be sure that THP is actively used, I did an experiment where I changed the
>> MEMSIZE in the page_fault. On doing so THP usage checked via /proc/meminfo also
>> increased as I expected.
>>
>> In any case, if you find something else please let me know and I will look into it
>> again.
>>
>>
>> I am still looking into your suggestion about cache line bouncing and will reply
>> to it, if I have more questions.
>>
>>
>> [...]
> I really feel like this discussion has gone off course. The idea here is
> to review this patch set[1] and provide working alternatives if there are
> issues with the current approach.


Agreed.

>
> The bitmap based approach still has a number of outstanding issues
> including sparse memory and hotplug which have yet to be addressed.

True, but I don't think those two are a blocker.

For sparse zone as we are maintaining the bitmap on a granularity of
(MAX_ORDER - 2) / (MAX_ORDER - 1) etc. the memory wastage should be
negligible in most of the cases.

For memory hotplug/hotremove, I did make sure that I don't break anything.
Even if a user starts using this feature with page-reporting enabled.
However, it is true that I don't report or capture any memory added/removed
thought it.

Fixing these issues will be an optimization which I will do as I get my basic
framework ready and in shape.

>  We can
> gloss over that, but there is a good chance that resolving those would
> have potential performance implications. With this most recent change
> there is now also the fact that it can only really support reporting at
> one page order so the solution is now much more prone to issues with
> memory fragmentation than it was before. I would consider the fact that my
> solution works with multiple page orders while the bitmap approach
> requires MAX_ORDER - 1 seems like another obvious win for my solution.

This is just a configuration change and only requires to update
the macro 'PAGE_REPORTING_MIN_ORDER' to what you are using.

What order do we want to report could vary based on the
use case where we are deploying the solution.

Ideally, this should be configurable maybe at the compile time
or we can stick with pageblock_order which is originally suggested
and used by you.

> Until we can get back to the point where we are comparing apples to apples
> I would prefer not to benchmark the bitmap solution as without the extra
> order limitation it was over 20% worse then my solution performance wise..

Understood.
However, as I reported previously after making the configuration changes
on top of v12 posting, I don't see the degradation.

I will be happy to try out more suggestions to see if the issue is really fixed.

I have started looking into your concern of cacheline bouncing after
which I will look into Michal's suggestion of using page-isolation APIs to
isolate and release pages back. After that, I can decide on
posting my next series (if it is required).

>
> Ideally I would like to get code review for patches 3 and 4, and spend my
> time addressing issues reported there. The main things I need input on is
> if the solution of allowing the list iterators to be reset is good enough
> to address the compaction issues that were pointed out several releases
> ago or if I have to look for another solution. Also I have changed things
> so that page_reporting.h was split over two files with the new one now
> living in the mm/ folder. By doing that I was hoping to reduce the
> exposure of the internal state of the free-lists so that essentially all
> we end up providing is an interface for the notifier to be used by virtio-
> balloon.

If everyone agrees that what you are proposing is the best way to move
forward then, by all means, lets go ahead with it. :)

>
> Thanks.
>
> - Alex
>
> [1]: https://lore.kernel.org/lkml/20191001152441.27008.99285.stgit@localhost.localdomain/
>
-- 
Thanks
Nitesh

Re: [PATCH v11 0/6] mm / virtio: Provide support for unused page reporting

[David Hildenbrand]

On 09.10.19 21:46, Nitesh Narayan Lal wrote:
> 
> On 10/9/19 12:35 PM, Alexander Duyck wrote:
>> On Wed, 2019-10-09 at 11:21 -0400, Nitesh Narayan Lal wrote:
>>> On 10/7/19 1:06 PM, Nitesh Narayan Lal wrote:
>>> [...]
>>>>> So what was the size of your guest? One thing that just occurred to me is
>>>>> that you might be running a much smaller guest than I was.
>>>> I am running a 30 GB guest.
>>>>
>>>>>>>  If so I would have expected a much higher difference versus
>>>>>>> baseline as zeroing/faulting the pages in the host gets expensive fairly
>>>>>>> quick. What is the host kernel you are running your test on? I'm just
>>>>>>> wondering if there is some additional overhead currently limiting your
>>>>>>> setup. My host kernel was just the same kernel I was running in the guest,
>>>>>>> just built without the patches applied.
>>>>>> Right now I have a different host-kernel. I can install the same kernel to the
>>>>>> host as well and see if that changes anything.
>>>>> The host kernel will have a fairly significant impact as I recall. For
>>>>> example running a stock CentOS kernel lowered the performance compared to
>>>>> running a linux-next kernel. As a result the numbers looked better since
>>>>> the overall baseline was lower to begin with as the host OS was
>>>>> introducing additional overhead.
>>>> I see in that case I will try by installing the same guest kernel
>>>> to the host as well.
>>> As per your suggestion, I tried replacing the host kernel with an
>>> upstream kernel without my patches i.e., my host has a kernel built on top
>>> of the upstream kernel's master branch which has Sept 23rd commit and the guest
>>> has the same kernel for the no-hinting case and same kernel + my patches
>>> for the page reporting case.
>>>
>>> With the changes reported earlier on top of v12, I am not seeing any further
>>> degradation (other than what I have previously reported).
>>>
>>> To be sure that THP is actively used, I did an experiment where I changed the
>>> MEMSIZE in the page_fault. On doing so THP usage checked via /proc/meminfo also
>>> increased as I expected.
>>>
>>> In any case, if you find something else please let me know and I will look into it
>>> again.
>>>
>>>
>>> I am still looking into your suggestion about cache line bouncing and will reply
>>> to it, if I have more questions.
>>>
>>>
>>> [...]
>> I really feel like this discussion has gone off course. The idea here is
>> to review this patch set[1] and provide working alternatives if there are
>> issues with the current approach.
> 
> 
> Agreed.
> 
>>
>> The bitmap based approach still has a number of outstanding issues
>> including sparse memory and hotplug which have yet to be addressed.
> 
> True, but I don't think those two are a blocker.
> 
> For sparse zone as we are maintaining the bitmap on a granularity of
> (MAX_ORDER - 2) / (MAX_ORDER - 1) etc. the memory wastage should be
> negligible in most of the cases.
> 
> For memory hotplug/hotremove, I did make sure that I don't break anything.
> Even if a user starts using this feature with page-reporting enabled.
> However, it is true that I don't report or capture any memory added/removed
> thought it.
> 
> Fixing these issues will be an optimization which I will do as I get my basic
> framework ready and in shape.
> 
>>  We can
>> gloss over that, but there is a good chance that resolving those would
>> have potential performance implications. With this most recent change
>> there is now also the fact that it can only really support reporting at
>> one page order so the solution is now much more prone to issues with
>> memory fragmentation than it was before. I would consider the fact that my
>> solution works with multiple page orders while the bitmap approach
>> requires MAX_ORDER - 1 seems like another obvious win for my solution.
> 
> This is just a configuration change and only requires to update
> the macro 'PAGE_REPORTING_MIN_ORDER' to what you are using.
> 
> What order do we want to report could vary based on the
> use case where we are deploying the solution.
> 
> Ideally, this should be configurable maybe at the compile time
> or we can stick with pageblock_order which is originally suggested
> and used by you.
> 
>> Until we can get back to the point where we are comparing apples to apples
>> I would prefer not to benchmark the bitmap solution as without the extra
>> order limitation it was over 20% worse then my solution performance wise..
> 
> Understood.
> However, as I reported previously after making the configuration changes
> on top of v12 posting, I don't see the degradation.
> 
> I will be happy to try out more suggestions to see if the issue is really fixed.
> 
> I have started looking into your concern of cacheline bouncing after
> which I will look into Michal's suggestion of using page-isolation APIs to
> isolate and release pages back. After that, I can decide on
> posting my next series (if it is required).
> 
>>
>> Ideally I would like to get code review for patches 3 and 4, and spend my
>> time addressing issues reported there. The main things I need input on is
>> if the solution of allowing the list iterators to be reset is good enough
>> to address the compaction issues that were pointed out several releases
>> ago or if I have to look for another solution. Also I have changed things
>> so that page_reporting.h was split over two files with the new one now
>> living in the mm/ folder. By doing that I was hoping to reduce the
>> exposure of the internal state of the free-lists so that essentially all
>> we end up providing is an interface for the notifier to be used by virtio-
>> balloon.
> 
> If everyone agrees that what you are proposing is the best way to move
> forward then, by all means, lets go ahead with it. :)
> 

Sorry, i didn't get to follow the discussion, caught a cold and my body
is still fighting with the last resistance.

Is there any rough summary on how much faster Alexanders approach is
compared to some external tracking? For external tracking, there is a
lot of optimization potential as far as I can read, however, I think a
rough summary should be possible by now "how far we are off".

Also, are there benchmarks/setups where both perform the same?


-- 

Thanks,

David / dhildenb

Re: [PATCH v11 0/6] mm / virtio: Provide support for unused page reporting

[Nitesh Narayan Lal]

On 10/10/19 3:36 AM, David Hildenbrand wrote:
> On 09.10.19 21:46, Nitesh Narayan Lal wrote:
>> On 10/9/19 12:35 PM, Alexander Duyck wrote:
>>> On Wed, 2019-10-09 at 11:21 -0400, Nitesh Narayan Lal wrote:
>>>> On 10/7/19 1:06 PM, Nitesh Narayan Lal wrote:
[...]
>>>> Ideally I would like to get code review for patches 3 and 4, and spend my
>>>> time addressing issues reported there. The main things I need input on is
>>>> if the solution of allowing the list iterators to be reset is good enough
>>>> to address the compaction issues that were pointed out several releases
>>>> ago or if I have to look for another solution. Also I have changed things
>>>> so that page_reporting.h was split over two files with the new one now
>>>> living in the mm/ folder. By doing that I was hoping to reduce the
>>>> exposure of the internal state of the free-lists so that essentially all
>>>> we end up providing is an interface for the notifier to be used by virtio-
>>>> balloon.
>> If everyone agrees that what you are proposing is the best way to move
>> forward then, by all means, lets go ahead with it. :)
>>
> Sorry, i didn't get to follow the discussion, caught a cold and my body
> is still fighting with the last resistance.

I hope you feel better soon.

>
> Is there any rough summary on how much faster Alexanders approach is
> compared to some external tracking? For external tracking, there is a
> lot of optimization potential as far as I can read, however, I think a
> rough summary should be possible by now "how far we are off".
>
> Also, are there benchmarks/setups where both perform the same?

So I tried to follow up on the suggestion provided by Alexander to
recreate his setup and with the posted v12, I did observe a drop in
will-it-scale/page_fault. Specifically in the number of threads that were
launched on the nth core.

However, I did not see that degradation after making the changes which I
suggested previously on top of v12.

After those changes as per my observation, both series are introducing more or
less the same amount of degradation over an unmodified kernel.

In any case, if there are more suggestions, I am open to performing more experiments
to ensure that there is no further degradation with my series.

-- 
Thanks
Nitesh