[RFC][Patch v9 0/6] KVM: Guest Free Page Hinting

[RFC][Patch v9 0/6] KVM: Guest Free Page Hinting

[Nitesh Narayan Lal]

The following patch-set proposes an efficient mechanism for handing freed memory between the guest and the host. It enables the guests with no page cache to rapidly free and reclaims memory to and from the host respectively.

Benefit:
With this patch-series, in our test-case, executed on a single system and single NUMA node with 15GB memory, we were able to successfully launch 5 guests(each with 5 GB memory) when page hinting was enabled and 3 without it. (Detailed explanation of the test procedure is provided at the bottom under Test - 1).

Changelog in v9:
	* Guest free page hinting hook is now invoked after a page has been merged in the buddy.
        * Free pages only with order FREE_PAGE_HINTING_MIN_ORDER(currently defined as MAX_ORDER - 1) are captured.
	* Removed kthread which was earlier used to perform the scanning, isolation & reporting of free pages.
	* Pages, captured in the per cpu array are sorted based on the zone numbers. This is to avoid redundancy of acquiring zone locks.
        * Dynamically allocated space is used to hold the isolated guest free pages.
        * All the pages are reported asynchronously to the host via virtio driver.
        * Pages are returned back to the guest buddy free list only when the host response is received.

Pending items:
        * Make sure that the guest free page hinting's current implementation doesn't break hugepages or device assigned guests.
	* Follow up on VIRTIO_BALLOON_F_PAGE_POISON's device side support. (It is currently missing)
        * Compare reporting free pages via vring with vhost.
        * Decide between MADV_DONTNEED and MADV_FREE.
	* Analyze overall performance impact due to guest free page hinting.
	* Come up with proper/traceable error-message/logs.

Tests:
1. Use-case - Number of guests we can launch

	NUMA Nodes = 1 with 15 GB memory
	Guest Memory = 5 GB
	Number of cores in guest = 1
	Workload = test allocation program allocates 4GB memory, touches it via memset and exits.
	Procedure =
	The first guest is launched and once its console is up, the test allocation program is executed with 4 GB memory request (Due to this the guest occupies almost 4-5 GB of memory in the host in a system without page hinting). Once this program exits at that time another guest is launched in the host and the same process is followed. We continue launching the guests until a guest gets killed due to low memory condition in the host.

	Results:
	Without hinting = 3
	With hinting = 5

2. Hackbench
	Guest Memory = 5 GB 
	Number of cores = 4
	Number of tasks		Time with Hinting	Time without Hinting
	4000			19.540			17.818

[RFC][Patch v9 1/6] KVM: Guest free page hinting support

[Nitesh Narayan Lal]

This patch adds the following:
1. Functional skeleton for the guest implementation. It enables the
guest to maintain the PFN of head buddy free pages of order
FREE_PAGE_HINTING_MIN_ORDER (currently defined as MAX_ORDER - 1)
in a per-cpu array.
Guest uses guest_free_page_enqueue() to enqueue the free pages post buddy
merging to the above mentioned per-cpu array.
guest_free_page_try_hinting() is used to initiate hinting operation once
the collected entries of the per-cpu array reaches or exceeds
HINTING_THRESHOLD (128). Having larger array size(MAX_FGPT_ENTRIES = 256)
than HINTING_THRESHOLD allows us to capture more pages specifically when
guest_free_page_enqueue() is called from free_pcppages_bulk().
For now guest_free_page_hinting() just resets the array index to continue
capturing of the freed pages.
2. Enables the support for x86 architecture.

Signed-off-by: Nitesh Narayan Lal <nitesh@redhat.com>
---
 arch/x86/Kbuild              |  2 +-
 arch/x86/kvm/Kconfig         |  8 +++
 arch/x86/kvm/Makefile        |  2 +
 include/linux/page_hinting.h | 15 ++++++
 mm/page_alloc.c              |  5 ++
 virt/kvm/page_hinting.c      | 98 ++++++++++++++++++++++++++++++++++++
 6 files changed, 129 insertions(+), 1 deletion(-)
 create mode 100644 include/linux/page_hinting.h
 create mode 100644 virt/kvm/page_hinting.c

diff --git a/arch/x86/Kbuild b/arch/x86/Kbuild
index c625f57472f7..3244df4ee311 100644
--- a/arch/x86/Kbuild
+++ b/arch/x86/Kbuild
@@ -2,7 +2,7 @@ obj-y += entry/
 
 obj-$(CONFIG_PERF_EVENTS) += events/
 
-obj-$(CONFIG_KVM) += kvm/
+obj-$(subst m,y,$(CONFIG_KVM)) += kvm/
 
 # Xen paravirtualization support
 obj-$(CONFIG_XEN) += xen/
diff --git a/arch/x86/kvm/Kconfig b/arch/x86/kvm/Kconfig
index 72fa955f4a15..2fae31459706 100644
--- a/arch/x86/kvm/Kconfig
+++ b/arch/x86/kvm/Kconfig
@@ -96,6 +96,14 @@ config KVM_MMU_AUDIT
 	 This option adds a R/W kVM module parameter 'mmu_audit', which allows
 	 auditing of KVM MMU events at runtime.
 
+# KVM_FREE_PAGE_HINTING will allow the guest to report the free pages to the
+# host in regular interval of time.
+config KVM_FREE_PAGE_HINTING
+       def_bool y
+       depends on KVM
+       select VIRTIO
+       select VIRTIO_BALLOON
+
 # OK, it's a little counter-intuitive to do this, but it puts it neatly under
 # the virtualization menu.
 source "drivers/vhost/Kconfig"
diff --git a/arch/x86/kvm/Makefile b/arch/x86/kvm/Makefile
index 69b3a7c30013..78640a80501e 100644
--- a/arch/x86/kvm/Makefile
+++ b/arch/x86/kvm/Makefile
@@ -16,6 +16,8 @@ kvm-y			+= x86.o mmu.o emulate.o i8259.o irq.o lapic.o \
 			   i8254.o ioapic.o irq_comm.o cpuid.o pmu.o mtrr.o \
 			   hyperv.o page_track.o debugfs.o
 
+obj-$(CONFIG_KVM_FREE_PAGE_HINTING)    += $(KVM)/page_hinting.o
+
 kvm-intel-y		+= vmx/vmx.o vmx/vmenter.o vmx/pmu_intel.o vmx/vmcs12.o vmx/evmcs.o vmx/nested.o
 kvm-amd-y		+= svm.o pmu_amd.o
 
diff --git a/include/linux/page_hinting.h b/include/linux/page_hinting.h
new file mode 100644
index 000000000000..90254c582789
--- /dev/null
+++ b/include/linux/page_hinting.h
@@ -0,0 +1,15 @@
+#include <linux/gfp.h>
+/*
+ * Size of the array which is used to store the freed pages is defined by
+ * MAX_FGPT_ENTRIES.
+ */
+#define MAX_FGPT_ENTRIES	256
+/*
+ * Threshold value after which hinting needs to be initiated on the captured
+ * free pages.
+ */
+#define HINTING_THRESHOLD	128
+#define FREE_PAGE_HINTING_MIN_ORDER	(MAX_ORDER - 1)
+
+void guest_free_page_enqueue(struct page *page, int order);
+void guest_free_page_try_hinting(void);
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index d295c9bc01a8..684d047f33ee 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -67,6 +67,7 @@
 #include <linux/lockdep.h>
 #include <linux/nmi.h>
 #include <linux/psi.h>
+#include <linux/page_hinting.h>
 
 #include <asm/sections.h>
 #include <asm/tlbflush.h>
@@ -1194,9 +1195,11 @@ static void free_pcppages_bulk(struct zone *zone, int count,
 			mt = get_pageblock_migratetype(page);
 
 		__free_one_page(page, page_to_pfn(page), zone, 0, mt);
+		guest_free_page_enqueue(page, 0);
 		trace_mm_page_pcpu_drain(page, 0, mt);
 	}
 	spin_unlock(&zone->lock);
+	guest_free_page_try_hinting();
 }
 
 static void free_one_page(struct zone *zone,
@@ -1210,7 +1213,9 @@ static void free_one_page(struct zone *zone,
 		migratetype = get_pfnblock_migratetype(page, pfn);
 	}
 	__free_one_page(page, pfn, zone, order, migratetype);
+	guest_free_page_enqueue(page, order);
 	spin_unlock(&zone->lock);
+	guest_free_page_try_hinting();
 }
 
 static void __meminit __init_single_page(struct page *page, unsigned long pfn,
diff --git a/virt/kvm/page_hinting.c b/virt/kvm/page_hinting.c
new file mode 100644
index 000000000000..48b4b5e796b0
--- /dev/null
+++ b/virt/kvm/page_hinting.c
@@ -0,0 +1,98 @@
+#include <linux/mm.h>
+#include <linux/page_hinting.h>
+
+/*
+ * struct guest_free_pages- holds array of guest freed PFN's along with an
+ * index variable to track total freed PFN's.
+ * @free_pfn_arr: array to store the page frame number of all the pages which
+ * are freed by the guest.
+ * @guest_free_pages_idx: index to track the number entries stored in
+ * free_pfn_arr.
+ */
+struct guest_free_pages {
+	unsigned long free_page_arr[MAX_FGPT_ENTRIES];
+	int free_pages_idx;
+};
+
+DEFINE_PER_CPU(struct guest_free_pages, free_pages_obj);
+
+struct page *get_buddy_page(struct page *page)
+{
+	unsigned long pfn = page_to_pfn(page);
+	unsigned int order;
+
+	for (order = 0; order < MAX_ORDER; order++) {
+		struct page *page_head = page - (pfn & ((1 << order) - 1));
+
+		if (PageBuddy(page_head) && page_private(page_head) >= order)
+			return page_head;
+	}
+	return NULL;
+}
+
+static void guest_free_page_hinting(void)
+{
+	struct guest_free_pages *hinting_obj = &get_cpu_var(free_pages_obj);
+
+	hinting_obj->free_pages_idx = 0;
+	put_cpu_var(hinting_obj);
+}
+
+int if_exist(struct page *page)
+{
+	int i = 0;
+	struct guest_free_pages *hinting_obj = this_cpu_ptr(&free_pages_obj);
+
+	while (i < MAX_FGPT_ENTRIES) {
+		if (page_to_pfn(page) == hinting_obj->free_page_arr[i])
+			return 1;
+		i++;
+	}
+	return 0;
+}
+
+void guest_free_page_enqueue(struct page *page, int order)
+{
+	unsigned long flags;
+	struct guest_free_pages *hinting_obj;
+	int l_idx;
+
+	/*
+	 * use of global variables may trigger a race condition between irq and
+	 * process context causing unwanted overwrites. This will be replaced
+	 * with a better solution to prevent such race conditions.
+	 */
+	local_irq_save(flags);
+	hinting_obj = this_cpu_ptr(&free_pages_obj);
+	l_idx = hinting_obj->free_pages_idx;
+	if (l_idx != MAX_FGPT_ENTRIES) {
+		if (PageBuddy(page) && page_private(page) >=
+		    FREE_PAGE_HINTING_MIN_ORDER) {
+			hinting_obj->free_page_arr[l_idx] = page_to_pfn(page);
+			hinting_obj->free_pages_idx += 1;
+		} else {
+			struct page *buddy_page = get_buddy_page(page);
+
+			if (buddy_page && page_private(buddy_page) >=
+			    FREE_PAGE_HINTING_MIN_ORDER &&
+			    !if_exist(buddy_page)) {
+				unsigned long buddy_pfn =
+					page_to_pfn(buddy_page);
+
+				hinting_obj->free_page_arr[l_idx] =
+							buddy_pfn;
+				hinting_obj->free_pages_idx += 1;
+			}
+		}
+	}
+	local_irq_restore(flags);
+}
+
+void guest_free_page_try_hinting(void)
+{
+	struct guest_free_pages *hinting_obj;
+
+	hinting_obj = this_cpu_ptr(&free_pages_obj);
+	if (hinting_obj->free_pages_idx >= HINTING_THRESHOLD)
+		guest_free_page_hinting();
+}
-- 
2.17.2

[RFC][Patch v9 2/6] KVM: Enables the kernel to isolate guest free pages

[Nitesh Narayan Lal]

This patch enables the kernel to scan the per cpu array
which carries head pages from the buddy free list of order
FREE_PAGE_HINTING_MIN_ORDER (MAX_ORDER - 1) by
guest_free_page_hinting().
guest_free_page_hinting() scans the entire per cpu array by
acquiring a zone lock corresponding to the pages which are
being scanned. If the page is still free and present in the
buddy it tries to isolate the page and adds it to a
dynamically allocated array.

Once this scanning process is complete and if there are any
isolated pages added to the dynamically allocated array
guest_free_page_report() is invoked. However, before this the
per-cpu array index is reset so that it can continue capturing
the pages from buddy free list.

In this patch guest_free_page_report() simply releases the pages back
to the buddy by using __free_one_page()

Signed-off-by: Nitesh Narayan Lal <nitesh@redhat.com>
---
 include/linux/page_hinting.h |   5 ++
 mm/page_alloc.c              |   2 +-
 virt/kvm/page_hinting.c      | 154 +++++++++++++++++++++++++++++++++++
 3 files changed, 160 insertions(+), 1 deletion(-)

diff --git a/include/linux/page_hinting.h b/include/linux/page_hinting.h
index 90254c582789..d554a2581826 100644
--- a/include/linux/page_hinting.h
+++ b/include/linux/page_hinting.h
@@ -13,3 +13,8 @@
 
 void guest_free_page_enqueue(struct page *page, int order);
 void guest_free_page_try_hinting(void);
+extern int __isolate_free_page(struct page *page, unsigned int order);
+extern void __free_one_page(struct page *page, unsigned long pfn,
+			    struct zone *zone, unsigned int order,
+			    int migratetype);
+void release_buddy_pages(void *obj_to_free, int entries);
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 684d047f33ee..d38b7eea207b 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -814,7 +814,7 @@ static inline int page_is_buddy(struct page *page, struct page *buddy,
  * -- nyc
  */
 
-static inline void __free_one_page(struct page *page,
+inline void __free_one_page(struct page *page,
 		unsigned long pfn,
 		struct zone *zone, unsigned int order,
 		int migratetype)
diff --git a/virt/kvm/page_hinting.c b/virt/kvm/page_hinting.c
index 48b4b5e796b0..9885b372b5a9 100644
--- a/virt/kvm/page_hinting.c
+++ b/virt/kvm/page_hinting.c
@@ -1,5 +1,9 @@
 #include <linux/mm.h>
 #include <linux/page_hinting.h>
+#include <linux/page_ref.h>
+#include <linux/kvm_host.h>
+#include <linux/kernel.h>
+#include <linux/sort.h>
 
 /*
  * struct guest_free_pages- holds array of guest freed PFN's along with an
@@ -16,6 +20,54 @@ struct guest_free_pages {
 
 DEFINE_PER_CPU(struct guest_free_pages, free_pages_obj);
 
+/*
+ * struct guest_isolated_pages- holds the buddy isolated pages which are
+ * supposed to be freed by the host.
+ * @pfn: page frame number for the isolated page.
+ * @order: order of the isolated page.
+ */
+struct guest_isolated_pages {
+	unsigned long pfn;
+	unsigned int order;
+};
+
+void release_buddy_pages(void *obj_to_free, int entries)
+{
+	int i = 0;
+	int mt = 0;
+	struct guest_isolated_pages *isolated_pages_obj = obj_to_free;
+
+	while (i < entries) {
+		struct page *page = pfn_to_page(isolated_pages_obj[i].pfn);
+
+		mt = get_pageblock_migratetype(page);
+		__free_one_page(page, page_to_pfn(page), page_zone(page),
+				isolated_pages_obj[i].order, mt);
+		i++;
+	}
+	kfree(isolated_pages_obj);
+}
+
+void guest_free_page_report(struct guest_isolated_pages *isolated_pages_obj,
+			    int entries)
+{
+	release_buddy_pages(isolated_pages_obj, entries);
+}
+
+static int sort_zonenum(const void *a1, const void *b1)
+{
+	const unsigned long *a = a1;
+	const unsigned long *b = b1;
+
+	if (page_zonenum(pfn_to_page(a[0])) > page_zonenum(pfn_to_page(b[0])))
+		return 1;
+
+	if (page_zonenum(pfn_to_page(a[0])) < page_zonenum(pfn_to_page(b[0])))
+		return -1;
+
+	return 0;
+}
+
 struct page *get_buddy_page(struct page *page)
 {
 	unsigned long pfn = page_to_pfn(page);
@@ -33,9 +85,111 @@ struct page *get_buddy_page(struct page *page)
 static void guest_free_page_hinting(void)
 {
 	struct guest_free_pages *hinting_obj = &get_cpu_var(free_pages_obj);
+	struct guest_isolated_pages *isolated_pages_obj;
+	int idx = 0, ret = 0;
+	struct zone *zone_cur, *zone_prev;
+	unsigned long flags = 0;
+	int hyp_idx = 0;
+	int free_pages_idx = hinting_obj->free_pages_idx;
+
+	isolated_pages_obj = kmalloc(MAX_FGPT_ENTRIES *
+			sizeof(struct guest_isolated_pages), GFP_KERNEL);
+	if (!isolated_pages_obj) {
+		hinting_obj->free_pages_idx = 0;
+		put_cpu_var(hinting_obj);
+		return;
+		/* return some logical error here*/
+	}
+
+	sort(hinting_obj->free_page_arr, free_pages_idx,
+	     sizeof(unsigned long), sort_zonenum, NULL);
+
+	while (idx < free_pages_idx) {
+		unsigned long pfn = hinting_obj->free_page_arr[idx];
+		unsigned long pfn_end = hinting_obj->free_page_arr[idx] +
+			(1 << FREE_PAGE_HINTING_MIN_ORDER) - 1;
+
+		zone_cur = page_zone(pfn_to_page(pfn));
+		if (idx == 0) {
+			zone_prev = zone_cur;
+			spin_lock_irqsave(&zone_cur->lock, flags);
+		} else if (zone_prev != zone_cur) {
+			spin_unlock_irqrestore(&zone_prev->lock, flags);
+			spin_lock_irqsave(&zone_cur->lock, flags);
+			zone_prev = zone_cur;
+		}
+
+		while (pfn <= pfn_end) {
+			struct page *page = pfn_to_page(pfn);
+			struct page *buddy_page = NULL;
+
+			if (PageCompound(page)) {
+				struct page *head_page = compound_head(page);
+				unsigned long head_pfn = page_to_pfn(head_page);
+				unsigned int alloc_pages =
+					1 << compound_order(head_page);
+
+				pfn = head_pfn + alloc_pages;
+				continue;
+			}
+
+			if (page_ref_count(page)) {
+				pfn++;
+				continue;
+			}
+
+			if (PageBuddy(page) && page_private(page) >=
+			    FREE_PAGE_HINTING_MIN_ORDER) {
+				int buddy_order = page_private(page);
+
+				ret = __isolate_free_page(page, buddy_order);
+				if (ret) {
+					isolated_pages_obj[hyp_idx].pfn = pfn;
+					isolated_pages_obj[hyp_idx].order =
+								buddy_order;
+					hyp_idx += 1;
+				}
+				pfn = pfn + (1 << buddy_order);
+				continue;
+			}
+
+			buddy_page = get_buddy_page(page);
+			if (buddy_page && page_private(buddy_page) >=
+			    FREE_PAGE_HINTING_MIN_ORDER) {
+				int buddy_order = page_private(buddy_page);
+
+				ret = __isolate_free_page(buddy_page,
+							  buddy_order);
+				if (ret) {
+					unsigned long buddy_pfn =
+						page_to_pfn(buddy_page);
+
+					isolated_pages_obj[hyp_idx].pfn =
+								buddy_pfn;
+					isolated_pages_obj[hyp_idx].order =
+								buddy_order;
+					hyp_idx += 1;
+				}
+				pfn = page_to_pfn(buddy_page) +
+					(1 << buddy_order);
+				continue;
+			}
+			pfn++;
+		}
+		hinting_obj->free_page_arr[idx] = 0;
+		idx++;
+		if (idx == free_pages_idx)
+			spin_unlock_irqrestore(&zone_cur->lock, flags);
+	}
 
 	hinting_obj->free_pages_idx = 0;
 	put_cpu_var(hinting_obj);
+
+	if (hyp_idx > 0)
+		guest_free_page_report(isolated_pages_obj, hyp_idx);
+	else
+		kfree(isolated_pages_obj);
+		/* return some logical error here*/
 }
 
 int if_exist(struct page *page)
-- 
2.17.2

[RFC][Patch v9 3/6] KVM: Enables the kernel to report isolated pages

[Nitesh Narayan Lal]

This patch enables the kernel to report the isolated pages
to the host via virtio balloon driver.
In order to do so a new virtuqeue (hinting_vq) is added to the
virtio balloon driver. As the host responds back after freeing
the pages, all the isolated pages are returned back to the buddy
via __free_one_page().

Signed-off-by: Nitesh Narayan Lal <nitesh@redhat.com>
---
 drivers/virtio/virtio_balloon.c     | 72 ++++++++++++++++++++++++++++-
 include/linux/page_hinting.h        |  4 ++
 include/uapi/linux/virtio_balloon.h |  8 ++++
 virt/kvm/page_hinting.c             | 18 ++++++--
 4 files changed, 98 insertions(+), 4 deletions(-)

diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
index 728ecd1eea30..cfe7574b5204 100644
--- a/drivers/virtio/virtio_balloon.c
+++ b/drivers/virtio/virtio_balloon.c
@@ -57,13 +57,15 @@ enum virtio_balloon_vq {
 	VIRTIO_BALLOON_VQ_INFLATE,
 	VIRTIO_BALLOON_VQ_DEFLATE,
 	VIRTIO_BALLOON_VQ_STATS,
+	VIRTIO_BALLOON_VQ_HINTING,
 	VIRTIO_BALLOON_VQ_FREE_PAGE,
 	VIRTIO_BALLOON_VQ_MAX
 };
 
 struct virtio_balloon {
 	struct virtio_device *vdev;
-	struct virtqueue *inflate_vq, *deflate_vq, *stats_vq, *free_page_vq;
+	struct virtqueue *inflate_vq, *deflate_vq, *stats_vq, *free_page_vq,
+								*hinting_vq;
 
 	/* Balloon's own wq for cpu-intensive work items */
 	struct workqueue_struct *balloon_wq;
@@ -122,6 +124,56 @@ static struct virtio_device_id id_table[] = {
 	{ 0 },
 };
 
+#ifdef CONFIG_KVM_FREE_PAGE_HINTING
+int virtballoon_page_hinting(struct virtio_balloon *vb,
+			     void *hinting_req,
+			     int entries)
+{
+	struct scatterlist sg;
+	struct virtqueue *vq = vb->hinting_vq;
+	int err;
+	int unused;
+	struct virtio_balloon_hint_req *hint_req;
+	u64 gpaddr;
+
+	hint_req = kmalloc(sizeof(struct virtio_balloon_hint_req), GFP_KERNEL);
+	while (virtqueue_get_buf(vq, &unused))
+		;
+
+	gpaddr = virt_to_phys(hinting_req);
+	hint_req->phys_addr = cpu_to_virtio64(vb->vdev, gpaddr);
+	hint_req->count = cpu_to_virtio32(vb->vdev, entries);
+	sg_init_one(&sg, hint_req, sizeof(struct virtio_balloon_hint_req));
+	err = virtqueue_add_outbuf(vq, &sg, 1, hint_req, GFP_KERNEL);
+	if (!err)
+		virtqueue_kick(vb->hinting_vq);
+	else
+		kfree(hint_req);
+	return err;
+}
+
+static void hinting_ack(struct virtqueue *vq)
+{
+	int len = sizeof(struct virtio_balloon_hint_req);
+	struct virtio_balloon_hint_req *hint_req = virtqueue_get_buf(vq, &len);
+	void *v_addr = phys_to_virt(hint_req->phys_addr);
+
+	release_buddy_pages(v_addr, hint_req->count);
+	kfree(hint_req);
+}
+
+static void enable_hinting(struct virtio_balloon *vb)
+{
+	request_hypercall = (void *)&virtballoon_page_hinting;
+	balloon_ptr = vb;
+}
+
+static void disable_hinting(void)
+{
+	balloon_ptr = NULL;
+}
+#endif
+
 static u32 page_to_balloon_pfn(struct page *page)
 {
 	unsigned long pfn = page_to_pfn(page);
@@ -481,6 +533,7 @@ static int init_vqs(struct virtio_balloon *vb)
 	names[VIRTIO_BALLOON_VQ_DEFLATE] = "deflate";
 	names[VIRTIO_BALLOON_VQ_STATS] = NULL;
 	names[VIRTIO_BALLOON_VQ_FREE_PAGE] = NULL;
+	names[VIRTIO_BALLOON_VQ_HINTING] = NULL;
 
 	if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_STATS_VQ)) {
 		names[VIRTIO_BALLOON_VQ_STATS] = "stats";
@@ -492,11 +545,18 @@ static int init_vqs(struct virtio_balloon *vb)
 		callbacks[VIRTIO_BALLOON_VQ_FREE_PAGE] = NULL;
 	}
 
+	if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_HINTING)) {
+		names[VIRTIO_BALLOON_VQ_HINTING] = "hinting_vq";
+		callbacks[VIRTIO_BALLOON_VQ_HINTING] = hinting_ack;
+	}
 	err = vb->vdev->config->find_vqs(vb->vdev, VIRTIO_BALLOON_VQ_MAX,
 					 vqs, callbacks, names, NULL, NULL);
 	if (err)
 		return err;
 
+	if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_HINTING))
+		vb->hinting_vq = vqs[VIRTIO_BALLOON_VQ_HINTING];
+
 	vb->inflate_vq = vqs[VIRTIO_BALLOON_VQ_INFLATE];
 	vb->deflate_vq = vqs[VIRTIO_BALLOON_VQ_DEFLATE];
 	if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_STATS_VQ)) {
@@ -908,6 +968,11 @@ static int virtballoon_probe(struct virtio_device *vdev)
 		if (err)
 			goto out_del_balloon_wq;
 	}
+
+#ifdef CONFIG_KVM_FREE_PAGE_HINTING
+	if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_HINTING))
+		enable_hinting(vb);
+#endif
 	virtio_device_ready(vdev);
 
 	if (towards_target(vb))
@@ -950,6 +1015,10 @@ static void virtballoon_remove(struct virtio_device *vdev)
 	cancel_work_sync(&vb->update_balloon_size_work);
 	cancel_work_sync(&vb->update_balloon_stats_work);
 
+#ifdef CONFIG_KVM_FREE_PAGE_HINTING
+	if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_HINTING))
+		disable_hinting();
+#endif
 	if (virtio_has_feature(vdev, VIRTIO_BALLOON_F_FREE_PAGE_HINT)) {
 		cancel_work_sync(&vb->report_free_page_work);
 		destroy_workqueue(vb->balloon_wq);
@@ -1009,6 +1078,7 @@ static unsigned int features[] = {
 	VIRTIO_BALLOON_F_MUST_TELL_HOST,
 	VIRTIO_BALLOON_F_STATS_VQ,
 	VIRTIO_BALLOON_F_DEFLATE_ON_OOM,
+	VIRTIO_BALLOON_F_HINTING,
 	VIRTIO_BALLOON_F_FREE_PAGE_HINT,
 	VIRTIO_BALLOON_F_PAGE_POISON,
 };
diff --git a/include/linux/page_hinting.h b/include/linux/page_hinting.h
index d554a2581826..a32af8851081 100644
--- a/include/linux/page_hinting.h
+++ b/include/linux/page_hinting.h
@@ -11,6 +11,8 @@
 #define HINTING_THRESHOLD	128
 #define FREE_PAGE_HINTING_MIN_ORDER	(MAX_ORDER - 1)
 
+extern void *balloon_ptr;
+
 void guest_free_page_enqueue(struct page *page, int order);
 void guest_free_page_try_hinting(void);
 extern int __isolate_free_page(struct page *page, unsigned int order);
@@ -18,3 +20,5 @@ extern void __free_one_page(struct page *page, unsigned long pfn,
 			    struct zone *zone, unsigned int order,
 			    int migratetype);
 void release_buddy_pages(void *obj_to_free, int entries);
+extern int (*request_hypercall)(void *balloon_ptr,
+				void *hinting_req, int entries);
diff --git a/include/uapi/linux/virtio_balloon.h b/include/uapi/linux/virtio_balloon.h
index a1966cd7b677..a7e909d77447 100644
--- a/include/uapi/linux/virtio_balloon.h
+++ b/include/uapi/linux/virtio_balloon.h
@@ -29,6 +29,7 @@
 #include <linux/virtio_types.h>
 #include <linux/virtio_ids.h>
 #include <linux/virtio_config.h>
+#include <linux/page_hinting.h>
 
 /* The feature bitmap for virtio balloon */
 #define VIRTIO_BALLOON_F_MUST_TELL_HOST	0 /* Tell before reclaiming pages */
@@ -36,6 +37,7 @@
 #define VIRTIO_BALLOON_F_DEFLATE_ON_OOM	2 /* Deflate balloon on OOM */
 #define VIRTIO_BALLOON_F_FREE_PAGE_HINT	3 /* VQ to report free pages */
 #define VIRTIO_BALLOON_F_PAGE_POISON	4 /* Guest is using page poisoning */
+#define VIRTIO_BALLOON_F_HINTING	5 /* Page hinting virtqueue */
 
 /* Size of a PFN in the balloon interface. */
 #define VIRTIO_BALLOON_PFN_SHIFT 12
@@ -108,4 +110,10 @@ struct virtio_balloon_stat {
 	__virtio64 val;
 } __attribute__((packed));
 
+#ifdef CONFIG_KVM_FREE_PAGE_HINTING
+struct virtio_balloon_hint_req {
+	__virtio64 phys_addr;
+	__virtio64 count;
+};
+#endif
 #endif /* _LINUX_VIRTIO_BALLOON_H */
diff --git a/virt/kvm/page_hinting.c b/virt/kvm/page_hinting.c
index 9885b372b5a9..eb0c0ddfe990 100644
--- a/virt/kvm/page_hinting.c
+++ b/virt/kvm/page_hinting.c
@@ -31,11 +31,16 @@ struct guest_isolated_pages {
 	unsigned int order;
 };
 
-void release_buddy_pages(void *obj_to_free, int entries)
+int (*request_hypercall)(void *balloon_ptr, void *hinting_req, int entries);
+EXPORT_SYMBOL(request_hypercall);
+void *balloon_ptr;
+EXPORT_SYMBOL(balloon_ptr);
+
+void release_buddy_pages(void *hinting_req, int entries)
 {
 	int i = 0;
 	int mt = 0;
-	struct guest_isolated_pages *isolated_pages_obj = obj_to_free;
+	struct guest_isolated_pages *isolated_pages_obj = hinting_req;
 
 	while (i < entries) {
 		struct page *page = pfn_to_page(isolated_pages_obj[i].pfn);
@@ -51,7 +56,14 @@ void release_buddy_pages(void *obj_to_free, int entries)
 void guest_free_page_report(struct guest_isolated_pages *isolated_pages_obj,
 			    int entries)
 {
-	release_buddy_pages(isolated_pages_obj, entries);
+	int err = 0;
+
+	if (balloon_ptr) {
+		err = request_hypercall(balloon_ptr, isolated_pages_obj,
+					entries);
+		if (err)
+			release_buddy_pages(isolated_pages_obj, entries);
+	}
 }
 
 static int sort_zonenum(const void *a1, const void *b1)
-- 
2.17.2

[RFC][Patch v9 4/6] KVM: Reporting page poisoning value to the host

[Nitesh Narayan Lal]

This patch enables the kernel to report the page poisoning value
to the host by using VIRTIO_BALLOON_F_PAGE_POISON feature.
Page Poisoning is a feature in which the page is filled with a specific
pattern of (0x00 or 0xaa) after freeing and the same is verified
before allocation to prevent following issues:
    *information leak from the freed data
    *use after free bugs
    *memory corruption
The issue arises when the pattern used for Page Poisoning is 0xaa while
the newly allocated page received from the host by the guest is
filled with the pattern 0x00. This will result in memory corruption errors.

Signed-off-by: Nitesh Narayan Lal <nitesh@redhat.com>
---
 drivers/virtio/virtio_balloon.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
index cfe7574b5204..e82c72cd916b 100644
--- a/drivers/virtio/virtio_balloon.c
+++ b/drivers/virtio/virtio_balloon.c
@@ -970,6 +970,11 @@ static int virtballoon_probe(struct virtio_device *vdev)
 	}
 
 #ifdef CONFIG_KVM_FREE_PAGE_HINTING
+	if (virtio_has_feature(vdev, VIRTIO_BALLOON_F_PAGE_POISON)) {
+		memset(&poison_val, PAGE_POISON, sizeof(poison_val));
+		virtio_cwrite(vb->vdev, struct virtio_balloon_config,
+			      poison_val, &poison_val);
+	}
 	if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_HINTING))
 		enable_hinting(vb);
 #endif
-- 
2.17.2

[RFC][Patch v9 5/6] KVM: Enabling guest free page hinting via static key

[Nitesh Narayan Lal]

This patch enables the guest free page hinting support
to enable or disable based on the STATIC key which
could be set via sysctl.

Signed-off-by: Nitesh Narayan Lal <nitesh@redhat.com>
---
 Documentation/sysctl/vm.txt     | 12 ++++++++++++
 drivers/virtio/virtio_balloon.c |  4 ++++
 include/linux/page_hinting.h    |  5 +++++
 kernel/sysctl.c                 | 12 ++++++++++++
 virt/kvm/page_hinting.c         | 26 ++++++++++++++++++++++++++
 5 files changed, 59 insertions(+)

diff --git a/Documentation/sysctl/vm.txt b/Documentation/sysctl/vm.txt
index 187ce4f599a2..eae9180ea0aa 100644
--- a/Documentation/sysctl/vm.txt
+++ b/Documentation/sysctl/vm.txt
@@ -31,6 +31,7 @@ Currently, these files are in /proc/sys/vm:
 - dirty_writeback_centisecs
 - drop_caches
 - extfrag_threshold
+- guest_free_page_hinting
 - hugetlb_shm_group
 - laptop_mode
 - legacy_va_layout
@@ -255,6 +256,17 @@ fragmentation index is <= extfrag_threshold. The default value is 500.
 
 ==============================================================
 
+guest_free_page_hinting
+
+This parameter enables the kernel to report KVM guest free pages to the host
+via virtio balloon driver. QEMU receives these free page hints and frees them
+by performing MADVISE_DONTNEED on it.
+
+It depends on VIRTIO_BALLOON for its functionality. In case VIRTIO_BALLOON
+driver is missing, this feature is disabled by default.
+
+==============================================================
+
 highmem_is_dirtyable
 
 Available only for systems with CONFIG_HIGHMEM enabled (32b systems).
diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
index e82c72cd916b..171fd72ef2ae 100644
--- a/drivers/virtio/virtio_balloon.c
+++ b/drivers/virtio/virtio_balloon.c
@@ -164,12 +164,16 @@ static void hinting_ack(struct virtqueue *vq)
 
 static void enable_hinting(struct virtio_balloon *vb)
 {
+	guest_free_page_hinting_flag = 1;
+	static_branch_enable(&guest_free_page_hinting_key);
 	request_hypercall = (void *)&virtballoon_page_hinting;
 	balloon_ptr = vb;
 }
 
 static void disable_hinting(void)
 {
+	guest_free_page_hinting_flag = 0;
+	static_branch_enable(&guest_free_page_hinting_key);
 	balloon_ptr = NULL;
 }
 #endif
diff --git a/include/linux/page_hinting.h b/include/linux/page_hinting.h
index a32af8851081..60e0a21bfbe6 100644
--- a/include/linux/page_hinting.h
+++ b/include/linux/page_hinting.h
@@ -12,6 +12,8 @@
 #define FREE_PAGE_HINTING_MIN_ORDER	(MAX_ORDER - 1)
 
 extern void *balloon_ptr;
+extern int guest_free_page_hinting_flag;
+extern struct static_key_false guest_free_page_hinting_key;
 
 void guest_free_page_enqueue(struct page *page, int order);
 void guest_free_page_try_hinting(void);
@@ -22,3 +24,6 @@ extern void __free_one_page(struct page *page, unsigned long pfn,
 void release_buddy_pages(void *obj_to_free, int entries);
 extern int (*request_hypercall)(void *balloon_ptr,
 				void *hinting_req, int entries);
+int guest_free_page_hinting_sysctl(struct ctl_table *table, int write,
+				   void __user *buffer, size_t *lenp,
+				   loff_t *ppos);
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index ba4d9e85feb8..7b2970e9e937 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -96,6 +96,9 @@
 #ifdef CONFIG_LOCKUP_DETECTOR
 #include <linux/nmi.h>
 #endif
+#ifdef CONFIG_KVM_FREE_PAGE_HINTING
+#include <linux/page_hinting.h>
+#endif
 
 #if defined(CONFIG_SYSCTL)
 
@@ -1690,6 +1693,15 @@ static struct ctl_table vm_table[] = {
 		.extra1		= (void *)&mmap_rnd_compat_bits_min,
 		.extra2		= (void *)&mmap_rnd_compat_bits_max,
 	},
+#endif
+#ifdef CONFIG_KVM_FREE_PAGE_HINTING
+	{
+		.procname       = "guest-free-page-hinting",
+		.data           = &guest_free_page_hinting_flag,
+		.maxlen         = sizeof(guest_free_page_hinting_flag),
+		.mode           = 0644,
+		.proc_handler   = guest_free_page_hinting_sysctl,
+	},
 #endif
 	{ }
 };
diff --git a/virt/kvm/page_hinting.c b/virt/kvm/page_hinting.c
index eb0c0ddfe990..5980682e0b86 100644
--- a/virt/kvm/page_hinting.c
+++ b/virt/kvm/page_hinting.c
@@ -36,6 +36,28 @@ EXPORT_SYMBOL(request_hypercall);
 void *balloon_ptr;
 EXPORT_SYMBOL(balloon_ptr);
 
+struct static_key_false guest_free_page_hinting_key  = STATIC_KEY_FALSE_INIT;
+EXPORT_SYMBOL(guest_free_page_hinting_key);
+static DEFINE_MUTEX(hinting_mutex);
+int guest_free_page_hinting_flag;
+EXPORT_SYMBOL(guest_free_page_hinting_flag);
+
+int guest_free_page_hinting_sysctl(struct ctl_table *table, int write,
+				   void __user *buffer, size_t *lenp,
+				   loff_t *ppos)
+{
+	int ret;
+
+	mutex_lock(&hinting_mutex);
+	ret = proc_dointvec(table, write, buffer, lenp, ppos);
+	if (guest_free_page_hinting_flag)
+		static_key_enable(&guest_free_page_hinting_key.key);
+	else
+		static_key_disable(&guest_free_page_hinting_key.key);
+	mutex_unlock(&hinting_mutex);
+	return ret;
+}
+
 void release_buddy_pages(void *hinting_req, int entries)
 {
 	int i = 0;
@@ -223,6 +245,8 @@ void guest_free_page_enqueue(struct page *page, int order)
 	struct guest_free_pages *hinting_obj;
 	int l_idx;
 
+	if (!static_branch_unlikely(&guest_free_page_hinting_key))
+		return;
 	/*
 	 * use of global variables may trigger a race condition between irq and
 	 * process context causing unwanted overwrites. This will be replaced
@@ -258,6 +282,8 @@ void guest_free_page_try_hinting(void)
 {
 	struct guest_free_pages *hinting_obj;
 
+	if (!static_branch_unlikely(&guest_free_page_hinting_key))
+		return;
 	hinting_obj = this_cpu_ptr(&free_pages_obj);
 	if (hinting_obj->free_pages_idx >= HINTING_THRESHOLD)
 		guest_free_page_hinting();
-- 
2.17.2

[RFC][Patch v9 6/6] KVM: Adding tracepoints for guest free page hinting

[Nitesh Narayan Lal]

This patch enables to track the pages freed by the guest and
the pages isolated by the page hinting code through kernel
tracepoints.

Signed-off-by: Nitesh Narayan Lal <nitesh@redhat.com>
---
 include/trace/events/kmem.h | 62 +++++++++++++++++++++++++++++++++++++
 virt/kvm/page_hinting.c     | 12 +++++++
 2 files changed, 74 insertions(+)

diff --git a/include/trace/events/kmem.h b/include/trace/events/kmem.h
index eb57e3037deb..0bef31484cf8 100644
--- a/include/trace/events/kmem.h
+++ b/include/trace/events/kmem.h
@@ -315,6 +315,68 @@ TRACE_EVENT(mm_page_alloc_extfrag,
 		__entry->change_ownership)
 );
 
+TRACE_EVENT(guest_free_page,
+	    TP_PROTO(unsigned long pfn, unsigned int order),
+
+	TP_ARGS(pfn, order),
+
+	TP_STRUCT__entry(
+		__field(unsigned long, pfn)
+		__field(unsigned int, order)
+	),
+
+	TP_fast_assign(
+		__entry->pfn            = pfn;
+		__entry->order          = order;
+	),
+
+	TP_printk("pfn=%lu order=%d",
+		  __entry->pfn,
+		  __entry->order)
+);
+
+TRACE_EVENT(guest_isolated_page,
+	    TP_PROTO(unsigned long pfn, unsigned int order),
+
+	TP_ARGS(pfn, order),
+
+	TP_STRUCT__entry(
+		__field(unsigned long, pfn)
+		__field(unsigned int, order)
+	),
+
+	TP_fast_assign(
+		__entry->pfn            = pfn;
+		__entry->order          = order;
+	),
+
+	TP_printk("pfn=%lu order=%u",
+		  __entry->pfn,
+		  __entry->order)
+);
+
+TRACE_EVENT(guest_captured_page,
+	    TP_PROTO(unsigned long pfn, unsigned int order, int idx),
+
+	TP_ARGS(pfn, order, idx),
+
+	TP_STRUCT__entry(
+		__field(unsigned long, pfn)
+		__field(unsigned int, order)
+		__field(int, idx)
+	),
+
+	TP_fast_assign(
+		__entry->pfn		= pfn;
+		__entry->order		= order;
+		__entry->idx		= idx;
+	),
+
+	TP_printk("pfn=%lu order=%u array_index=%d",
+		  __entry->pfn,
+		  __entry->order,
+		  __entry->idx)
+);
 #endif /* _TRACE_KMEM_H */
 
 /* This part must be outside protection */
diff --git a/virt/kvm/page_hinting.c b/virt/kvm/page_hinting.c
index 5980682e0b86..dc72f1947751 100644
--- a/virt/kvm/page_hinting.c
+++ b/virt/kvm/page_hinting.c
@@ -4,6 +4,7 @@
 #include <linux/kvm_host.h>
 #include <linux/kernel.h>
 #include <linux/sort.h>
+#include <trace/events/kmem.h>
 
 /*
  * struct guest_free_pages- holds array of guest freed PFN's along with an
@@ -178,6 +179,8 @@ static void guest_free_page_hinting(void)
 
 				ret = __isolate_free_page(page, buddy_order);
 				if (ret) {
+					trace_guest_isolated_page(pfn,
+								  buddy_order);
 					isolated_pages_obj[hyp_idx].pfn = pfn;
 					isolated_pages_obj[hyp_idx].order =
 								buddy_order;
@@ -198,6 +201,8 @@ static void guest_free_page_hinting(void)
 					unsigned long buddy_pfn =
 						page_to_pfn(buddy_page);
 
+					trace_guest_isolated_page(buddy_pfn,
+								  buddy_order);
 					isolated_pages_obj[hyp_idx].pfn =
 								buddy_pfn;
 					isolated_pages_obj[hyp_idx].order =
@@ -255,9 +260,12 @@ void guest_free_page_enqueue(struct page *page, int order)
 	local_irq_save(flags);
 	hinting_obj = this_cpu_ptr(&free_pages_obj);
 	l_idx = hinting_obj->free_pages_idx;
+	trace_guest_free_page(page_to_pfn(page), order);
 	if (l_idx != MAX_FGPT_ENTRIES) {
 		if (PageBuddy(page) && page_private(page) >=
 		    FREE_PAGE_HINTING_MIN_ORDER) {
+			trace_guest_captured_page(page_to_pfn(page), order,
+						  l_idx);
 			hinting_obj->free_page_arr[l_idx] = page_to_pfn(page);
 			hinting_obj->free_pages_idx += 1;
 		} else {
@@ -268,7 +276,11 @@ void guest_free_page_enqueue(struct page *page, int order)
 			    !if_exist(buddy_page)) {
 				unsigned long buddy_pfn =
 					page_to_pfn(buddy_page);
+				unsigned int buddy_order =
+					page_private(buddy_page);
 
+				trace_guest_captured_page(buddy_pfn,
+							  buddy_order, l_idx);
 				hinting_obj->free_page_arr[l_idx] =
 							buddy_pfn;
 				hinting_obj->free_pages_idx += 1;
-- 
2.17.2

[RFC][QEMU Patch] KVM: Enable QEMU to free the pages hinted by the guest

[Nitesh Narayan Lal]

This patch enables QEMU to perform MADVISE_DONTNEED on the pages
reported by the guest.

Signed-off-by: Nitesh Narayan Lal <nitesh@redhat.com>
---
 hw/virtio/trace-events                        |  1 +
 hw/virtio/virtio-balloon.c                    | 90 +++++++++++++++++++
 include/hw/virtio/virtio-balloon.h            |  2 +-
 .../standard-headers/linux/virtio_balloon.h   |  1 +
 4 files changed, 93 insertions(+), 1 deletion(-)

diff --git a/hw/virtio/trace-events b/hw/virtio/trace-events
index 07bcbe9e85..e3ab66f126 100644
--- a/hw/virtio/trace-events
+++ b/hw/virtio/trace-events
@@ -46,3 +46,4 @@ virtio_balloon_handle_output(const char *name, uint64_t gpa) "section name: %s g
 virtio_balloon_get_config(uint32_t num_pages, uint32_t actual) "num_pages: %d actual: %d"
 virtio_balloon_set_config(uint32_t actual, uint32_t oldactual) "actual: %d oldactual: %d"
 virtio_balloon_to_target(uint64_t target, uint32_t num_pages) "balloon target: 0x%"PRIx64" num_pages: %d"
+virtio_balloon_hinting_request(unsigned long pfn, unsigned int num_pages) "Guest page hinting request: %lu num_pages: %d"
diff --git a/hw/virtio/virtio-balloon.c b/hw/virtio/virtio-balloon.c
index a12677d4d5..7ab1471017 100644
--- a/hw/virtio/virtio-balloon.c
+++ b/hw/virtio/virtio-balloon.c
@@ -33,6 +33,13 @@
 
 #define BALLOON_PAGE_SIZE  (1 << VIRTIO_BALLOON_PFN_SHIFT)
 
+struct guest_pages {
+	unsigned long pfn;
+	unsigned int order;
+};
+
+void page_hinting_request(uint64_t addr, uint32_t len);
+
 static void balloon_page(void *addr, int deflate)
 {
     if (!qemu_balloon_is_inhibited()) {
@@ -207,6 +214,85 @@ static void balloon_stats_set_poll_interval(Object *obj, Visitor *v,
     balloon_stats_change_timer(s, 0);
 }
 
+static void *gpa2hva(MemoryRegion **p_mr, hwaddr addr, Error **errp)
+{
+    MemoryRegionSection mrs = memory_region_find(get_system_memory(),
+                                                 addr, 1);
+
+    if (!mrs.mr) {
+        error_setg(errp, "No memory is mapped at address 0x%" HWADDR_PRIx, addr);
+        return NULL;
+    }
+
+    if (!memory_region_is_ram(mrs.mr) && !memory_region_is_romd(mrs.mr)) {
+        error_setg(errp, "Memory at address 0x%" HWADDR_PRIx "is not RAM", addr);
+        memory_region_unref(mrs.mr);
+        return NULL;
+    }
+
+    *p_mr = mrs.mr;
+    return qemu_map_ram_ptr(mrs.mr->ram_block, mrs.offset_within_region);
+}
+
+void page_hinting_request(uint64_t addr, uint32_t len)
+{
+    Error *local_err = NULL;
+    MemoryRegion *mr = NULL;
+    int ret = 0;
+    struct guest_pages *guest_obj;
+    int i = 0;
+    void *hvaddr_to_free;
+    unsigned long pfn, pfn_end;
+    uint64_t gpaddr_to_free;
+    void * temp_addr = gpa2hva(&mr, addr, &local_err);
+
+    if (local_err) {
+        error_report_err(local_err);
+        return;
+    }
+    guest_obj = temp_addr;
+    while (i < len) {
+        pfn = guest_obj[i].pfn;
+	pfn_end = guest_obj[i].pfn + (1 << guest_obj[i].order) - 1;
+	trace_virtio_balloon_hinting_request(pfn,(1 << guest_obj[i].order));
+	while (pfn <= pfn_end) {
+	        gpaddr_to_free = pfn << VIRTIO_BALLOON_PFN_SHIFT;
+	        hvaddr_to_free = gpa2hva(&mr, gpaddr_to_free, &local_err);
+	        if (local_err) {
+			error_report_err(local_err);
+		        return;
+		}
+		ret = qemu_madvise((void *)hvaddr_to_free, 4096, QEMU_MADV_DONTNEED);
+		if (ret == -1)
+		    printf("\n%d:%s Error: Madvise failed with error:%d\n", __LINE__, __func__, ret);
+		pfn++;
+	}
+	i++;
+    }
+}
+
+static void virtio_balloon_page_hinting(VirtIODevice *vdev, VirtQueue *vq)
+{
+    VirtQueueElement *elem = NULL;
+    uint64_t temp_addr;
+    uint32_t temp_len;
+    size_t size, t_size = 0;
+
+    elem = virtqueue_pop(vq, sizeof(VirtQueueElement));
+    if (!elem) {
+	printf("\npop error\n");
+	return;
+    }
+    size = iov_to_buf(elem->out_sg, elem->out_num, 0, &temp_addr, sizeof(temp_addr));
+    t_size += size;
+    size = iov_to_buf(elem->out_sg, elem->out_num, 8, &temp_len, sizeof(temp_len));
+    t_size += size;
+    page_hinting_request(temp_addr, temp_len);
+    virtqueue_push(vq, elem, t_size);
+    virtio_notify(vdev, vq);
+    g_free(elem);
+}
+
 static void virtio_balloon_handle_output(VirtIODevice *vdev, VirtQueue *vq)
 {
     VirtIOBalloon *s = VIRTIO_BALLOON(vdev);
@@ -376,6 +462,7 @@ 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);
+    virtio_add_feature(&f, VIRTIO_BALLOON_F_HINTING);
     return f;
 }
 
@@ -445,6 +532,7 @@ static void virtio_balloon_device_realize(DeviceState *dev, Error **errp)
     s->ivq = virtio_add_queue(vdev, 128, virtio_balloon_handle_output);
     s->dvq = virtio_add_queue(vdev, 128, virtio_balloon_handle_output);
     s->svq = virtio_add_queue(vdev, 128, virtio_balloon_receive_stats);
+    s->hvq = virtio_add_queue(vdev, 128, virtio_balloon_page_hinting);
 
     reset_stats(s);
 }
@@ -488,6 +576,8 @@ static void virtio_balloon_instance_init(Object *obj)
 
     object_property_add(obj, "guest-stats", "guest statistics",
                         balloon_stats_get_all, NULL, NULL, s, NULL);
+    object_property_add(obj, "guest-page-hinting", "guest page hinting",
+                        NULL, NULL, NULL, s, NULL);
 
     object_property_add(obj, "guest-stats-polling-interval", "int",
                         balloon_stats_get_poll_interval,
diff --git a/include/hw/virtio/virtio-balloon.h b/include/hw/virtio/virtio-balloon.h
index e0df3528c8..774498a6ca 100644
--- a/include/hw/virtio/virtio-balloon.h
+++ b/include/hw/virtio/virtio-balloon.h
@@ -32,7 +32,7 @@ typedef struct virtio_balloon_stat_modern {
 
 typedef struct VirtIOBalloon {
     VirtIODevice parent_obj;
-    VirtQueue *ivq, *dvq, *svq;
+    VirtQueue *ivq, *dvq, *svq, *hvq;
     uint32_t num_pages;
     uint32_t actual;
     uint64_t stats[VIRTIO_BALLOON_S_NR];
diff --git a/include/standard-headers/linux/virtio_balloon.h b/include/standard-headers/linux/virtio_balloon.h
index 4dbb7dc6c0..f50c0d95ea 100644
--- a/include/standard-headers/linux/virtio_balloon.h
+++ b/include/standard-headers/linux/virtio_balloon.h
@@ -34,6 +34,7 @@
 #define VIRTIO_BALLOON_F_MUST_TELL_HOST	0 /* Tell before reclaiming pages */
 #define VIRTIO_BALLOON_F_STATS_VQ	1 /* Memory Stats virtqueue */
 #define VIRTIO_BALLOON_F_DEFLATE_ON_OOM	2 /* Deflate balloon on OOM */
+#define VIRTIO_BALLOON_F_HINTING	5 /* Page hinting virtqueue */
 
 /* Size of a PFN in the balloon interface. */
 #define VIRTIO_BALLOON_PFN_SHIFT 12
-- 
2.17.2

Re: [RFC][Patch v9 0/6] KVM: Guest Free Page Hinting

[Michael S. Tsirkin]

On Wed, Mar 06, 2019 at 10:50:42AM -0500, Nitesh Narayan Lal wrote:
> The following patch-set proposes an efficient mechanism for handing freed memory between the guest and the host. It enables the guests with no page cache to rapidly free and reclaims memory to and from the host respectively.
> 
> Benefit:
> With this patch-series, in our test-case, executed on a single system and single NUMA node with 15GB memory, we were able to successfully launch 5 guests(each with 5 GB memory) when page hinting was enabled and 3 without it. (Detailed explanation of the test procedure is provided at the bottom under Test - 1).
> 
> Changelog in v9:
> 	* Guest free page hinting hook is now invoked after a page has been merged in the buddy.
>         * Free pages only with order FREE_PAGE_HINTING_MIN_ORDER(currently defined as MAX_ORDER - 1) are captured.
> 	* Removed kthread which was earlier used to perform the scanning, isolation & reporting of free pages.
> 	* Pages, captured in the per cpu array are sorted based on the zone numbers. This is to avoid redundancy of acquiring zone locks.
>         * Dynamically allocated space is used to hold the isolated guest free pages.
>         * All the pages are reported asynchronously to the host via virtio driver.
>         * Pages are returned back to the guest buddy free list only when the host response is received.
> 
> Pending items:
>         * Make sure that the guest free page hinting's current implementation doesn't break hugepages or device assigned guests.
> 	* Follow up on VIRTIO_BALLOON_F_PAGE_POISON's device side support. (It is currently missing)
>         * Compare reporting free pages via vring with vhost.
>         * Decide between MADV_DONTNEED and MADV_FREE.
> 	* Analyze overall performance impact due to guest free page hinting.
> 	* Come up with proper/traceable error-message/logs.
> 
> Tests:
> 1. Use-case - Number of guests we can launch
> 
> 	NUMA Nodes = 1 with 15 GB memory
> 	Guest Memory = 5 GB
> 	Number of cores in guest = 1
> 	Workload = test allocation program allocates 4GB memory, touches it via memset and exits.
> 	Procedure =
> 	The first guest is launched and once its console is up, the test allocation program is executed with 4 GB memory request (Due to this the guest occupies almost 4-5 GB of memory in the host in a system without page hinting). Once this program exits at that time another guest is launched in the host and the same process is followed. We continue launching the guests until a guest gets killed due to low memory condition in the host.
> 
> 	Results:
> 	Without hinting = 3
> 	With hinting = 5
> 
> 2. Hackbench
> 	Guest Memory = 5 GB 
> 	Number of cores = 4
> 	Number of tasks		Time with Hinting	Time without Hinting
> 	4000			19.540			17.818
> 

How about memhog btw?
Alex reported:

	My testing up till now has consisted of setting up 4 8GB VMs on a system
	with 32GB of memory and 4GB of swap. To stress the memory on the system I
	would run "memhog 8G" sequentially on each of the guests and observe how
	long it took to complete the run. The observed behavior is that on the
	systems with these patches applied in both the guest and on the host I was
	able to complete the test with a time of 5 to 7 seconds per guest. On a
	system without these patches the time ranged from 7 to 49 seconds per
	guest. I am assuming the variability is due to time being spent writing
	pages out to disk in order to free up space for the guest.

Re: [RFC][Patch v9 0/6] KVM: Guest Free Page Hinting

[Alexander Duyck]

On Wed, Mar 6, 2019 at 7:51 AM Nitesh Narayan Lal <nitesh@redhat.com> wrote:
>
> The following patch-set proposes an efficient mechanism for handing freed memory between the guest and the host. It enables the guests with no page cache to rapidly free and reclaims memory to and from the host respectively.
>
> Benefit:
> With this patch-series, in our test-case, executed on a single system and single NUMA node with 15GB memory, we were able to successfully launch 5 guests(each with 5 GB memory) when page hinting was enabled and 3 without it. (Detailed explanation of the test procedure is provided at the bottom under Test - 1).
>
> Changelog in v9:
>         * Guest free page hinting hook is now invoked after a page has been merged in the buddy.
>         * Free pages only with order FREE_PAGE_HINTING_MIN_ORDER(currently defined as MAX_ORDER - 1) are captured.
>         * Removed kthread which was earlier used to perform the scanning, isolation & reporting of free pages.

Without a kthread this has the potential to get really ugly really
fast. If we are going to run asynchronously we should probably be
truly asynchonous and just place a few pieces of data in the page that
a worker thread can use to identify which pages have been hinted and
which pages have not. Then we can have that one thread just walking
through the zone memory pulling out fixed size pieces at a time and
providing hints on that. By doing that we avoid the potential of
creating a batch of pages that eat up most of the system memory.

>         * Pages, captured in the per cpu array are sorted based on the zone numbers. This is to avoid redundancy of acquiring zone locks.
>         * Dynamically allocated space is used to hold the isolated guest free pages.

I have concerns that doing this per CPU and allocating memory
dynamically can result in you losing a significant amount of memory as
it sits waiting to be hinted.

>         * All the pages are reported asynchronously to the host via virtio driver.
>         * Pages are returned back to the guest buddy free list only when the host response is received.

I have been thinking about this. Instead of stealing the page couldn't
you simply flag it that there is a hint in progress and simply wait in
arch_alloc_page until the hint has been processed? The problem is in
stealing pages you are going to introduce false OOM issues when the
memory isn't available because it is being hinted on.

> Pending items:
>         * Make sure that the guest free page hinting's current implementation doesn't break hugepages or device assigned guests.
>         * Follow up on VIRTIO_BALLOON_F_PAGE_POISON's device side support. (It is currently missing)
>         * Compare reporting free pages via vring with vhost.
>         * Decide between MADV_DONTNEED and MADV_FREE.
>         * Analyze overall performance impact due to guest free page hinting.
>         * Come up with proper/traceable error-message/logs.

I'll try applying these patches and see if I can reproduce the results
you reported. With the last patch set I couldn't reproduce the results
as you reported them. It has me wondering if you were somehow seeing
the effects of a balloon instead of the actual memory hints as I
couldn't find any evidence of the memory ever actually being freed
back by the hints functionality.

Also do you have any idea if this patch set will work with an SMP
setup or is it still racy? I might try enabling SMP in my environment
to see if I can test the scalability of the VM with something like a
will-it-scale test.

> Tests:
> 1. Use-case - Number of guests we can launch
>
>         NUMA Nodes = 1 with 15 GB memory
>         Guest Memory = 5 GB
>         Number of cores in guest = 1
>         Workload = test allocation program allocates 4GB memory, touches it via memset and exits.
>         Procedure =
>         The first guest is launched and once its console is up, the test allocation program is executed with 4 GB memory request (Due to this the guest occupies almost 4-5 GB of memory in the host in a system without page hinting). Once this program exits at that time another guest is launched in the host and the same process is followed. We continue launching the guests until a guest gets killed due to low memory condition in the host.
>
>         Results:
>         Without hinting = 3
>         With hinting = 5
>
> 2. Hackbench
>         Guest Memory = 5 GB
>         Number of cores = 4
>         Number of tasks         Time with Hinting       Time without Hinting
>         4000                    19.540                  17.818
>
>

Re: [RFC][Patch v9 0/6] KVM: Guest Free Page Hinting

[Nitesh Narayan Lal]

[-- Attachment #1.1: Type: text/plain, Size: 4453 bytes --]


On 3/6/19 11:09 AM, Michael S. Tsirkin wrote:
> On Wed, Mar 06, 2019 at 10:50:42AM -0500, Nitesh Narayan Lal wrote:
>> The following patch-set proposes an efficient mechanism for handing freed memory between the guest and the host. It enables the guests with no page cache to rapidly free and reclaims memory to and from the host respectively.
>>
>> Benefit:
>> With this patch-series, in our test-case, executed on a single system and single NUMA node with 15GB memory, we were able to successfully launch 5 guests(each with 5 GB memory) when page hinting was enabled and 3 without it. (Detailed explanation of the test procedure is provided at the bottom under Test - 1).
>>
>> Changelog in v9:
>> 	* Guest free page hinting hook is now invoked after a page has been merged in the buddy.
>>         * Free pages only with order FREE_PAGE_HINTING_MIN_ORDER(currently defined as MAX_ORDER - 1) are captured.
>> 	* Removed kthread which was earlier used to perform the scanning, isolation & reporting of free pages.
>> 	* Pages, captured in the per cpu array are sorted based on the zone numbers. This is to avoid redundancy of acquiring zone locks.
>>         * Dynamically allocated space is used to hold the isolated guest free pages.
>>         * All the pages are reported asynchronously to the host via virtio driver.
>>         * Pages are returned back to the guest buddy free list only when the host response is received.
>>
>> Pending items:
>>         * Make sure that the guest free page hinting's current implementation doesn't break hugepages or device assigned guests.
>> 	* Follow up on VIRTIO_BALLOON_F_PAGE_POISON's device side support. (It is currently missing)
>>         * Compare reporting free pages via vring with vhost.
>>         * Decide between MADV_DONTNEED and MADV_FREE.
>> 	* Analyze overall performance impact due to guest free page hinting.
>> 	* Come up with proper/traceable error-message/logs.
>>
>> Tests:
>> 1. Use-case - Number of guests we can launch
>>
>> 	NUMA Nodes = 1 with 15 GB memory
>> 	Guest Memory = 5 GB
>> 	Number of cores in guest = 1
>> 	Workload = test allocation program allocates 4GB memory, touches it via memset and exits.
>> 	Procedure =
>> 	The first guest is launched and once its console is up, the test allocation program is executed with 4 GB memory request (Due to this the guest occupies almost 4-5 GB of memory in the host in a system without page hinting). Once this program exits at that time another guest is launched in the host and the same process is followed. We continue launching the guests until a guest gets killed due to low memory condition in the host.
>>
>> 	Results:
>> 	Without hinting = 3
>> 	With hinting = 5
>>
>> 2. Hackbench
>> 	Guest Memory = 5 GB 
>> 	Number of cores = 4
>> 	Number of tasks		Time with Hinting	Time without Hinting
>> 	4000			19.540			17.818
>>
> How about memhog btw?
> Alex reported:
>
> 	My testing up till now has consisted of setting up 4 8GB VMs on a system
> 	with 32GB of memory and 4GB of swap. To stress the memory on the system I
> 	would run "memhog 8G" sequentially on each of the guests and observe how
> 	long it took to complete the run. The observed behavior is that on the
> 	systems with these patches applied in both the guest and on the host I was
> 	able to complete the test with a time of 5 to 7 seconds per guest. On a
> 	system without these patches the time ranged from 7 to 49 seconds per
> 	guest. I am assuming the variability is due to time being spent writing
> 	pages out to disk in order to free up space for the guest.
>
Here are the results:

Procedure: 3 Guests of size 5GB is launched on a single NUMA node with
total memory of 15GB and no swap. In each of the guest, memhog is run
with 5GB. Post-execution of memhog, Host memory usage is monitored by
using Free command.

Without Hinting:
                 Time of execution    Host used memory
Guest 1:        45 seconds            5.4 GB
Guest 2:        45 seconds            10 GB
Guest 3:        1  minute               15 GB

With Hinting:
                Time of execution     Host used memory
Guest 1:        49 seconds            2.4 GB
Guest 2:        40 seconds            4.3 GB
Guest 3:        50 seconds            6.3 GB

-- 
Regards
Nitesh


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [RFC][Patch v9 0/6] KVM: Guest Free Page Hinting

[Michael S. Tsirkin]

On Wed, Mar 06, 2019 at 01:07:50PM -0500, Nitesh Narayan Lal wrote:
> 
> On 3/6/19 11:09 AM, Michael S. Tsirkin wrote:
> > On Wed, Mar 06, 2019 at 10:50:42AM -0500, Nitesh Narayan Lal wrote:
> >> The following patch-set proposes an efficient mechanism for handing freed memory between the guest and the host. It enables the guests with no page cache to rapidly free and reclaims memory to and from the host respectively.
> >>
> >> Benefit:
> >> With this patch-series, in our test-case, executed on a single system and single NUMA node with 15GB memory, we were able to successfully launch 5 guests(each with 5 GB memory) when page hinting was enabled and 3 without it. (Detailed explanation of the test procedure is provided at the bottom under Test - 1).
> >>
> >> Changelog in v9:
> >> 	* Guest free page hinting hook is now invoked after a page has been merged in the buddy.
> >>         * Free pages only with order FREE_PAGE_HINTING_MIN_ORDER(currently defined as MAX_ORDER - 1) are captured.
> >> 	* Removed kthread which was earlier used to perform the scanning, isolation & reporting of free pages.
> >> 	* Pages, captured in the per cpu array are sorted based on the zone numbers. This is to avoid redundancy of acquiring zone locks.
> >>         * Dynamically allocated space is used to hold the isolated guest free pages.
> >>         * All the pages are reported asynchronously to the host via virtio driver.
> >>         * Pages are returned back to the guest buddy free list only when the host response is received.
> >>
> >> Pending items:
> >>         * Make sure that the guest free page hinting's current implementation doesn't break hugepages or device assigned guests.
> >> 	* Follow up on VIRTIO_BALLOON_F_PAGE_POISON's device side support. (It is currently missing)
> >>         * Compare reporting free pages via vring with vhost.
> >>         * Decide between MADV_DONTNEED and MADV_FREE.
> >> 	* Analyze overall performance impact due to guest free page hinting.
> >> 	* Come up with proper/traceable error-message/logs.
> >>
> >> Tests:
> >> 1. Use-case - Number of guests we can launch
> >>
> >> 	NUMA Nodes = 1 with 15 GB memory
> >> 	Guest Memory = 5 GB
> >> 	Number of cores in guest = 1
> >> 	Workload = test allocation program allocates 4GB memory, touches it via memset and exits.
> >> 	Procedure =
> >> 	The first guest is launched and once its console is up, the test allocation program is executed with 4 GB memory request (Due to this the guest occupies almost 4-5 GB of memory in the host in a system without page hinting). Once this program exits at that time another guest is launched in the host and the same process is followed. We continue launching the guests until a guest gets killed due to low memory condition in the host.
> >>
> >> 	Results:
> >> 	Without hinting = 3
> >> 	With hinting = 5
> >>
> >> 2. Hackbench
> >> 	Guest Memory = 5 GB 
> >> 	Number of cores = 4
> >> 	Number of tasks		Time with Hinting	Time without Hinting
> >> 	4000			19.540			17.818
> >>
> > How about memhog btw?
> > Alex reported:
> >
> > 	My testing up till now has consisted of setting up 4 8GB VMs on a system
> > 	with 32GB of memory and 4GB of swap. To stress the memory on the system I
> > 	would run "memhog 8G" sequentially on each of the guests and observe how
> > 	long it took to complete the run. The observed behavior is that on the
> > 	systems with these patches applied in both the guest and on the host I was
> > 	able to complete the test with a time of 5 to 7 seconds per guest. On a
> > 	system without these patches the time ranged from 7 to 49 seconds per
> > 	guest. I am assuming the variability is due to time being spent writing
> > 	pages out to disk in order to free up space for the guest.
> >
> Here are the results:
> 
> Procedure: 3 Guests of size 5GB is launched on a single NUMA node with
> total memory of 15GB and no swap. In each of the guest, memhog is run
> with 5GB. Post-execution of memhog, Host memory usage is monitored by
> using Free command.
> 
> Without Hinting:
>                  Time of execution    Host used memory
> Guest 1:        45 seconds            5.4 GB
> Guest 2:        45 seconds            10 GB
> Guest 3:        1  minute               15 GB
> 
> With Hinting:
>                 Time of execution     Host used memory
> Guest 1:        49 seconds            2.4 GB
> Guest 2:        40 seconds            4.3 GB
> Guest 3:        50 seconds            6.3 GB

OK so no improvement. OTOH Alex's patches cut time down to 5-7 seconds
which seems better. Want to try testing Alex's patches for comparison?

-- 
MST

Re: [RFC][Patch v9 0/6] KVM: Guest Free Page Hinting

[Nitesh Narayan Lal]

[-- Attachment #1.1: Type: text/plain, Size: 5469 bytes --]

On 3/6/19 1:12 PM, Michael S. Tsirkin wrote:
> On Wed, Mar 06, 2019 at 01:07:50PM -0500, Nitesh Narayan Lal wrote:
>> On 3/6/19 11:09 AM, Michael S. Tsirkin wrote:
>>> On Wed, Mar 06, 2019 at 10:50:42AM -0500, Nitesh Narayan Lal wrote:
>>>> The following patch-set proposes an efficient mechanism for handing freed memory between the guest and the host. It enables the guests with no page cache to rapidly free and reclaims memory to and from the host respectively.
>>>>
>>>> Benefit:
>>>> With this patch-series, in our test-case, executed on a single system and single NUMA node with 15GB memory, we were able to successfully launch 5 guests(each with 5 GB memory) when page hinting was enabled and 3 without it. (Detailed explanation of the test procedure is provided at the bottom under Test - 1).
>>>>
>>>> Changelog in v9:
>>>> 	* Guest free page hinting hook is now invoked after a page has been merged in the buddy.
>>>>         * Free pages only with order FREE_PAGE_HINTING_MIN_ORDER(currently defined as MAX_ORDER - 1) are captured.
>>>> 	* Removed kthread which was earlier used to perform the scanning, isolation & reporting of free pages.
>>>> 	* Pages, captured in the per cpu array are sorted based on the zone numbers. This is to avoid redundancy of acquiring zone locks.
>>>>         * Dynamically allocated space is used to hold the isolated guest free pages.
>>>>         * All the pages are reported asynchronously to the host via virtio driver.
>>>>         * Pages are returned back to the guest buddy free list only when the host response is received.
>>>>
>>>> Pending items:
>>>>         * Make sure that the guest free page hinting's current implementation doesn't break hugepages or device assigned guests.
>>>> 	* Follow up on VIRTIO_BALLOON_F_PAGE_POISON's device side support. (It is currently missing)
>>>>         * Compare reporting free pages via vring with vhost.
>>>>         * Decide between MADV_DONTNEED and MADV_FREE.
>>>> 	* Analyze overall performance impact due to guest free page hinting.
>>>> 	* Come up with proper/traceable error-message/logs.
>>>>
>>>> Tests:
>>>> 1. Use-case - Number of guests we can launch
>>>>
>>>> 	NUMA Nodes = 1 with 15 GB memory
>>>> 	Guest Memory = 5 GB
>>>> 	Number of cores in guest = 1
>>>> 	Workload = test allocation program allocates 4GB memory, touches it via memset and exits.
>>>> 	Procedure =
>>>> 	The first guest is launched and once its console is up, the test allocation program is executed with 4 GB memory request (Due to this the guest occupies almost 4-5 GB of memory in the host in a system without page hinting). Once this program exits at that time another guest is launched in the host and the same process is followed. We continue launching the guests until a guest gets killed due to low memory condition in the host.
>>>>
>>>> 	Results:
>>>> 	Without hinting = 3
>>>> 	With hinting = 5
>>>>
>>>> 2. Hackbench
>>>> 	Guest Memory = 5 GB 
>>>> 	Number of cores = 4
>>>> 	Number of tasks		Time with Hinting	Time without Hinting
>>>> 	4000			19.540			17.818
>>>>
>>> How about memhog btw?
>>> Alex reported:
>>>
>>> 	My testing up till now has consisted of setting up 4 8GB VMs on a system
>>> 	with 32GB of memory and 4GB of swap. To stress the memory on the system I
>>> 	would run "memhog 8G" sequentially on each of the guests and observe how
>>> 	long it took to complete the run. The observed behavior is that on the
>>> 	systems with these patches applied in both the guest and on the host I was
>>> 	able to complete the test with a time of 5 to 7 seconds per guest. On a
>>> 	system without these patches the time ranged from 7 to 49 seconds per
>>> 	guest. I am assuming the variability is due to time being spent writing
>>> 	pages out to disk in order to free up space for the guest.
>>>
>> Here are the results:
>>
>> Procedure: 3 Guests of size 5GB is launched on a single NUMA node with
>> total memory of 15GB and no swap. In each of the guest, memhog is run
>> with 5GB. Post-execution of memhog, Host memory usage is monitored by
>> using Free command.
>>
>> Without Hinting:
>>                  Time of execution    Host used memory
>> Guest 1:        45 seconds            5.4 GB
>> Guest 2:        45 seconds            10 GB
>> Guest 3:        1  minute               15 GB
>>
>> With Hinting:
>>                 Time of execution     Host used memory
>> Guest 1:        49 seconds            2.4 GB
>> Guest 2:        40 seconds            4.3 GB
>> Guest 3:        50 seconds            6.3 GB
> OK so no improvement.
If we are looking in terms of memory we are getting back from the guest,
then there is an improvement. However, if we are looking at the
improvement in terms of time of execution of memhog then yes there is none.
>  OTOH Alex's patches cut time down to 5-7 seconds
> which seems better. 
I haven't investigated memhog as such so cannot comment on what exactly
it does and why there was a time difference. I can take a look at it.
> Want to try testing Alex's patches for comparison?
Somehow I am not in a favor of doing a hypercall on every page (with
huge TLB order/MAX_ORDER -1) as I think it will be costly.
I can try using Alex's host side logic instead of virtio.
Let me know what you think?
>
-- 
Regards
Nitesh


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [RFC][Patch v9 0/6] KVM: Guest Free Page Hinting

[Michael S. Tsirkin]

On Wed, Mar 06, 2019 at 01:30:14PM -0500, Nitesh Narayan Lal wrote:
> > Want to try testing Alex's patches for comparison?
> Somehow I am not in a favor of doing a hypercall on every page (with
> huge TLB order/MAX_ORDER -1) as I think it will be costly.
> I can try using Alex's host side logic instead of virtio.
> Let me know what you think?

I am just saying maybe your setup is misconfigured
that's why you see no speedup. If you try Alex's
patches and *don't* see speedup like he does, then
he might be able to help you figure out why.
OTOH if you do then *you* can try figuring out why
don't your patches help.

-- 
MST

Re: [RFC][Patch v9 0/6] KVM: Guest Free Page Hinting

[Nitesh Narayan Lal]

[-- Attachment #1.1: Type: text/plain, Size: 744 bytes --]

On 3/6/19 1:38 PM, Michael S. Tsirkin wrote:
> On Wed, Mar 06, 2019 at 01:30:14PM -0500, Nitesh Narayan Lal wrote:
>>> Want to try testing Alex's patches for comparison?
>> Somehow I am not in a favor of doing a hypercall on every page (with
>> huge TLB order/MAX_ORDER -1) as I think it will be costly.
>> I can try using Alex's host side logic instead of virtio.
>> Let me know what you think?
> I am just saying maybe your setup is misconfigured
> that's why you see no speedup. 
Got it.
> If you try Alex's
> patches and *don't* see speedup like he does, then
> he might be able to help you figure out why.
> OTOH if you do then *you* can try figuring out why
> don't your patches help.
Yeap, I can do that.
Thanks.
>



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [RFC][Patch v9 0/6] KVM: Guest Free Page Hinting

[Alexander Duyck]

On Wed, Mar 6, 2019 at 10:41 AM Nitesh Narayan Lal <nitesh@redhat.com> wrote:
>
> On 3/6/19 1:38 PM, Michael S. Tsirkin wrote:
> > On Wed, Mar 06, 2019 at 01:30:14PM -0500, Nitesh Narayan Lal wrote:
> >>> Want to try testing Alex's patches for comparison?
> >> Somehow I am not in a favor of doing a hypercall on every page (with
> >> huge TLB order/MAX_ORDER -1) as I think it will be costly.
> >> I can try using Alex's host side logic instead of virtio.
> >> Let me know what you think?
> > I am just saying maybe your setup is misconfigured
> > that's why you see no speedup.
> Got it.
> > If you try Alex's
> > patches and *don't* see speedup like he does, then
> > he might be able to help you figure out why.
> > OTOH if you do then *you* can try figuring out why
> > don't your patches help.
> Yeap, I can do that.
> Thanks.

If I can get your patches up and running I can probably try the same
test I did to see if I am able to reproduce the behavior. It may take
a bit though as I am running into several merge conflicts that I am
having to sort out.

Thanks.

- Alex

Re: [RFC][Patch v9 0/6] KVM: Guest Free Page Hinting

[Michael S. Tsirkin]

On Wed, Mar 06, 2019 at 01:30:14PM -0500, Nitesh Narayan Lal wrote:
> >> Here are the results:
> >>
> >> Procedure: 3 Guests of size 5GB is launched on a single NUMA node with
> >> total memory of 15GB and no swap. In each of the guest, memhog is run
> >> with 5GB. Post-execution of memhog, Host memory usage is monitored by
> >> using Free command.
> >>
> >> Without Hinting:
> >>                  Time of execution    Host used memory
> >> Guest 1:        45 seconds            5.4 GB
> >> Guest 2:        45 seconds            10 GB
> >> Guest 3:        1  minute               15 GB
> >>
> >> With Hinting:
> >>                 Time of execution     Host used memory
> >> Guest 1:        49 seconds            2.4 GB
> >> Guest 2:        40 seconds            4.3 GB
> >> Guest 3:        50 seconds            6.3 GB
> > OK so no improvement.
> If we are looking in terms of memory we are getting back from the guest,
> then there is an improvement. However, if we are looking at the
> improvement in terms of time of execution of memhog then yes there is none.

Yes but the way I see it you can't overcommit this unused memory
since guests can start using it at any time.  You timed it carefully
such that this does not happen, but what will cause this timing on real
guests?

So the real reason to want this is to avoid need for writeback on free
pages.

Right?


> >  OTOH Alex's patches cut time down to 5-7 seconds
> > which seems better. 
> I haven't investigated memhog as such so cannot comment on what exactly
> it does and why there was a time difference. I can take a look at it.
> > Want to try testing Alex's patches for comparison?
> Somehow I am not in a favor of doing a hypercall on every page (with
> huge TLB order/MAX_ORDER -1) as I think it will be costly.
> I can try using Alex's host side logic instead of virtio.
> Let me know what you think?
> >
> -- 
> Regards
> Nitesh
> 

Re: [RFC][Patch v9 0/6] KVM: Guest Free Page Hinting

[David Hildenbrand]

On 06.03.19 19:43, Michael S. Tsirkin wrote:
> On Wed, Mar 06, 2019 at 01:30:14PM -0500, Nitesh Narayan Lal wrote:
>>>> Here are the results:
>>>>
>>>> Procedure: 3 Guests of size 5GB is launched on a single NUMA node with
>>>> total memory of 15GB and no swap. In each of the guest, memhog is run
>>>> with 5GB. Post-execution of memhog, Host memory usage is monitored by
>>>> using Free command.
>>>>
>>>> Without Hinting:
>>>>                  Time of execution    Host used memory
>>>> Guest 1:        45 seconds            5.4 GB
>>>> Guest 2:        45 seconds            10 GB
>>>> Guest 3:        1  minute               15 GB
>>>>
>>>> With Hinting:
>>>>                 Time of execution     Host used memory
>>>> Guest 1:        49 seconds            2.4 GB
>>>> Guest 2:        40 seconds            4.3 GB
>>>> Guest 3:        50 seconds            6.3 GB
>>> OK so no improvement.
>> If we are looking in terms of memory we are getting back from the guest,
>> then there is an improvement. However, if we are looking at the
>> improvement in terms of time of execution of memhog then yes there is none.
> 
> Yes but the way I see it you can't overcommit this unused memory
> since guests can start using it at any time.  You timed it carefully
> such that this does not happen, but what will cause this timing on real
> guests?

Whenever you overcommit you will need backup swap. There is no way
around it. It just makes the probability of you having to go to disk
less likely.

If you assume that all of your guests will be using all of their memory
all the time, you don't have to think about overcommiting memory in the
first place. But this is not what we usually have.

> 
> So the real reason to want this is to avoid need for writeback on free
> pages.
> 
> Right?

-- 

Thanks,

David / dhildenb

Re: [RFC][Patch v9 0/6] KVM: Guest Free Page Hinting

[Nitesh Narayan Lal]

[-- Attachment #1.1: Type: text/plain, Size: 6011 bytes --]


On 3/6/19 1:00 PM, Alexander Duyck wrote:
> On Wed, Mar 6, 2019 at 7:51 AM Nitesh Narayan Lal <nitesh@redhat.com> wrote:
>> The following patch-set proposes an efficient mechanism for handing freed memory between the guest and the host. It enables the guests with no page cache to rapidly free and reclaims memory to and from the host respectively.
>>
>> Benefit:
>> With this patch-series, in our test-case, executed on a single system and single NUMA node with 15GB memory, we were able to successfully launch 5 guests(each with 5 GB memory) when page hinting was enabled and 3 without it. (Detailed explanation of the test procedure is provided at the bottom under Test - 1).
>>
>> Changelog in v9:
>>         * Guest free page hinting hook is now invoked after a page has been merged in the buddy.
>>         * Free pages only with order FREE_PAGE_HINTING_MIN_ORDER(currently defined as MAX_ORDER - 1) are captured.
>>         * Removed kthread which was earlier used to perform the scanning, isolation & reporting of free pages.
> Without a kthread this has the potential to get really ugly really
> fast. If we are going to run asynchronously we should probably be
> truly asynchonous and just place a few pieces of data in the page that
> a worker thread can use to identify which pages have been hinted and
> which pages have not. 

Can you please explain what do you mean by truly asynchronous?

With this implementation also I am not reporting the pages synchronously.

> Then we can have that one thread just walking
> through the zone memory pulling out fixed size pieces at a time and
> providing hints on that. By doing that we avoid the potential of
> creating a batch of pages that eat up most of the system memory.
>
>>         * Pages, captured in the per cpu array are sorted based on the zone numbers. This is to avoid redundancy of acquiring zone locks.
>>         * Dynamically allocated space is used to hold the isolated guest free pages.
> I have concerns that doing this per CPU and allocating memory
> dynamically can result in you losing a significant amount of memory as
> it sits waiting to be hinted.
It should not as the buddy will keep merging the pages and we are only
capturing MAX_ORDER - 1.
This was the issue with the last patch-series when I was capturing all
order pages resulting in the per-cpu array to be filled with lower order
pages.
>
>>         * All the pages are reported asynchronously to the host via virtio driver.
>>         * Pages are returned back to the guest buddy free list only when the host response is received.
> I have been thinking about this. Instead of stealing the page couldn't
> you simply flag it that there is a hint in progress and simply wait in
> arch_alloc_page until the hint has been processed? 
With the flag, I am assuming you mean to block the allocation until
hinting is going on, which is an issue. That was one of the issues
discussed earlier which I wanted to solve with this implementation.
> The problem is in
> stealing pages you are going to introduce false OOM issues when the
> memory isn't available because it is being hinted on.
I think this situation will arise when the guest is under memory
pressure. In such situations any attempt to perform isolation will
anyways fail and we may not be reporting anything at that time.
>
>> Pending items:
>>         * Make sure that the guest free page hinting's current implementation doesn't break hugepages or device assigned guests.
>>         * Follow up on VIRTIO_BALLOON_F_PAGE_POISON's device side support. (It is currently missing)
>>         * Compare reporting free pages via vring with vhost.
>>         * Decide between MADV_DONTNEED and MADV_FREE.
>>         * Analyze overall performance impact due to guest free page hinting.
>>         * Come up with proper/traceable error-message/logs.
> I'll try applying these patches and see if I can reproduce the results
> you reported. 
Thanks. Let me know if you run into any issues.
> With the last patch set I couldn't reproduce the results
> as you reported them. 
If I remember correctly then the last time you only tried with multiple
vcpus and not with 1 vcpu.
> It has me wondering if you were somehow seeing
> the effects of a balloon instead of the actual memory hints as I
> couldn't find any evidence of the memory ever actually being freed
> back by the hints functionality.

Can you please elaborate what kind of evidence you are looking for?

I did trace the hints on the QEMU/host side.

>
> Also do you have any idea if this patch set will work with an SMP
> setup or is it still racy? I might try enabling SMP in my environment
> to see if I can test the scalability of the VM with something like a
> will-it-scale test.
I did try running page_fault1_threads in will-it-scale with 4 vcpus.
It didn't give me any issue.
>
>> Tests:
>> 1. Use-case - Number of guests we can launch
>>
>>         NUMA Nodes = 1 with 15 GB memory
>>         Guest Memory = 5 GB
>>         Number of cores in guest = 1
>>         Workload = test allocation program allocates 4GB memory, touches it via memset and exits.
>>         Procedure =
>>         The first guest is launched and once its console is up, the test allocation program is executed with 4 GB memory request (Due to this the guest occupies almost 4-5 GB of memory in the host in a system without page hinting). Once this program exits at that time another guest is launched in the host and the same process is followed. We continue launching the guests until a guest gets killed due to low memory condition in the host.
>>
>>         Results:
>>         Without hinting = 3
>>         With hinting = 5
>>
>> 2. Hackbench
>>         Guest Memory = 5 GB
>>         Number of cores = 4
>>         Number of tasks         Time with Hinting       Time without Hinting
>>         4000                    19.540                  17.818
>>
>>
-- 
Nitesh


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [RFC][Patch v9 0/6] KVM: Guest Free Page Hinting

[Alexander Duyck]

On Wed, Mar 6, 2019 at 11:00 AM David Hildenbrand <david@redhat.com> wrote:
>
> On 06.03.19 19:43, Michael S. Tsirkin wrote:
> > On Wed, Mar 06, 2019 at 01:30:14PM -0500, Nitesh Narayan Lal wrote:
> >>>> Here are the results:
> >>>>
> >>>> Procedure: 3 Guests of size 5GB is launched on a single NUMA node with
> >>>> total memory of 15GB and no swap. In each of the guest, memhog is run
> >>>> with 5GB. Post-execution of memhog, Host memory usage is monitored by
> >>>> using Free command.
> >>>>
> >>>> Without Hinting:
> >>>>                  Time of execution    Host used memory
> >>>> Guest 1:        45 seconds            5.4 GB
> >>>> Guest 2:        45 seconds            10 GB
> >>>> Guest 3:        1  minute               15 GB
> >>>>
> >>>> With Hinting:
> >>>>                 Time of execution     Host used memory
> >>>> Guest 1:        49 seconds            2.4 GB
> >>>> Guest 2:        40 seconds            4.3 GB
> >>>> Guest 3:        50 seconds            6.3 GB
> >>> OK so no improvement.
> >> If we are looking in terms of memory we are getting back from the guest,
> >> then there is an improvement. However, if we are looking at the
> >> improvement in terms of time of execution of memhog then yes there is none.
> >
> > Yes but the way I see it you can't overcommit this unused memory
> > since guests can start using it at any time.  You timed it carefully
> > such that this does not happen, but what will cause this timing on real
> > guests?
>
> Whenever you overcommit you will need backup swap. There is no way
> around it. It just makes the probability of you having to go to disk
> less likely.
>
> If you assume that all of your guests will be using all of their memory
> all the time, you don't have to think about overcommiting memory in the
> first place. But this is not what we usually have.

Right, but the general idea is that free page hinting allows us to
avoid having to use the swap if we are hinting the pages as unused.
The general assumption we are working with is that some percentage of
the VMs are unused most of the time so you can share those resources
between multiple VMs and have them free those up normally.

If we can reduce swap usage we can improve overall performance and
that was what I was pointing out with my test. I had also done
something similar to what Nitesh was doing with his original test
where I had launched 8 VMs with 8GB of memory per VM on a system with
32G of RAM and only 4G of swap. In that setup I could keep a couple
VMs busy at a time without issues, and obviously without the patch I
just started to OOM qemu instances and  could only have 4 VMs at a
time running at maximum.

Re: [RFC][Patch v9 0/6] KVM: Guest Free Page Hinting

[David Hildenbrand]

On 06.03.19 20:08, Alexander Duyck wrote:
> On Wed, Mar 6, 2019 at 11:00 AM David Hildenbrand <david@redhat.com> wrote:
>>
>> On 06.03.19 19:43, Michael S. Tsirkin wrote:
>>> On Wed, Mar 06, 2019 at 01:30:14PM -0500, Nitesh Narayan Lal wrote:
>>>>>> Here are the results:
>>>>>>
>>>>>> Procedure: 3 Guests of size 5GB is launched on a single NUMA node with
>>>>>> total memory of 15GB and no swap. In each of the guest, memhog is run
>>>>>> with 5GB. Post-execution of memhog, Host memory usage is monitored by
>>>>>> using Free command.
>>>>>>
>>>>>> Without Hinting:
>>>>>>                  Time of execution    Host used memory
>>>>>> Guest 1:        45 seconds            5.4 GB
>>>>>> Guest 2:        45 seconds            10 GB
>>>>>> Guest 3:        1  minute               15 GB
>>>>>>
>>>>>> With Hinting:
>>>>>>                 Time of execution     Host used memory
>>>>>> Guest 1:        49 seconds            2.4 GB
>>>>>> Guest 2:        40 seconds            4.3 GB
>>>>>> Guest 3:        50 seconds            6.3 GB
>>>>> OK so no improvement.
>>>> If we are looking in terms of memory we are getting back from the guest,
>>>> then there is an improvement. However, if we are looking at the
>>>> improvement in terms of time of execution of memhog then yes there is none.
>>>
>>> Yes but the way I see it you can't overcommit this unused memory
>>> since guests can start using it at any time.  You timed it carefully
>>> such that this does not happen, but what will cause this timing on real
>>> guests?
>>
>> Whenever you overcommit you will need backup swap. There is no way
>> around it. It just makes the probability of you having to go to disk
>> less likely.
>>
>> If you assume that all of your guests will be using all of their memory
>> all the time, you don't have to think about overcommiting memory in the
>> first place. But this is not what we usually have.
> 
> Right, but the general idea is that free page hinting allows us to
> avoid having to use the swap if we are hinting the pages as unused.
> The general assumption we are working with is that some percentage of
> the VMs are unused most of the time so you can share those resources
> between multiple VMs and have them free those up normally.

Yes, similar to VCPU yielding or playin scheduling when the VCPU is
spleeping. Instead of busy looping, hand over the resource to somebody
who can actually make use of it.

> 
> If we can reduce swap usage we can improve overall performance and
> that was what I was pointing out with my test. I had also done
> something similar to what Nitesh was doing with his original test
> where I had launched 8 VMs with 8GB of memory per VM on a system with
> 32G of RAM and only 4G of swap. In that setup I could keep a couple
> VMs busy at a time without issues, and obviously without the patch I
> just started to OOM qemu instances and  could only have 4 VMs at a
> time running at maximum.

While these are nice experiments (especially to showcase reduced swap
usage!), I would not suggest to use 4GB of swap on a x2 overcomited
system (32GB overcommited). Disks are so cheap nowadays that one does
not have to play with fire.

But yes, reducing swap usage implies overall system performance (unless
the hinting is terribly slow :) ). Reducing swap usage, not swap space :)

-- 

Thanks,

David / dhildenb

Re: [RFC][Patch v9 0/6] KVM: Guest Free Page Hinting

[Alexander Duyck]

On Wed, Mar 6, 2019 at 11:18 AM David Hildenbrand <david@redhat.com> wrote:
>
> On 06.03.19 20:08, Alexander Duyck wrote:
> > On Wed, Mar 6, 2019 at 11:00 AM David Hildenbrand <david@redhat.com> wrote:
> >>
> >> On 06.03.19 19:43, Michael S. Tsirkin wrote:
> >>> On Wed, Mar 06, 2019 at 01:30:14PM -0500, Nitesh Narayan Lal wrote:
> >>>>>> Here are the results:
> >>>>>>
> >>>>>> Procedure: 3 Guests of size 5GB is launched on a single NUMA node with
> >>>>>> total memory of 15GB and no swap. In each of the guest, memhog is run
> >>>>>> with 5GB. Post-execution of memhog, Host memory usage is monitored by
> >>>>>> using Free command.
> >>>>>>
> >>>>>> Without Hinting:
> >>>>>>                  Time of execution    Host used memory
> >>>>>> Guest 1:        45 seconds            5.4 GB
> >>>>>> Guest 2:        45 seconds            10 GB
> >>>>>> Guest 3:        1  minute               15 GB
> >>>>>>
> >>>>>> With Hinting:
> >>>>>>                 Time of execution     Host used memory
> >>>>>> Guest 1:        49 seconds            2.4 GB
> >>>>>> Guest 2:        40 seconds            4.3 GB
> >>>>>> Guest 3:        50 seconds            6.3 GB
> >>>>> OK so no improvement.
> >>>> If we are looking in terms of memory we are getting back from the guest,
> >>>> then there is an improvement. However, if we are looking at the
> >>>> improvement in terms of time of execution of memhog then yes there is none.
> >>>
> >>> Yes but the way I see it you can't overcommit this unused memory
> >>> since guests can start using it at any time.  You timed it carefully
> >>> such that this does not happen, but what will cause this timing on real
> >>> guests?
> >>
> >> Whenever you overcommit you will need backup swap. There is no way
> >> around it. It just makes the probability of you having to go to disk
> >> less likely.
> >>
> >> If you assume that all of your guests will be using all of their memory
> >> all the time, you don't have to think about overcommiting memory in the
> >> first place. But this is not what we usually have.
> >
> > Right, but the general idea is that free page hinting allows us to
> > avoid having to use the swap if we are hinting the pages as unused.
> > The general assumption we are working with is that some percentage of
> > the VMs are unused most of the time so you can share those resources
> > between multiple VMs and have them free those up normally.
>
> Yes, similar to VCPU yielding or playin scheduling when the VCPU is
> spleeping. Instead of busy looping, hand over the resource to somebody
> who can actually make use of it.
>
> >
> > If we can reduce swap usage we can improve overall performance and
> > that was what I was pointing out with my test. I had also done
> > something similar to what Nitesh was doing with his original test
> > where I had launched 8 VMs with 8GB of memory per VM on a system with
> > 32G of RAM and only 4G of swap. In that setup I could keep a couple
> > VMs busy at a time without issues, and obviously without the patch I
> > just started to OOM qemu instances and  could only have 4 VMs at a
> > time running at maximum.
>
> While these are nice experiments (especially to showcase reduced swap
> usage!), I would not suggest to use 4GB of swap on a x2 overcomited
> system (32GB overcommited). Disks are so cheap nowadays that one does
> not have to play with fire.

Right. The only reason for using 4G is because the system normally has
128G of RAM available and I didn't really think I would need swap for
the system when I originally configured it.

> But yes, reducing swap usage implies overall system performance (unless
> the hinting is terribly slow :) ). Reducing swap usage, not swap space :)

Right. Also the swap is really a necessity if we are going to look at
things like MADV_FREE as I have not seen us really start to free up
resources until we are starting to put some pressure on swap.

Re: [RFC][Patch v9 0/6] KVM: Guest Free Page Hinting

[Nitesh Narayan Lal]

[-- Attachment #1.1: Type: text/plain, Size: 4288 bytes --]

On 3/6/19 2:24 PM, Alexander Duyck wrote:
> On Wed, Mar 6, 2019 at 11:18 AM David Hildenbrand <david@redhat.com> wrote:
>> On 06.03.19 20:08, Alexander Duyck wrote:
>>> On Wed, Mar 6, 2019 at 11:00 AM David Hildenbrand <david@redhat.com> wrote:
>>>> On 06.03.19 19:43, Michael S. Tsirkin wrote:
>>>>> On Wed, Mar 06, 2019 at 01:30:14PM -0500, Nitesh Narayan Lal wrote:
>>>>>>>> Here are the results:
>>>>>>>>
>>>>>>>> Procedure: 3 Guests of size 5GB is launched on a single NUMA node with
>>>>>>>> total memory of 15GB and no swap. In each of the guest, memhog is run
>>>>>>>> with 5GB. Post-execution of memhog, Host memory usage is monitored by
>>>>>>>> using Free command.
>>>>>>>>
>>>>>>>> Without Hinting:
>>>>>>>>                  Time of execution    Host used memory
>>>>>>>> Guest 1:        45 seconds            5.4 GB
>>>>>>>> Guest 2:        45 seconds            10 GB
>>>>>>>> Guest 3:        1  minute               15 GB
>>>>>>>>
>>>>>>>> With Hinting:
>>>>>>>>                 Time of execution     Host used memory
>>>>>>>> Guest 1:        49 seconds            2.4 GB
>>>>>>>> Guest 2:        40 seconds            4.3 GB
>>>>>>>> Guest 3:        50 seconds            6.3 GB
>>>>>>> OK so no improvement.
>>>>>> If we are looking in terms of memory we are getting back from the guest,
>>>>>> then there is an improvement. However, if we are looking at the
>>>>>> improvement in terms of time of execution of memhog then yes there is none.
>>>>> Yes but the way I see it you can't overcommit this unused memory
>>>>> since guests can start using it at any time.  You timed it carefully
>>>>> such that this does not happen, but what will cause this timing on real
>>>>> guests?
>>>> Whenever you overcommit you will need backup swap. There is no way
>>>> around it. It just makes the probability of you having to go to disk
>>>> less likely.
>>>>
>>>> If you assume that all of your guests will be using all of their memory
>>>> all the time, you don't have to think about overcommiting memory in the
>>>> first place. But this is not what we usually have.
>>> Right, but the general idea is that free page hinting allows us to
>>> avoid having to use the swap if we are hinting the pages as unused.
>>> The general assumption we are working with is that some percentage of
>>> the VMs are unused most of the time so you can share those resources
>>> between multiple VMs and have them free those up normally.
>> Yes, similar to VCPU yielding or playin scheduling when the VCPU is
>> spleeping. Instead of busy looping, hand over the resource to somebody
>> who can actually make use of it.
>>
>>> If we can reduce swap usage we can improve overall performance and
>>> that was what I was pointing out with my test. I had also done
>>> something similar to what Nitesh was doing with his original test
>>> where I had launched 8 VMs with 8GB of memory per VM on a system with
>>> 32G of RAM and only 4G of swap. In that setup I could keep a couple
>>> VMs busy at a time without issues, and obviously without the patch I
>>> just started to OOM qemu instances and  could only have 4 VMs at a
>>> time running at maximum.
>> While these are nice experiments (especially to showcase reduced swap
>> usage!), I would not suggest to use 4GB of swap on a x2 overcomited
>> system (32GB overcommited). Disks are so cheap nowadays that one does
>> not have to play with fire.
> Right. The only reason for using 4G is because the system normally has
> 128G of RAM available and I didn't really think I would need swap for
> the system when I originally configured it.
>
>> But yes, reducing swap usage implies overall system performance (unless
>> the hinting is terribly slow :) ). Reducing swap usage, not swap space :)
> Right. Also the swap is really a necessity if we are going to look at
> things like MADV_FREE as I have not seen us really start to free up
> resources until we are starting to put some pressure on swap.
I agree in order to see the effect of MADV_FREE we may have to use
swap(it doesn't have to be huge).
About Michael's comment, if the guest is consistently under memory
pressure then we may not get anything back in the host at all during
this time.


-- 
Thanks
Nitesh


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [RFC][Patch v9 0/6] KVM: Guest Free Page Hinting

[Michael S. Tsirkin]

On Wed, Mar 06, 2019 at 07:59:57PM +0100, David Hildenbrand wrote:
> On 06.03.19 19:43, Michael S. Tsirkin wrote:
> > On Wed, Mar 06, 2019 at 01:30:14PM -0500, Nitesh Narayan Lal wrote:
> >>>> Here are the results:
> >>>>
> >>>> Procedure: 3 Guests of size 5GB is launched on a single NUMA node with
> >>>> total memory of 15GB and no swap. In each of the guest, memhog is run
> >>>> with 5GB. Post-execution of memhog, Host memory usage is monitored by
> >>>> using Free command.
> >>>>
> >>>> Without Hinting:
> >>>>                  Time of execution    Host used memory
> >>>> Guest 1:        45 seconds            5.4 GB
> >>>> Guest 2:        45 seconds            10 GB
> >>>> Guest 3:        1  minute               15 GB
> >>>>
> >>>> With Hinting:
> >>>>                 Time of execution     Host used memory
> >>>> Guest 1:        49 seconds            2.4 GB
> >>>> Guest 2:        40 seconds            4.3 GB
> >>>> Guest 3:        50 seconds            6.3 GB
> >>> OK so no improvement.
> >> If we are looking in terms of memory we are getting back from the guest,
> >> then there is an improvement. However, if we are looking at the
> >> improvement in terms of time of execution of memhog then yes there is none.
> > 
> > Yes but the way I see it you can't overcommit this unused memory
> > since guests can start using it at any time.  You timed it carefully
> > such that this does not happen, but what will cause this timing on real
> > guests?
> 
> Whenever you overcommit you will need backup swap.

Right and the point of hinting is that pages can just be
discarded and not end up in swap.


Point is you should be able to see the gain.

Hinting patches cost some CPU so we need to know whether
they cost too much. How much is too much? When the cost
is bigger than benefit. But we can't compare CPU cycles
to bytes. So we need to benchmark everything in terms of
cycles.

> There is no way
> around it. It just makes the probability of you having to go to disk
> less likely.


Right and let's quantify this. Does this result in net gain or loss?


> If you assume that all of your guests will be using all of their memory
> all the time, you don't have to think about overcommiting memory in the
> first place. But this is not what we usually have.

Right and swap is there to support overcommit. However it
was felt that hinting can be faster since it avoids IO
involved in swap.

> > 
> > So the real reason to want this is to avoid need for writeback on free
> > pages.
> > 
> > Right?
> 
> -- 
> 
> Thanks,
> 
> David / dhildenb

Re: [RFC][Patch v9 3/6] KVM: Enables the kernel to report isolated pages

[Alexander Duyck]

On Wed, Mar 6, 2019 at 7:51 AM Nitesh Narayan Lal <nitesh@redhat.com> wrote:
>
> This patch enables the kernel to report the isolated pages
> to the host via virtio balloon driver.
> In order to do so a new virtuqeue (hinting_vq) is added to the
> virtio balloon driver. As the host responds back after freeing
> the pages, all the isolated pages are returned back to the buddy
> via __free_one_page().
>
> Signed-off-by: Nitesh Narayan Lal <nitesh@redhat.com>

I ran into a few build issues due to this patch. Comments below.

> ---
>  drivers/virtio/virtio_balloon.c     | 72 ++++++++++++++++++++++++++++-
>  include/linux/page_hinting.h        |  4 ++
>  include/uapi/linux/virtio_balloon.h |  8 ++++
>  virt/kvm/page_hinting.c             | 18 ++++++--
>  4 files changed, 98 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
> index 728ecd1eea30..cfe7574b5204 100644
> --- a/drivers/virtio/virtio_balloon.c
> +++ b/drivers/virtio/virtio_balloon.c
> @@ -57,13 +57,15 @@ enum virtio_balloon_vq {
>         VIRTIO_BALLOON_VQ_INFLATE,
>         VIRTIO_BALLOON_VQ_DEFLATE,
>         VIRTIO_BALLOON_VQ_STATS,
> +       VIRTIO_BALLOON_VQ_HINTING,
>         VIRTIO_BALLOON_VQ_FREE_PAGE,
>         VIRTIO_BALLOON_VQ_MAX
>  };
>
>  struct virtio_balloon {
>         struct virtio_device *vdev;
> -       struct virtqueue *inflate_vq, *deflate_vq, *stats_vq, *free_page_vq;
> +       struct virtqueue *inflate_vq, *deflate_vq, *stats_vq, *free_page_vq,
> +                                                               *hinting_vq;
>
>         /* Balloon's own wq for cpu-intensive work items */
>         struct workqueue_struct *balloon_wq;
> @@ -122,6 +124,56 @@ static struct virtio_device_id id_table[] = {
>         { 0 },
>  };
>
> +#ifdef CONFIG_KVM_FREE_PAGE_HINTING
> +int virtballoon_page_hinting(struct virtio_balloon *vb,
> +                            void *hinting_req,
> +                            int entries)
> +{
> +       struct scatterlist sg;
> +       struct virtqueue *vq = vb->hinting_vq;
> +       int err;
> +       int unused;
> +       struct virtio_balloon_hint_req *hint_req;
> +       u64 gpaddr;
> +
> +       hint_req = kmalloc(sizeof(struct virtio_balloon_hint_req), GFP_KERNEL);
> +       while (virtqueue_get_buf(vq, &unused))
> +               ;
> +
> +       gpaddr = virt_to_phys(hinting_req);
> +       hint_req->phys_addr = cpu_to_virtio64(vb->vdev, gpaddr);
> +       hint_req->count = cpu_to_virtio32(vb->vdev, entries);
> +       sg_init_one(&sg, hint_req, sizeof(struct virtio_balloon_hint_req));
> +       err = virtqueue_add_outbuf(vq, &sg, 1, hint_req, GFP_KERNEL);
> +       if (!err)
> +               virtqueue_kick(vb->hinting_vq);
> +       else
> +               kfree(hint_req);
> +       return err;
> +}
> +
> +static void hinting_ack(struct virtqueue *vq)
> +{
> +       int len = sizeof(struct virtio_balloon_hint_req);
> +       struct virtio_balloon_hint_req *hint_req = virtqueue_get_buf(vq, &len);
> +       void *v_addr = phys_to_virt(hint_req->phys_addr);
> +
> +       release_buddy_pages(v_addr, hint_req->count);
> +       kfree(hint_req);
> +}
> +

You use release_buddy_pages here, but never exported it in the call
down below. Since this can be built as a module and I believe the page
hinting can be built either into the kernel or as a seperate module
shouldn't you be exporting it?

> +static void enable_hinting(struct virtio_balloon *vb)
> +{
> +       request_hypercall = (void *)&virtballoon_page_hinting;
> +       balloon_ptr = vb;
> +}
> +
> +static void disable_hinting(void)
> +{
> +       balloon_ptr = NULL;
> +}
> +#endif
> +
>  static u32 page_to_balloon_pfn(struct page *page)
>  {
>         unsigned long pfn = page_to_pfn(page);
> @@ -481,6 +533,7 @@ static int init_vqs(struct virtio_balloon *vb)
>         names[VIRTIO_BALLOON_VQ_DEFLATE] = "deflate";
>         names[VIRTIO_BALLOON_VQ_STATS] = NULL;
>         names[VIRTIO_BALLOON_VQ_FREE_PAGE] = NULL;
> +       names[VIRTIO_BALLOON_VQ_HINTING] = NULL;
>
>         if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_STATS_VQ)) {
>                 names[VIRTIO_BALLOON_VQ_STATS] = "stats";
> @@ -492,11 +545,18 @@ static int init_vqs(struct virtio_balloon *vb)
>                 callbacks[VIRTIO_BALLOON_VQ_FREE_PAGE] = NULL;
>         }
>
> +       if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_HINTING)) {
> +               names[VIRTIO_BALLOON_VQ_HINTING] = "hinting_vq";
> +               callbacks[VIRTIO_BALLOON_VQ_HINTING] = hinting_ack;
> +       }
>         err = vb->vdev->config->find_vqs(vb->vdev, VIRTIO_BALLOON_VQ_MAX,
>                                          vqs, callbacks, names, NULL, NULL);
>         if (err)
>                 return err;
>
> +       if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_HINTING))
> +               vb->hinting_vq = vqs[VIRTIO_BALLOON_VQ_HINTING];
> +
>         vb->inflate_vq = vqs[VIRTIO_BALLOON_VQ_INFLATE];
>         vb->deflate_vq = vqs[VIRTIO_BALLOON_VQ_DEFLATE];
>         if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_STATS_VQ)) {
> @@ -908,6 +968,11 @@ static int virtballoon_probe(struct virtio_device *vdev)
>                 if (err)
>                         goto out_del_balloon_wq;
>         }
> +
> +#ifdef CONFIG_KVM_FREE_PAGE_HINTING
> +       if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_HINTING))
> +               enable_hinting(vb);
> +#endif
>         virtio_device_ready(vdev);
>
>         if (towards_target(vb))
> @@ -950,6 +1015,10 @@ static void virtballoon_remove(struct virtio_device *vdev)
>         cancel_work_sync(&vb->update_balloon_size_work);
>         cancel_work_sync(&vb->update_balloon_stats_work);
>
> +#ifdef CONFIG_KVM_FREE_PAGE_HINTING
> +       if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_HINTING))
> +               disable_hinting();
> +#endif
>         if (virtio_has_feature(vdev, VIRTIO_BALLOON_F_FREE_PAGE_HINT)) {
>                 cancel_work_sync(&vb->report_free_page_work);
>                 destroy_workqueue(vb->balloon_wq);
> @@ -1009,6 +1078,7 @@ static unsigned int features[] = {
>         VIRTIO_BALLOON_F_MUST_TELL_HOST,
>         VIRTIO_BALLOON_F_STATS_VQ,
>         VIRTIO_BALLOON_F_DEFLATE_ON_OOM,
> +       VIRTIO_BALLOON_F_HINTING,
>         VIRTIO_BALLOON_F_FREE_PAGE_HINT,
>         VIRTIO_BALLOON_F_PAGE_POISON,
>  };
> diff --git a/include/linux/page_hinting.h b/include/linux/page_hinting.h
> index d554a2581826..a32af8851081 100644
> --- a/include/linux/page_hinting.h
> +++ b/include/linux/page_hinting.h
> @@ -11,6 +11,8 @@
>  #define HINTING_THRESHOLD      128
>  #define FREE_PAGE_HINTING_MIN_ORDER    (MAX_ORDER - 1)
>
> +extern void *balloon_ptr;
> +
>  void guest_free_page_enqueue(struct page *page, int order);
>  void guest_free_page_try_hinting(void);
>  extern int __isolate_free_page(struct page *page, unsigned int order);
> @@ -18,3 +20,5 @@ extern void __free_one_page(struct page *page, unsigned long pfn,
>                             struct zone *zone, unsigned int order,
>                             int migratetype);
>  void release_buddy_pages(void *obj_to_free, int entries);
> +extern int (*request_hypercall)(void *balloon_ptr,
> +                               void *hinting_req, int entries);
> diff --git a/include/uapi/linux/virtio_balloon.h b/include/uapi/linux/virtio_balloon.h
> index a1966cd7b677..a7e909d77447 100644
> --- a/include/uapi/linux/virtio_balloon.h
> +++ b/include/uapi/linux/virtio_balloon.h
> @@ -29,6 +29,7 @@
>  #include <linux/virtio_types.h>
>  #include <linux/virtio_ids.h>
>  #include <linux/virtio_config.h>
> +#include <linux/page_hinting.h>
>
>  /* The feature bitmap for virtio balloon */
>  #define VIRTIO_BALLOON_F_MUST_TELL_HOST        0 /* Tell before reclaiming pages */

So I am pretty sure that this isn't valid. You have a file in
include/uapi/linux referencing one in include/linux. As such when the
userspace headers are built off of this they cannot access the kernel
include file.

> @@ -36,6 +37,7 @@
>  #define VIRTIO_BALLOON_F_DEFLATE_ON_OOM        2 /* Deflate balloon on OOM */
>  #define VIRTIO_BALLOON_F_FREE_PAGE_HINT        3 /* VQ to report free pages */
>  #define VIRTIO_BALLOON_F_PAGE_POISON   4 /* Guest is using page poisoning */
> +#define VIRTIO_BALLOON_F_HINTING       5 /* Page hinting virtqueue */
>
>  /* Size of a PFN in the balloon interface. */
>  #define VIRTIO_BALLOON_PFN_SHIFT 12
> @@ -108,4 +110,10 @@ struct virtio_balloon_stat {
>         __virtio64 val;
>  } __attribute__((packed));
>
> +#ifdef CONFIG_KVM_FREE_PAGE_HINTING
> +struct virtio_balloon_hint_req {
> +       __virtio64 phys_addr;
> +       __virtio64 count;
> +};
> +#endif
>  #endif /* _LINUX_VIRTIO_BALLOON_H */
> diff --git a/virt/kvm/page_hinting.c b/virt/kvm/page_hinting.c
> index 9885b372b5a9..eb0c0ddfe990 100644
> --- a/virt/kvm/page_hinting.c
> +++ b/virt/kvm/page_hinting.c
> @@ -31,11 +31,16 @@ struct guest_isolated_pages {
>         unsigned int order;
>  };
>
> -void release_buddy_pages(void *obj_to_free, int entries)
> +int (*request_hypercall)(void *balloon_ptr, void *hinting_req, int entries);
> +EXPORT_SYMBOL(request_hypercall);
> +void *balloon_ptr;
> +EXPORT_SYMBOL(balloon_ptr);
> +

Why are you using a standard EXPORT_SYMBOL here instead of
EXPORT_SYMBOL_GPL? It seems like these are core functions that can
impact the memory allocator. It might make more sense to use
EXPORT_SYMBOL_GPL.

> +void release_buddy_pages(void *hinting_req, int entries)
>  {
>         int i = 0;
>         int mt = 0;
> -       struct guest_isolated_pages *isolated_pages_obj = obj_to_free;
> +       struct guest_isolated_pages *isolated_pages_obj = hinting_req;
>
>         while (i < entries) {
>                 struct page *page = pfn_to_page(isolated_pages_obj[i].pfn);

See my comment above, I am pretty sure you need to be exporting this.
I had to change this in order to be able to build.

Re: [RFC][Patch v9 0/6] KVM: Guest Free Page Hinting

[David Hildenbrand]

On 06.03.19 21:32, Michael S. Tsirkin wrote:
> On Wed, Mar 06, 2019 at 07:59:57PM +0100, David Hildenbrand wrote:
>> On 06.03.19 19:43, Michael S. Tsirkin wrote:
>>> On Wed, Mar 06, 2019 at 01:30:14PM -0500, Nitesh Narayan Lal wrote:
>>>>>> Here are the results:
>>>>>>
>>>>>> Procedure: 3 Guests of size 5GB is launched on a single NUMA node with
>>>>>> total memory of 15GB and no swap. In each of the guest, memhog is run
>>>>>> with 5GB. Post-execution of memhog, Host memory usage is monitored by
>>>>>> using Free command.
>>>>>>
>>>>>> Without Hinting:
>>>>>>                  Time of execution    Host used memory
>>>>>> Guest 1:        45 seconds            5.4 GB
>>>>>> Guest 2:        45 seconds            10 GB
>>>>>> Guest 3:        1  minute               15 GB
>>>>>>
>>>>>> With Hinting:
>>>>>>                 Time of execution     Host used memory
>>>>>> Guest 1:        49 seconds            2.4 GB
>>>>>> Guest 2:        40 seconds            4.3 GB
>>>>>> Guest 3:        50 seconds            6.3 GB
>>>>> OK so no improvement.
>>>> If we are looking in terms of memory we are getting back from the guest,
>>>> then there is an improvement. However, if we are looking at the
>>>> improvement in terms of time of execution of memhog then yes there is none.
>>>
>>> Yes but the way I see it you can't overcommit this unused memory
>>> since guests can start using it at any time.  You timed it carefully
>>> such that this does not happen, but what will cause this timing on real
>>> guests?
>>
>> Whenever you overcommit you will need backup swap.
> 
> Right and the point of hinting is that pages can just be
> discarded and not end up in swap.
> 
> 
> Point is you should be able to see the gain.
> 
> Hinting patches cost some CPU so we need to know whether
> they cost too much. How much is too much? When the cost
> is bigger than benefit. But we can't compare CPU cycles
> to bytes. So we need to benchmark everything in terms of
> cycles.
> 
>> There is no way
>> around it. It just makes the probability of you having to go to disk
>> less likely.
> 
> 
> Right and let's quantify this. Does this result in net gain or loss?

Yes, I am totally with you. But if it is a net benefit heavily depends
on the setup. E.g. what kind of storage used for the swap, how fast, is
the same disk also used for other I/O ...

Also, CPU is a totally different resource than I/O. While you might have
plenty of CPU cycles to spare, your I/O throughput might already be
limited. Same goes into the other direction.

So it might not be as easy as comparing two numbers. It really depends
on the setup. Well, not completely true, with 0% CPU overhead we would
have a clear winner with hinting ;)

> 
> 
>> If you assume that all of your guests will be using all of their memory
>> all the time, you don't have to think about overcommiting memory in the
>> first place. But this is not what we usually have.
> 
> Right and swap is there to support overcommit. However it
> was felt that hinting can be faster since it avoids IO
> involved in swap.

Feels like it, I/O is prone to be slow.


-- 

Thanks,

David / dhildenb

Re: [RFC][Patch v9 0/6] KVM: Guest Free Page Hinting

[Alexander Duyck]

On Wed, Mar 6, 2019 at 11:07 AM Nitesh Narayan Lal <nitesh@redhat.com> wrote:
>
>
> On 3/6/19 1:00 PM, Alexander Duyck wrote:
> > On Wed, Mar 6, 2019 at 7:51 AM Nitesh Narayan Lal <nitesh@redhat.com> wrote:
> >> The following patch-set proposes an efficient mechanism for handing freed memory between the guest and the host. It enables the guests with no page cache to rapidly free and reclaims memory to and from the host respectively.
> >>
> >> Benefit:
> >> With this patch-series, in our test-case, executed on a single system and single NUMA node with 15GB memory, we were able to successfully launch 5 guests(each with 5 GB memory) when page hinting was enabled and 3 without it. (Detailed explanation of the test procedure is provided at the bottom under Test - 1).
> >>
> >> Changelog in v9:
> >>         * Guest free page hinting hook is now invoked after a page has been merged in the buddy.
> >>         * Free pages only with order FREE_PAGE_HINTING_MIN_ORDER(currently defined as MAX_ORDER - 1) are captured.
> >>         * Removed kthread which was earlier used to perform the scanning, isolation & reporting of free pages.
> > Without a kthread this has the potential to get really ugly really
> > fast. If we are going to run asynchronously we should probably be
> > truly asynchonous and just place a few pieces of data in the page that
> > a worker thread can use to identify which pages have been hinted and
> > which pages have not.
>
> Can you please explain what do you mean by truly asynchronous?
>
> With this implementation also I am not reporting the pages synchronously.

The problem is you are making it pseudo synchronous by having to push
pages off to a side buffer aren't you? In my mind we should be able to
have the page hinting go on with little to no interference with
existing page allocation and freeing.

> > Then we can have that one thread just walking
> > through the zone memory pulling out fixed size pieces at a time and
> > providing hints on that. By doing that we avoid the potential of
> > creating a batch of pages that eat up most of the system memory.
> >
> >>         * Pages, captured in the per cpu array are sorted based on the zone numbers. This is to avoid redundancy of acquiring zone locks.
> >>         * Dynamically allocated space is used to hold the isolated guest free pages.
> > I have concerns that doing this per CPU and allocating memory
> > dynamically can result in you losing a significant amount of memory as
> > it sits waiting to be hinted.
> It should not as the buddy will keep merging the pages and we are only
> capturing MAX_ORDER - 1.
> This was the issue with the last patch-series when I was capturing all
> order pages resulting in the per-cpu array to be filled with lower order
> pages.
> >
> >>         * All the pages are reported asynchronously to the host via virtio driver.
> >>         * Pages are returned back to the guest buddy free list only when the host response is received.
> > I have been thinking about this. Instead of stealing the page couldn't
> > you simply flag it that there is a hint in progress and simply wait in
> > arch_alloc_page until the hint has been processed?
> With the flag, I am assuming you mean to block the allocation until
> hinting is going on, which is an issue. That was one of the issues
> discussed earlier which I wanted to solve with this implementation.

With the flag we would allow the allocation, but would have to
synchronize with the hinting at that point. I got the idea from the
way the s390 code works. They have both an arch_free_page and an
arch_alloc_page. If I understand correctly the arch_alloc_page is what
is meant to handle the case of a page that has been marked for
hinting, but may not have been hinted on yet. My thought for now is to
keep it simple and use a page flag to indicate that a page is
currently pending a hint. We should be able to spin in such a case and
it would probably still perform better than a solution where we would
not have the memory available and possibly be under memory pressure.

> > The problem is in
> > stealing pages you are going to introduce false OOM issues when the
> > memory isn't available because it is being hinted on.
> I think this situation will arise when the guest is under memory
> pressure. In such situations any attempt to perform isolation will
> anyways fail and we may not be reporting anything at that time.

What I want to avoid is the scenario where an application grabs a
large amount of memory, then frees said memory, and we are sitting on
it for some time because we decide to try and hint on the large chunk.
By processing this sometime after the pages are sent to the buddy
allocator in a separate thread, and by processing a small fixed window
of memory at a time we can avoid making freeing memory expensive, and
still provide the hints in a reasonable time frame.

> >
> >> Pending items:
> >>         * Make sure that the guest free page hinting's current implementation doesn't break hugepages or device assigned guests.
> >>         * Follow up on VIRTIO_BALLOON_F_PAGE_POISON's device side support. (It is currently missing)
> >>         * Compare reporting free pages via vring with vhost.
> >>         * Decide between MADV_DONTNEED and MADV_FREE.
> >>         * Analyze overall performance impact due to guest free page hinting.
> >>         * Come up with proper/traceable error-message/logs.
> > I'll try applying these patches and see if I can reproduce the results
> > you reported.
> Thanks. Let me know if you run into any issues.
> > With the last patch set I couldn't reproduce the results
> > as you reported them.
> If I remember correctly then the last time you only tried with multiple
> vcpus and not with 1 vcpu.

I had tried 1 vcpu, however I ended up running into some other issues
that made it difficult to even boot the system last week.

> > It has me wondering if you were somehow seeing
> > the effects of a balloon instead of the actual memory hints as I
> > couldn't find any evidence of the memory ever actually being freed
> > back by the hints functionality.
>
> Can you please elaborate what kind of evidence you are looking for?
>
> I did trace the hints on the QEMU/host side.

It looks like the new patches are working as I am seeing the memory
freeing occurring this time around. Although it looks like this is
still generating traces from free_pcpages_bulk if I enable multiple
VCPUs:

[  175.823539] list_add corruption. next->prev should be prev
(ffff947c7ffd61e0), but was ffffc7a29f9e0008. (next=ffffc7a29f4c0008).
[  175.825978] ------------[ cut here ]------------
[  175.826889] kernel BUG at lib/list_debug.c:25!
[  175.827766] invalid opcode: 0000 [#1] SMP PTI
[  175.828621] CPU: 5 PID: 1344 Comm: page_fault1_thr Not tainted
5.0.0-next-20190306-baseline+ #76
[  175.830312] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS Bochs 01/01/2011
[  175.831885] RIP: 0010:__list_add_valid+0x35/0x70
[  175.832784] Code: 18 48 8b 32 48 39 f0 75 39 48 39 c7 74 1e 48 39
fa 74 19 b8 01 00 00 00 c3 48 89 c1 48 c7 c7 80 b5 0f a9 31 c0 e8 8f
aa c8 ff <0f> 0b 48 89 c1 48 89 fe 31 c0 48 c7 c7 30 b6 0f a9 e8 79 aa
c8 ff
[  175.836379] RSP: 0018:ffffa717c40839b0 EFLAGS: 00010046
[  175.837394] RAX: 0000000000000075 RBX: ffff947c7ffd61e0 RCX: 0000000000000000
[  175.838779] RDX: 0000000000000000 RSI: ffff947c5f957188 RDI: ffff947c5f957188
[  175.840162] RBP: ffff947c7ffd61d0 R08: 000000000000026f R09: 0000000000000005
[  175.841539] R10: 0000000000000000 R11: ffffa717c4083730 R12: ffffc7a29f260008
[  175.842932] R13: ffff947c7ffd5d00 R14: ffffc7a29f4c0008 R15: ffffc7a29f260000
[  175.844319] FS:  0000000000000000(0000) GS:ffff947c5f940000(0000)
knlGS:0000000000000000
[  175.845896] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  175.847009] CR2: 00007fffe3421000 CR3: 000000051220e006 CR4: 0000000000160ee0
[  175.848390] Call Trace:
[  175.848896]  free_pcppages_bulk+0x4bc/0x6a0
[  175.849723]  free_unref_page_list+0x10d/0x190
[  175.850567]  release_pages+0x103/0x4a0
[  175.851313]  tlb_flush_mmu_free+0x36/0x50
[  175.852105]  unmap_page_range+0x963/0xd50
[  175.852897]  unmap_vmas+0x62/0xc0
[  175.853549]  exit_mmap+0xb5/0x1a0
[  175.854205]  mmput+0x5b/0x120
[  175.854794]  do_exit+0x273/0xc30
[  175.855426]  ? free_unref_page_commit+0x85/0xf0
[  175.856312]  do_group_exit+0x39/0xa0
[  175.857018]  get_signal+0x172/0x7c0
[  175.857703]  do_signal+0x36/0x620
[  175.858355]  ? percpu_counter_add_batch+0x4b/0x60
[  175.859280]  ? __do_munmap+0x288/0x390
[  175.860020]  exit_to_usermode_loop+0x4c/0xa8
[  175.860859]  do_syscall_64+0x152/0x170
[  175.861595]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[  175.862586] RIP: 0033:0x7ffff76a8ec7
[  175.863292] Code: Bad RIP value.
[  175.863928] RSP: 002b:00007ffff4422eb8 EFLAGS: 00000212 ORIG_RAX:
000000000000000b
[  175.865396] RAX: 0000000000000000 RBX: 00007ffff7ff7280 RCX: 00007ffff76a8ec7
[  175.866799] RDX: 00007fffe3422000 RSI: 0000000008000000 RDI: 00007fffdb422000
[  175.868194] RBP: 0000000000001000 R08: ffffffffffffffff R09: 0000000000000000
[  175.869582] R10: 0000000000000022 R11: 0000000000000212 R12: 00007ffff4422fc0
[  175.870984] R13: 0000000000000001 R14: 00007fffffffc1b0 R15: 00007ffff44239c0
[  175.872350] Modules linked in: ip6t_rpfilter ip6t_REJECT
nf_reject_ipv6 xt_conntrack ip_set nfnetlink ebtable_nat
ebtable_broute bridge stp llc ip6table_nat ip6table_mangle
ip6table_raw ip6table_security iptable_nat nf_nat nf_conntrack
nf_defrag_ipv6 nf_defrag_ipv4 iptable_mangle iptable_raw
iptable_security ebtable_filter ebtables ip6table_filter ip6_tables
sunrpc sb_edac crct10dif_pclmul crc32_pclmul ghash_clmulni_intel
kvm_intel kvm ppdev irqbypass parport_pc parport virtio_balloon pcspkr
i2c_piix4 joydev xfs libcrc32c cirrus drm_kms_helper ttm drm e1000
crc32c_intel virtio_blk serio_raw ata_generic floppy pata_acpi
qemu_fw_cfg
[  175.883153] ---[ end trace 5b67f12a67d1f373 ]---

I should be able to rebuild the kernels/qemu and test this patch set
over the next day or two.

Thanks.

- Alex

Re: [RFC][Patch v9 0/6] KVM: Guest Free Page Hinting

[Michael S. Tsirkin]

On Wed, Mar 06, 2019 at 10:40:57PM +0100, David Hildenbrand wrote:
> On 06.03.19 21:32, Michael S. Tsirkin wrote:
> > On Wed, Mar 06, 2019 at 07:59:57PM +0100, David Hildenbrand wrote:
> >> On 06.03.19 19:43, Michael S. Tsirkin wrote:
> >>> On Wed, Mar 06, 2019 at 01:30:14PM -0500, Nitesh Narayan Lal wrote:
> >>>>>> Here are the results:
> >>>>>>
> >>>>>> Procedure: 3 Guests of size 5GB is launched on a single NUMA node with
> >>>>>> total memory of 15GB and no swap. In each of the guest, memhog is run
> >>>>>> with 5GB. Post-execution of memhog, Host memory usage is monitored by
> >>>>>> using Free command.
> >>>>>>
> >>>>>> Without Hinting:
> >>>>>>                  Time of execution    Host used memory
> >>>>>> Guest 1:        45 seconds            5.4 GB
> >>>>>> Guest 2:        45 seconds            10 GB
> >>>>>> Guest 3:        1  minute               15 GB
> >>>>>>
> >>>>>> With Hinting:
> >>>>>>                 Time of execution     Host used memory
> >>>>>> Guest 1:        49 seconds            2.4 GB
> >>>>>> Guest 2:        40 seconds            4.3 GB
> >>>>>> Guest 3:        50 seconds            6.3 GB
> >>>>> OK so no improvement.
> >>>> If we are looking in terms of memory we are getting back from the guest,
> >>>> then there is an improvement. However, if we are looking at the
> >>>> improvement in terms of time of execution of memhog then yes there is none.
> >>>
> >>> Yes but the way I see it you can't overcommit this unused memory
> >>> since guests can start using it at any time.  You timed it carefully
> >>> such that this does not happen, but what will cause this timing on real
> >>> guests?
> >>
> >> Whenever you overcommit you will need backup swap.
> > 
> > Right and the point of hinting is that pages can just be
> > discarded and not end up in swap.
> > 
> > 
> > Point is you should be able to see the gain.
> > 
> > Hinting patches cost some CPU so we need to know whether
> > they cost too much. How much is too much? When the cost
> > is bigger than benefit. But we can't compare CPU cycles
> > to bytes. So we need to benchmark everything in terms of
> > cycles.
> > 
> >> There is no way
> >> around it. It just makes the probability of you having to go to disk
> >> less likely.
> > 
> > 
> > Right and let's quantify this. Does this result in net gain or loss?
> 
> Yes, I am totally with you. But if it is a net benefit heavily depends
> on the setup. E.g. what kind of storage used for the swap, how fast, is
> the same disk also used for other I/O ...
> 
> Also, CPU is a totally different resource than I/O. While you might have
> plenty of CPU cycles to spare, your I/O throughput might already be
> limited. Same goes into the other direction.
> 
> So it might not be as easy as comparing two numbers. It really depends
> on the setup. Well, not completely true, with 0% CPU overhead we would
> have a clear winner with hinting ;)

I mean users need to know about this too.

Are these hinting patches a gain:
- on zram
- on ssd
- on a rotating disk
- none of the above
?

If users don't know when would they enable hinting?

Close to one is going to try all possible configurations, test
exhaustively and find an optimal default for their workload.
So it's our job to figure it out and provide guidance.

> 
> > 
> > 
> >> If you assume that all of your guests will be using all of their memory
> >> all the time, you don't have to think about overcommiting memory in the
> >> first place. But this is not what we usually have.
> > 
> > Right and swap is there to support overcommit. However it
> > was felt that hinting can be faster since it avoids IO
> > involved in swap.
> 
> Feels like it, I/O is prone to be slow.
> 
> 
> -- 
> 
> Thanks,
> 
> David / dhildenb

OK so should be measureable.

-- 
MST

Re: [RFC][Patch v9 0/6] KVM: Guest Free Page Hinting

[Alexander Duyck]

On Wed, Mar 6, 2019 at 2:18 PM Michael S. Tsirkin <mst@redhat.com> wrote:
>
> On Wed, Mar 06, 2019 at 10:40:57PM +0100, David Hildenbrand wrote:
> > On 06.03.19 21:32, Michael S. Tsirkin wrote:
> > > On Wed, Mar 06, 2019 at 07:59:57PM +0100, David Hildenbrand wrote:
> > >> On 06.03.19 19:43, Michael S. Tsirkin wrote:
> > >>> On Wed, Mar 06, 2019 at 01:30:14PM -0500, Nitesh Narayan Lal wrote:
> > >>>>>> Here are the results:
> > >>>>>>
> > >>>>>> Procedure: 3 Guests of size 5GB is launched on a single NUMA node with
> > >>>>>> total memory of 15GB and no swap. In each of the guest, memhog is run
> > >>>>>> with 5GB. Post-execution of memhog, Host memory usage is monitored by
> > >>>>>> using Free command.
> > >>>>>>
> > >>>>>> Without Hinting:
> > >>>>>>                  Time of execution    Host used memory
> > >>>>>> Guest 1:        45 seconds            5.4 GB
> > >>>>>> Guest 2:        45 seconds            10 GB
> > >>>>>> Guest 3:        1  minute               15 GB
> > >>>>>>
> > >>>>>> With Hinting:
> > >>>>>>                 Time of execution     Host used memory
> > >>>>>> Guest 1:        49 seconds            2.4 GB
> > >>>>>> Guest 2:        40 seconds            4.3 GB
> > >>>>>> Guest 3:        50 seconds            6.3 GB
> > >>>>> OK so no improvement.
> > >>>> If we are looking in terms of memory we are getting back from the guest,
> > >>>> then there is an improvement. However, if we are looking at the
> > >>>> improvement in terms of time of execution of memhog then yes there is none.
> > >>>
> > >>> Yes but the way I see it you can't overcommit this unused memory
> > >>> since guests can start using it at any time.  You timed it carefully
> > >>> such that this does not happen, but what will cause this timing on real
> > >>> guests?
> > >>
> > >> Whenever you overcommit you will need backup swap.
> > >
> > > Right and the point of hinting is that pages can just be
> > > discarded and not end up in swap.
> > >
> > >
> > > Point is you should be able to see the gain.
> > >
> > > Hinting patches cost some CPU so we need to know whether
> > > they cost too much. How much is too much? When the cost
> > > is bigger than benefit. But we can't compare CPU cycles
> > > to bytes. So we need to benchmark everything in terms of
> > > cycles.
> > >
> > >> There is no way
> > >> around it. It just makes the probability of you having to go to disk
> > >> less likely.
> > >
> > >
> > > Right and let's quantify this. Does this result in net gain or loss?
> >
> > Yes, I am totally with you. But if it is a net benefit heavily depends
> > on the setup. E.g. what kind of storage used for the swap, how fast, is
> > the same disk also used for other I/O ...
> >
> > Also, CPU is a totally different resource than I/O. While you might have
> > plenty of CPU cycles to spare, your I/O throughput might already be
> > limited. Same goes into the other direction.
> >
> > So it might not be as easy as comparing two numbers. It really depends
> > on the setup. Well, not completely true, with 0% CPU overhead we would
> > have a clear winner with hinting ;)
>
> I mean users need to know about this too.
>
> Are these hinting patches a gain:
> - on zram
> - on ssd
> - on a rotating disk
> - none of the above
> ?
>
> If users don't know when would they enable hinting?
>
> Close to one is going to try all possible configurations, test
> exhaustively and find an optimal default for their workload.
> So it's our job to figure it out and provide guidance.

Right. I think for now I will stick to testing on what I have which is
a SSD for swap, and no-overcommit for the "non of the above" case.

BTW it looks like this patch set introduced a pretty heavy penalty for
the no-overcommit case. For a 32G VM with no overcommit a 32G memhog
test is now taking over 50 seconds whereas without the patch set I can
complete the test in around 20 seconds.

> >
> > >
> > >
> > >> If you assume that all of your guests will be using all of their memory
> > >> all the time, you don't have to think about overcommiting memory in the
> > >> first place. But this is not what we usually have.
> > >
> > > Right and swap is there to support overcommit. However it
> > > was felt that hinting can be faster since it avoids IO
> > > involved in swap.
> >
> > Feels like it, I/O is prone to be slow.
> >
> >
> > --
> >
> > Thanks,
> >
> > David / dhildenb
>
> OK so should be measureable.
>
> --
> MST

Re: [RFC][Patch v9 1/6] KVM: Guest free page hinting support

[Alexander Duyck]

On Wed, Mar 6, 2019 at 7:51 AM Nitesh Narayan Lal <nitesh@redhat.com> wrote:
>
> This patch adds the following:
> 1. Functional skeleton for the guest implementation. It enables the
> guest to maintain the PFN of head buddy free pages of order
> FREE_PAGE_HINTING_MIN_ORDER (currently defined as MAX_ORDER - 1)
> in a per-cpu array.
> Guest uses guest_free_page_enqueue() to enqueue the free pages post buddy
> merging to the above mentioned per-cpu array.
> guest_free_page_try_hinting() is used to initiate hinting operation once
> the collected entries of the per-cpu array reaches or exceeds
> HINTING_THRESHOLD (128). Having larger array size(MAX_FGPT_ENTRIES = 256)
> than HINTING_THRESHOLD allows us to capture more pages specifically when
> guest_free_page_enqueue() is called from free_pcppages_bulk().
> For now guest_free_page_hinting() just resets the array index to continue
> capturing of the freed pages.
> 2. Enables the support for x86 architecture.
>
> Signed-off-by: Nitesh Narayan Lal <nitesh@redhat.com>
> ---
>  arch/x86/Kbuild              |  2 +-
>  arch/x86/kvm/Kconfig         |  8 +++
>  arch/x86/kvm/Makefile        |  2 +
>  include/linux/page_hinting.h | 15 ++++++
>  mm/page_alloc.c              |  5 ++
>  virt/kvm/page_hinting.c      | 98 ++++++++++++++++++++++++++++++++++++
>  6 files changed, 129 insertions(+), 1 deletion(-)
>  create mode 100644 include/linux/page_hinting.h
>  create mode 100644 virt/kvm/page_hinting.c
>
> diff --git a/arch/x86/Kbuild b/arch/x86/Kbuild
> index c625f57472f7..3244df4ee311 100644
> --- a/arch/x86/Kbuild
> +++ b/arch/x86/Kbuild
> @@ -2,7 +2,7 @@ obj-y += entry/
>
>  obj-$(CONFIG_PERF_EVENTS) += events/
>
> -obj-$(CONFIG_KVM) += kvm/
> +obj-$(subst m,y,$(CONFIG_KVM)) += kvm/
>
>  # Xen paravirtualization support
>  obj-$(CONFIG_XEN) += xen/
> diff --git a/arch/x86/kvm/Kconfig b/arch/x86/kvm/Kconfig
> index 72fa955f4a15..2fae31459706 100644
> --- a/arch/x86/kvm/Kconfig
> +++ b/arch/x86/kvm/Kconfig
> @@ -96,6 +96,14 @@ config KVM_MMU_AUDIT
>          This option adds a R/W kVM module parameter 'mmu_audit', which allows
>          auditing of KVM MMU events at runtime.
>
> +# KVM_FREE_PAGE_HINTING will allow the guest to report the free pages to the
> +# host in regular interval of time.
> +config KVM_FREE_PAGE_HINTING
> +       def_bool y
> +       depends on KVM
> +       select VIRTIO
> +       select VIRTIO_BALLOON
> +
>  # OK, it's a little counter-intuitive to do this, but it puts it neatly under
>  # the virtualization menu.
>  source "drivers/vhost/Kconfig"
> diff --git a/arch/x86/kvm/Makefile b/arch/x86/kvm/Makefile
> index 69b3a7c30013..78640a80501e 100644
> --- a/arch/x86/kvm/Makefile
> +++ b/arch/x86/kvm/Makefile
> @@ -16,6 +16,8 @@ kvm-y                 += x86.o mmu.o emulate.o i8259.o irq.o lapic.o \
>                            i8254.o ioapic.o irq_comm.o cpuid.o pmu.o mtrr.o \
>                            hyperv.o page_track.o debugfs.o
>
> +obj-$(CONFIG_KVM_FREE_PAGE_HINTING)    += $(KVM)/page_hinting.o
> +
>  kvm-intel-y            += vmx/vmx.o vmx/vmenter.o vmx/pmu_intel.o vmx/vmcs12.o vmx/evmcs.o vmx/nested.o
>  kvm-amd-y              += svm.o pmu_amd.o
>
> diff --git a/include/linux/page_hinting.h b/include/linux/page_hinting.h
> new file mode 100644
> index 000000000000..90254c582789
> --- /dev/null
> +++ b/include/linux/page_hinting.h
> @@ -0,0 +1,15 @@
> +#include <linux/gfp.h>
> +/*
> + * Size of the array which is used to store the freed pages is defined by
> + * MAX_FGPT_ENTRIES.
> + */
> +#define MAX_FGPT_ENTRIES       256
> +/*
> + * Threshold value after which hinting needs to be initiated on the captured
> + * free pages.
> + */
> +#define HINTING_THRESHOLD      128
> +#define FREE_PAGE_HINTING_MIN_ORDER    (MAX_ORDER - 1)
> +
> +void guest_free_page_enqueue(struct page *page, int order);
> +void guest_free_page_try_hinting(void);
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index d295c9bc01a8..684d047f33ee 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -67,6 +67,7 @@
>  #include <linux/lockdep.h>
>  #include <linux/nmi.h>
>  #include <linux/psi.h>
> +#include <linux/page_hinting.h>
>
>  #include <asm/sections.h>
>  #include <asm/tlbflush.h>
> @@ -1194,9 +1195,11 @@ static void free_pcppages_bulk(struct zone *zone, int count,
>                         mt = get_pageblock_migratetype(page);
>
>                 __free_one_page(page, page_to_pfn(page), zone, 0, mt);
> +               guest_free_page_enqueue(page, 0);
>                 trace_mm_page_pcpu_drain(page, 0, mt);
>         }
>         spin_unlock(&zone->lock);
> +       guest_free_page_try_hinting();
>  }
>

Trying to enqueue pages from here seems like a really bad idea. You
are essentially putting yourself in a hot-path for order 0 pages and
going to cause significant bottlenecks.

>  static void free_one_page(struct zone *zone,
> @@ -1210,7 +1213,9 @@ static void free_one_page(struct zone *zone,
>                 migratetype = get_pfnblock_migratetype(page, pfn);
>         }
>         __free_one_page(page, pfn, zone, order, migratetype);
> +       guest_free_page_enqueue(page, order);
>         spin_unlock(&zone->lock);
> +       guest_free_page_try_hinting();
>  }

I really think it would be better to leave the page assembly to the
buddy allocator. Instead you may want to focus on somehow tagging the
pages as being recently freed but not hinted on so that you can come
back later to work on them.

>  static void __meminit __init_single_page(struct page *page, unsigned long pfn,
> diff --git a/virt/kvm/page_hinting.c b/virt/kvm/page_hinting.c
> new file mode 100644
> index 000000000000..48b4b5e796b0
> --- /dev/null
> +++ b/virt/kvm/page_hinting.c
> @@ -0,0 +1,98 @@
> +#include <linux/mm.h>
> +#include <linux/page_hinting.h>
> +
> +/*
> + * struct guest_free_pages- holds array of guest freed PFN's along with an
> + * index variable to track total freed PFN's.
> + * @free_pfn_arr: array to store the page frame number of all the pages which
> + * are freed by the guest.
> + * @guest_free_pages_idx: index to track the number entries stored in
> + * free_pfn_arr.
> + */
> +struct guest_free_pages {
> +       unsigned long free_page_arr[MAX_FGPT_ENTRIES];
> +       int free_pages_idx;
> +};
> +
> +DEFINE_PER_CPU(struct guest_free_pages, free_pages_obj);
> +
> +struct page *get_buddy_page(struct page *page)
> +{
> +       unsigned long pfn = page_to_pfn(page);
> +       unsigned int order;
> +
> +       for (order = 0; order < MAX_ORDER; order++) {
> +               struct page *page_head = page - (pfn & ((1 << order) - 1));
> +
> +               if (PageBuddy(page_head) && page_private(page_head) >= order)
> +                       return page_head;
> +       }
> +       return NULL;
> +}
> +

You would be much better off just letting the buddy allocator take care of this.

I really think the spot I had my arch_merge_page call would work much
better than this. The buddy allocator is already optimized to handle
merging the pages and such so we should really let it do its job
rather than reinventing it ourselves.

> +static void guest_free_page_hinting(void)
> +{
> +       struct guest_free_pages *hinting_obj = &get_cpu_var(free_pages_obj);
> +
> +       hinting_obj->free_pages_idx = 0;
> +       put_cpu_var(hinting_obj);
> +}
> +

Shouldn't this be guarded with a local_irq_save to prevent someone
from possibly performing an enqueue on the same CPU as the one you are
resetting the work on, or is just the preempt_disable int he
get_cpu_var enough to handle the case? If so could we get away with
the same thing for the guest_free_page_enqueue?

> +int if_exist(struct page *page)
> +{
> +       int i = 0;
> +       struct guest_free_pages *hinting_obj = this_cpu_ptr(&free_pages_obj);
> +
> +       while (i < MAX_FGPT_ENTRIES) {
> +               if (page_to_pfn(page) == hinting_obj->free_page_arr[i])
> +                       return 1;
> +               i++;
> +       }
> +       return 0;
> +}
> +

Doing a linear search for the page is going to be painful. Also this
is only searching a per-cpu list. What if you have this split over a
couple of CPUs?

> +void guest_free_page_enqueue(struct page *page, int order)
> +{
> +       unsigned long flags;
> +       struct guest_free_pages *hinting_obj;
> +       int l_idx;
> +
> +       /*
> +        * use of global variables may trigger a race condition between irq and
> +        * process context causing unwanted overwrites. This will be replaced
> +        * with a better solution to prevent such race conditions.
> +        */
> +       local_irq_save(flags);
> +       hinting_obj = this_cpu_ptr(&free_pages_obj);
> +       l_idx = hinting_obj->free_pages_idx;
> +       if (l_idx != MAX_FGPT_ENTRIES) {
> +               if (PageBuddy(page) && page_private(page) >=
> +                   FREE_PAGE_HINTING_MIN_ORDER) {
> +                       hinting_obj->free_page_arr[l_idx] = page_to_pfn(page);
> +                       hinting_obj->free_pages_idx += 1;
> +               } else {
> +                       struct page *buddy_page = get_buddy_page(page);
> +
> +                       if (buddy_page && page_private(buddy_page) >=
> +                           FREE_PAGE_HINTING_MIN_ORDER &&
> +                           !if_exist(buddy_page)) {
> +                               unsigned long buddy_pfn =
> +                                       page_to_pfn(buddy_page);
> +
> +                               hinting_obj->free_page_arr[l_idx] =
> +                                                       buddy_pfn;
> +                               hinting_obj->free_pages_idx += 1;
> +                       }
> +               }
> +       }
> +       local_irq_restore(flags);
> +}
> +
> +void guest_free_page_try_hinting(void)
> +{
> +       struct guest_free_pages *hinting_obj;
> +
> +       hinting_obj = this_cpu_ptr(&free_pages_obj);
> +       if (hinting_obj->free_pages_idx >= HINTING_THRESHOLD)
> +               guest_free_page_hinting();
> +}
> --
> 2.17.2
>

Re: [RFC][QEMU Patch] KVM: Enable QEMU to free the pages hinted by the guest

[Alexander Duyck]

On Wed, Mar 6, 2019 at 7:52 AM Nitesh Narayan Lal <nitesh@redhat.com> wrote:
>
> This patch enables QEMU to perform MADVISE_DONTNEED on the pages
> reported by the guest.
>
> Signed-off-by: Nitesh Narayan Lal <nitesh@redhat.com>
> ---
>  hw/virtio/trace-events                        |  1 +
>  hw/virtio/virtio-balloon.c                    | 90 +++++++++++++++++++
>  include/hw/virtio/virtio-balloon.h            |  2 +-
>  .../standard-headers/linux/virtio_balloon.h   |  1 +
>  4 files changed, 93 insertions(+), 1 deletion(-)
>
> diff --git a/hw/virtio/trace-events b/hw/virtio/trace-events
> index 07bcbe9e85..e3ab66f126 100644
> --- a/hw/virtio/trace-events
> +++ b/hw/virtio/trace-events
> @@ -46,3 +46,4 @@ virtio_balloon_handle_output(const char *name, uint64_t gpa) "section name: %s g
>  virtio_balloon_get_config(uint32_t num_pages, uint32_t actual) "num_pages: %d actual: %d"
>  virtio_balloon_set_config(uint32_t actual, uint32_t oldactual) "actual: %d oldactual: %d"
>  virtio_balloon_to_target(uint64_t target, uint32_t num_pages) "balloon target: 0x%"PRIx64" num_pages: %d"
> +virtio_balloon_hinting_request(unsigned long pfn, unsigned int num_pages) "Guest page hinting request: %lu num_pages: %d"
> diff --git a/hw/virtio/virtio-balloon.c b/hw/virtio/virtio-balloon.c
> index a12677d4d5..7ab1471017 100644
> --- a/hw/virtio/virtio-balloon.c
> +++ b/hw/virtio/virtio-balloon.c
> @@ -33,6 +33,13 @@
>
>  #define BALLOON_PAGE_SIZE  (1 << VIRTIO_BALLOON_PFN_SHIFT)
>
> +struct guest_pages {
> +       unsigned long pfn;
> +       unsigned int order;
> +};
> +
> +void page_hinting_request(uint64_t addr, uint32_t len);
> +
>  static void balloon_page(void *addr, int deflate)
>  {
>      if (!qemu_balloon_is_inhibited()) {
> @@ -207,6 +214,85 @@ static void balloon_stats_set_poll_interval(Object *obj, Visitor *v,
>      balloon_stats_change_timer(s, 0);
>  }
>
> +static void *gpa2hva(MemoryRegion **p_mr, hwaddr addr, Error **errp)
> +{
> +    MemoryRegionSection mrs = memory_region_find(get_system_memory(),
> +                                                 addr, 1);
> +
> +    if (!mrs.mr) {
> +        error_setg(errp, "No memory is mapped at address 0x%" HWADDR_PRIx, addr);
> +        return NULL;
> +    }
> +
> +    if (!memory_region_is_ram(mrs.mr) && !memory_region_is_romd(mrs.mr)) {
> +        error_setg(errp, "Memory at address 0x%" HWADDR_PRIx "is not RAM", addr);
> +        memory_region_unref(mrs.mr);
> +        return NULL;
> +    }
> +
> +    *p_mr = mrs.mr;
> +    return qemu_map_ram_ptr(mrs.mr->ram_block, mrs.offset_within_region);
> +}
> +
> +void page_hinting_request(uint64_t addr, uint32_t len)
> +{
> +    Error *local_err = NULL;
> +    MemoryRegion *mr = NULL;
> +    int ret = 0;
> +    struct guest_pages *guest_obj;
> +    int i = 0;
> +    void *hvaddr_to_free;
> +    unsigned long pfn, pfn_end;
> +    uint64_t gpaddr_to_free;
> +    void * temp_addr = gpa2hva(&mr, addr, &local_err);
> +
> +    if (local_err) {
> +        error_report_err(local_err);
> +        return;
> +    }
> +    guest_obj = temp_addr;
> +    while (i < len) {
> +        pfn = guest_obj[i].pfn;
> +       pfn_end = guest_obj[i].pfn + (1 << guest_obj[i].order) - 1;
> +       trace_virtio_balloon_hinting_request(pfn,(1 << guest_obj[i].order));
> +       while (pfn <= pfn_end) {
> +               gpaddr_to_free = pfn << VIRTIO_BALLOON_PFN_SHIFT;
> +               hvaddr_to_free = gpa2hva(&mr, gpaddr_to_free, &local_err);
> +               if (local_err) {
> +                       error_report_err(local_err);
> +                       return;
> +               }
> +               ret = qemu_madvise((void *)hvaddr_to_free, 4096, QEMU_MADV_DONTNEED);

So the structure of this function is going to cause significant
performance issues. Because we are freeing the memory 4K at a time we
are kicking the pages out of using THP and as a result each page fault
will occur on a 4K boundary instead of a THP boundary.

As a result I am seeing the first pass of memhog take around 35s, but
the second pass takes 57s or so because we are no longer faulting in
THP pages and instead having to fault in 4K pages.

We should be trying to madvise the lesser of either PAGE_SIZE <<
guest_obj[i[.order or the size of the memory region minus our offset.

> +               if (ret == -1)
> +                   printf("\n%d:%s Error: Madvise failed with error:%d\n", __LINE__, __func__, ret);
> +               pfn++;
> +       }
> +       i++;
> +    }
> +}
> +
> +static void virtio_balloon_page_hinting(VirtIODevice *vdev, VirtQueue *vq)
> +{
> +    VirtQueueElement *elem = NULL;
> +    uint64_t temp_addr;
> +    uint32_t temp_len;
> +    size_t size, t_size = 0;
> +
> +    elem = virtqueue_pop(vq, sizeof(VirtQueueElement));
> +    if (!elem) {
> +       printf("\npop error\n");
> +       return;
> +    }
> +    size = iov_to_buf(elem->out_sg, elem->out_num, 0, &temp_addr, sizeof(temp_addr));
> +    t_size += size;
> +    size = iov_to_buf(elem->out_sg, elem->out_num, 8, &temp_len, sizeof(temp_len));
> +    t_size += size;
> +    page_hinting_request(temp_addr, temp_len);
> +    virtqueue_push(vq, elem, t_size);
> +    virtio_notify(vdev, vq);
> +    g_free(elem);
> +}
> +
>  static void virtio_balloon_handle_output(VirtIODevice *vdev, VirtQueue *vq)
>  {
>      VirtIOBalloon *s = VIRTIO_BALLOON(vdev);
> @@ -376,6 +462,7 @@ 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);
> +    virtio_add_feature(&f, VIRTIO_BALLOON_F_HINTING);
>      return f;
>  }
>
> @@ -445,6 +532,7 @@ static void virtio_balloon_device_realize(DeviceState *dev, Error **errp)
>      s->ivq = virtio_add_queue(vdev, 128, virtio_balloon_handle_output);
>      s->dvq = virtio_add_queue(vdev, 128, virtio_balloon_handle_output);
>      s->svq = virtio_add_queue(vdev, 128, virtio_balloon_receive_stats);
> +    s->hvq = virtio_add_queue(vdev, 128, virtio_balloon_page_hinting);
>
>      reset_stats(s);
>  }
> @@ -488,6 +576,8 @@ static void virtio_balloon_instance_init(Object *obj)
>
>      object_property_add(obj, "guest-stats", "guest statistics",
>                          balloon_stats_get_all, NULL, NULL, s, NULL);
> +    object_property_add(obj, "guest-page-hinting", "guest page hinting",
> +                        NULL, NULL, NULL, s, NULL);
>
>      object_property_add(obj, "guest-stats-polling-interval", "int",
>                          balloon_stats_get_poll_interval,
> diff --git a/include/hw/virtio/virtio-balloon.h b/include/hw/virtio/virtio-balloon.h
> index e0df3528c8..774498a6ca 100644
> --- a/include/hw/virtio/virtio-balloon.h
> +++ b/include/hw/virtio/virtio-balloon.h
> @@ -32,7 +32,7 @@ typedef struct virtio_balloon_stat_modern {
>
>  typedef struct VirtIOBalloon {
>      VirtIODevice parent_obj;
> -    VirtQueue *ivq, *dvq, *svq;
> +    VirtQueue *ivq, *dvq, *svq, *hvq;
>      uint32_t num_pages;
>      uint32_t actual;
>      uint64_t stats[VIRTIO_BALLOON_S_NR];
> diff --git a/include/standard-headers/linux/virtio_balloon.h b/include/standard-headers/linux/virtio_balloon.h
> index 4dbb7dc6c0..f50c0d95ea 100644
> --- a/include/standard-headers/linux/virtio_balloon.h
> +++ b/include/standard-headers/linux/virtio_balloon.h
> @@ -34,6 +34,7 @@
>  #define VIRTIO_BALLOON_F_MUST_TELL_HOST        0 /* Tell before reclaiming pages */
>  #define VIRTIO_BALLOON_F_STATS_VQ      1 /* Memory Stats virtqueue */
>  #define VIRTIO_BALLOON_F_DEFLATE_ON_OOM        2 /* Deflate balloon on OOM */
> +#define VIRTIO_BALLOON_F_HINTING       5 /* Page hinting virtqueue */
>
>  /* Size of a PFN in the balloon interface. */
>  #define VIRTIO_BALLOON_PFN_SHIFT 12
> --
> 2.17.2
>

Re: [RFC][QEMU Patch] KVM: Enable QEMU to free the pages hinted by the guest

[Alexander Duyck]

Here are some changes I made to your patch in order to address the sizing
issue I called out. You may want to try testing with this patch applied to
your QEMU as I am finding it is making a signficant difference. It has cut
the test time for the 32G memhog test I called out earlier in half.

Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
---
 hw/virtio/virtio-balloon.c |   28 +++++++++++++++++-----------
 1 file changed, 17 insertions(+), 11 deletions(-)

diff --git a/hw/virtio/virtio-balloon.c b/hw/virtio/virtio-balloon.c
index d2cf66ada3c0..3ca6b1c6d511 100644
--- a/hw/virtio/virtio-balloon.c
+++ b/hw/virtio/virtio-balloon.c
@@ -285,7 +285,7 @@ static void balloon_stats_set_poll_interval(Object *obj, Visitor *v,
     balloon_stats_change_timer(s, 0);
 }
 
-static void *gpa2hva(MemoryRegion **p_mr, hwaddr addr, Error **errp)
+static void *gpa2hva(MemoryRegion **p_mr, unsigned long *size, hwaddr addr, Error **errp)
 {
     MemoryRegionSection mrs = memory_region_find(get_system_memory(),
                                                  addr, 1);
@@ -302,6 +302,7 @@ static void *gpa2hva(MemoryRegion **p_mr, hwaddr addr, Error **errp)
     }
 
     *p_mr = mrs.mr;
+    *size = mrs.mr->size - mrs.offset_within_region;
     return qemu_map_ram_ptr(mrs.mr->ram_block, mrs.offset_within_region);
 }
 
@@ -313,30 +314,35 @@ void page_hinting_request(uint64_t addr, uint32_t len)
     struct guest_pages *guest_obj;
     int i = 0;
     void *hvaddr_to_free;
-    unsigned long pfn, pfn_end;
     uint64_t gpaddr_to_free;
-    void * temp_addr = gpa2hva(&mr, addr, &local_err);
+    unsigned long madv_size, size;
+    void * temp_addr = gpa2hva(&mr, &madv_size, addr, &local_err);
 
     if (local_err) {
         error_report_err(local_err);
         return;
     }
+    if (madv_size < sizeof(*guest_obj)) {
+	printf("\nBad guest object ptr\n");
+	return;
+    }
     guest_obj = temp_addr;
     while (i < len) {
-        pfn = guest_obj[i].pfn;
-	pfn_end = guest_obj[i].pfn + (1 << guest_obj[i].order) - 1;
-	trace_virtio_balloon_hinting_request(pfn,(1 << guest_obj[i].order));
-	while (pfn <= pfn_end) {
-	        gpaddr_to_free = pfn << VIRTIO_BALLOON_PFN_SHIFT;
-	        hvaddr_to_free = gpa2hva(&mr, gpaddr_to_free, &local_err);
+        gpaddr_to_free = guest_obj[i].pfn << VIRTIO_BALLOON_PFN_SHIFT;
+	size = (1 << VIRTIO_BALLOON_PFN_SHIFT) << guest_obj[i].order;
+	while (size) {
+	        hvaddr_to_free = gpa2hva(&mr, &madv_size, gpaddr_to_free, &local_err);
 	        if (local_err) {
 			error_report_err(local_err);
 		        return;
 		}
-		ret = qemu_madvise((void *)hvaddr_to_free, 4096, QEMU_MADV_DONTNEED);
+		if (size < madv_size)
+			madv_size = size;
+		ret = qemu_madvise((void *)hvaddr_to_free, madv_size, QEMU_MADV_DONTNEED);
 		if (ret == -1)
 		    printf("\n%d:%s Error: Madvise failed with error:%d\n", __LINE__, __func__, ret);
-		pfn++;
+		gpaddr_to_free += madv_size;
+		size -= madv_size;
 	}
 	i++;
     }

Re: [RFC][QEMU Patch] KVM: Enable QEMU to free the pages hinted by the guest

[Nitesh Narayan Lal]

[-- Attachment #1.1: Type: text/plain, Size: 3308 bytes --]


On 3/6/19 7:35 PM, Alexander Duyck wrote:
> Here are some changes I made to your patch in order to address the sizing
> issue I called out. You may want to try testing with this patch applied to
> your QEMU as I am finding it is making a signficant difference. It has cut
> the test time for the 32G memhog test I called out earlier in half.
Thanks, I will try this out.
>
> Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> ---
>  hw/virtio/virtio-balloon.c |   28 +++++++++++++++++-----------
>  1 file changed, 17 insertions(+), 11 deletions(-)
>
> diff --git a/hw/virtio/virtio-balloon.c b/hw/virtio/virtio-balloon.c
> index d2cf66ada3c0..3ca6b1c6d511 100644
> --- a/hw/virtio/virtio-balloon.c
> +++ b/hw/virtio/virtio-balloon.c
> @@ -285,7 +285,7 @@ static void balloon_stats_set_poll_interval(Object *obj, Visitor *v,
>      balloon_stats_change_timer(s, 0);
>  }
>  
> -static void *gpa2hva(MemoryRegion **p_mr, hwaddr addr, Error **errp)
> +static void *gpa2hva(MemoryRegion **p_mr, unsigned long *size, hwaddr addr, Error **errp)
>  {
>      MemoryRegionSection mrs = memory_region_find(get_system_memory(),
>                                                   addr, 1);
> @@ -302,6 +302,7 @@ static void *gpa2hva(MemoryRegion **p_mr, hwaddr addr, Error **errp)
>      }
>  
>      *p_mr = mrs.mr;
> +    *size = mrs.mr->size - mrs.offset_within_region;
>      return qemu_map_ram_ptr(mrs.mr->ram_block, mrs.offset_within_region);
>  }
>  
> @@ -313,30 +314,35 @@ void page_hinting_request(uint64_t addr, uint32_t len)
>      struct guest_pages *guest_obj;
>      int i = 0;
>      void *hvaddr_to_free;
> -    unsigned long pfn, pfn_end;
>      uint64_t gpaddr_to_free;
> -    void * temp_addr = gpa2hva(&mr, addr, &local_err);
> +    unsigned long madv_size, size;
> +    void * temp_addr = gpa2hva(&mr, &madv_size, addr, &local_err);
>  
>      if (local_err) {
>          error_report_err(local_err);
>          return;
>      }
> +    if (madv_size < sizeof(*guest_obj)) {
> +	printf("\nBad guest object ptr\n");
> +	return;
> +    }
>      guest_obj = temp_addr;
>      while (i < len) {
> -        pfn = guest_obj[i].pfn;
> -	pfn_end = guest_obj[i].pfn + (1 << guest_obj[i].order) - 1;
> -	trace_virtio_balloon_hinting_request(pfn,(1 << guest_obj[i].order));
> -	while (pfn <= pfn_end) {
> -	        gpaddr_to_free = pfn << VIRTIO_BALLOON_PFN_SHIFT;
> -	        hvaddr_to_free = gpa2hva(&mr, gpaddr_to_free, &local_err);
> +        gpaddr_to_free = guest_obj[i].pfn << VIRTIO_BALLOON_PFN_SHIFT;
> +	size = (1 << VIRTIO_BALLOON_PFN_SHIFT) << guest_obj[i].order;
> +	while (size) {
> +	        hvaddr_to_free = gpa2hva(&mr, &madv_size, gpaddr_to_free, &local_err);
>  	        if (local_err) {
>  			error_report_err(local_err);
>  		        return;
>  		}
> -		ret = qemu_madvise((void *)hvaddr_to_free, 4096, QEMU_MADV_DONTNEED);
> +		if (size < madv_size)
> +			madv_size = size;
> +		ret = qemu_madvise((void *)hvaddr_to_free, madv_size, QEMU_MADV_DONTNEED);
>  		if (ret == -1)
>  		    printf("\n%d:%s Error: Madvise failed with error:%d\n", __LINE__, __func__, ret);
> -		pfn++;
> +		gpaddr_to_free += madv_size;
> +		size -= madv_size;
>  	}
>  	i++;
>      }
>
-- 
Regards
Nitesh


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [RFC][Patch v9 0/6] KVM: Guest Free Page Hinting

[Nitesh Narayan Lal]

[-- Attachment #1.1: Type: text/plain, Size: 12031 bytes --]


On 3/6/19 5:05 PM, Alexander Duyck wrote:
> On Wed, Mar 6, 2019 at 11:07 AM Nitesh Narayan Lal <nitesh@redhat.com> wrote:
>>
>> On 3/6/19 1:00 PM, Alexander Duyck wrote:
>>> On Wed, Mar 6, 2019 at 7:51 AM Nitesh Narayan Lal <nitesh@redhat.com> wrote:
>>>> The following patch-set proposes an efficient mechanism for handing freed memory between the guest and the host. It enables the guests with no page cache to rapidly free and reclaims memory to and from the host respectively.
>>>>
>>>> Benefit:
>>>> With this patch-series, in our test-case, executed on a single system and single NUMA node with 15GB memory, we were able to successfully launch 5 guests(each with 5 GB memory) when page hinting was enabled and 3 without it. (Detailed explanation of the test procedure is provided at the bottom under Test - 1).
>>>>
>>>> Changelog in v9:
>>>>         * Guest free page hinting hook is now invoked after a page has been merged in the buddy.
>>>>         * Free pages only with order FREE_PAGE_HINTING_MIN_ORDER(currently defined as MAX_ORDER - 1) are captured.
>>>>         * Removed kthread which was earlier used to perform the scanning, isolation & reporting of free pages.
>>> Without a kthread this has the potential to get really ugly really
>>> fast. If we are going to run asynchronously we should probably be
>>> truly asynchonous and just place a few pieces of data in the page that
>>> a worker thread can use to identify which pages have been hinted and
>>> which pages have not.
>> Can you please explain what do you mean by truly asynchronous?
>>
>> With this implementation also I am not reporting the pages synchronously.
> The problem is you are making it pseudo synchronous by having to push
> pages off to a side buffer aren't you? In my mind we should be able to
> have the page hinting go on with little to no interference with
> existing page allocation and freeing.
We have to opt one of the two options:
1. Block allocation by using a flag or acquire a lock to prevent the
usage of pages we are hinting.
2. Remove the page set entirely from the buddy. (This is what I am doing
right now)

The reason I would prefer the second approach is that we are not
blocking the allocation in any way and as we are only working with a
smaller set of pages we should be fine.
However, with the current approach as we are reporting asynchronously
there is a chance that we end up hinting more than 2-3 times for a
single workload run. In situation where this could lead to low memory
condition in the guest, the hinting will anyways fail as the guest will
not allow page isolation.
I can possibly try and test the same to ensure that we don't get OOM due
to hinting when the guest is under memory pressure.


>
>>> Then we can have that one thread just walking
>>> through the zone memory pulling out fixed size pieces at a time and
>>> providing hints on that. By doing that we avoid the potential of
>>> creating a batch of pages that eat up most of the system memory.
>>>
>>>>         * Pages, captured in the per cpu array are sorted based on the zone numbers. This is to avoid redundancy of acquiring zone locks.
>>>>         * Dynamically allocated space is used to hold the isolated guest free pages.
>>> I have concerns that doing this per CPU and allocating memory
>>> dynamically can result in you losing a significant amount of memory as
>>> it sits waiting to be hinted.
>> It should not as the buddy will keep merging the pages and we are only
>> capturing MAX_ORDER - 1.
>> This was the issue with the last patch-series when I was capturing all
>> order pages resulting in the per-cpu array to be filled with lower order
>> pages.
>>>>         * All the pages are reported asynchronously to the host via virtio driver.
>>>>         * Pages are returned back to the guest buddy free list only when the host response is received.
>>> I have been thinking about this. Instead of stealing the page couldn't
>>> you simply flag it that there is a hint in progress and simply wait in
>>> arch_alloc_page until the hint has been processed?
>> With the flag, I am assuming you mean to block the allocation until
>> hinting is going on, which is an issue. That was one of the issues
>> discussed earlier which I wanted to solve with this implementation.
> With the flag we would allow the allocation, but would have to
> synchronize with the hinting at that point. I got the idea from the
> way the s390 code works. They have both an arch_free_page and an
> arch_alloc_page. If I understand correctly the arch_alloc_page is what
> is meant to handle the case of a page that has been marked for
> hinting, but may not have been hinted on yet. My thought for now is to
> keep it simple and use a page flag to indicate that a page is
> currently pending a hint. 
I am assuming this page flag will be located in the page structure.
> We should be able to spin in such a case and
> it would probably still perform better than a solution where we would
> not have the memory available and possibly be under memory pressure.
I had this same idea earlier. However, the thing about which I was not
sure is if adding a flag in the page structure will be acceptable upstream.
>
>>> The problem is in
>>> stealing pages you are going to introduce false OOM issues when the
>>> memory isn't available because it is being hinted on.
>> I think this situation will arise when the guest is under memory
>> pressure. In such situations any attempt to perform isolation will
>> anyways fail and we may not be reporting anything at that time.
> What I want to avoid is the scenario where an application grabs a
> large amount of memory, then frees said memory, and we are sitting on
> it for some time because we decide to try and hint on the large chunk.
I agree.
> By processing this sometime after the pages are sent to the buddy
> allocator in a separate thread, and by processing a small fixed window
> of memory at a time we can avoid making freeing memory expensive, and
> still provide the hints in a reasonable time frame.

My impression is that the current window on which I am working may give
issues for smaller size guests. But otherwise, we are already working
with a smaller fixed window of memory.

I can further restrict this to just 128 entries and test which would
bring down the window of memory. Let me know what you think.

>
>>>> Pending items:
>>>>         * Make sure that the guest free page hinting's current implementation doesn't break hugepages or device assigned guests.
>>>>         * Follow up on VIRTIO_BALLOON_F_PAGE_POISON's device side support. (It is currently missing)
>>>>         * Compare reporting free pages via vring with vhost.
>>>>         * Decide between MADV_DONTNEED and MADV_FREE.
>>>>         * Analyze overall performance impact due to guest free page hinting.
>>>>         * Come up with proper/traceable error-message/logs.
>>> I'll try applying these patches and see if I can reproduce the results
>>> you reported.
>> Thanks. Let me know if you run into any issues.
>>> With the last patch set I couldn't reproduce the results
>>> as you reported them.
>> If I remember correctly then the last time you only tried with multiple
>> vcpus and not with 1 vcpu.
> I had tried 1 vcpu, however I ended up running into some other issues
> that made it difficult to even boot the system last week.
>
>>> It has me wondering if you were somehow seeing
>>> the effects of a balloon instead of the actual memory hints as I
>>> couldn't find any evidence of the memory ever actually being freed
>>> back by the hints functionality.
>> Can you please elaborate what kind of evidence you are looking for?
>>
>> I did trace the hints on the QEMU/host side.
> It looks like the new patches are working as I am seeing the memory
> freeing occurring this time around. Although it looks like this is
> still generating traces from free_pcpages_bulk if I enable multiple
> VCPUs:
I am assuming with the changes you suggested you were able to run this
patch-series. Is that correct?
>
> [  175.823539] list_add corruption. next->prev should be prev
> (ffff947c7ffd61e0), but was ffffc7a29f9e0008. (next=ffffc7a29f4c0008).
> [  175.825978] ------------[ cut here ]------------
> [  175.826889] kernel BUG at lib/list_debug.c:25!
> [  175.827766] invalid opcode: 0000 [#1] SMP PTI
> [  175.828621] CPU: 5 PID: 1344 Comm: page_fault1_thr Not tainted
> 5.0.0-next-20190306-baseline+ #76
> [  175.830312] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
> BIOS Bochs 01/01/2011
> [  175.831885] RIP: 0010:__list_add_valid+0x35/0x70
> [  175.832784] Code: 18 48 8b 32 48 39 f0 75 39 48 39 c7 74 1e 48 39
> fa 74 19 b8 01 00 00 00 c3 48 89 c1 48 c7 c7 80 b5 0f a9 31 c0 e8 8f
> aa c8 ff <0f> 0b 48 89 c1 48 89 fe 31 c0 48 c7 c7 30 b6 0f a9 e8 79 aa
> c8 ff
> [  175.836379] RSP: 0018:ffffa717c40839b0 EFLAGS: 00010046
> [  175.837394] RAX: 0000000000000075 RBX: ffff947c7ffd61e0 RCX: 0000000000000000
> [  175.838779] RDX: 0000000000000000 RSI: ffff947c5f957188 RDI: ffff947c5f957188
> [  175.840162] RBP: ffff947c7ffd61d0 R08: 000000000000026f R09: 0000000000000005
> [  175.841539] R10: 0000000000000000 R11: ffffa717c4083730 R12: ffffc7a29f260008
> [  175.842932] R13: ffff947c7ffd5d00 R14: ffffc7a29f4c0008 R15: ffffc7a29f260000
> [  175.844319] FS:  0000000000000000(0000) GS:ffff947c5f940000(0000)
> knlGS:0000000000000000
> [  175.845896] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [  175.847009] CR2: 00007fffe3421000 CR3: 000000051220e006 CR4: 0000000000160ee0
> [  175.848390] Call Trace:
> [  175.848896]  free_pcppages_bulk+0x4bc/0x6a0
> [  175.849723]  free_unref_page_list+0x10d/0x190
> [  175.850567]  release_pages+0x103/0x4a0
> [  175.851313]  tlb_flush_mmu_free+0x36/0x50
> [  175.852105]  unmap_page_range+0x963/0xd50
> [  175.852897]  unmap_vmas+0x62/0xc0
> [  175.853549]  exit_mmap+0xb5/0x1a0
> [  175.854205]  mmput+0x5b/0x120
> [  175.854794]  do_exit+0x273/0xc30
> [  175.855426]  ? free_unref_page_commit+0x85/0xf0
> [  175.856312]  do_group_exit+0x39/0xa0
> [  175.857018]  get_signal+0x172/0x7c0
> [  175.857703]  do_signal+0x36/0x620
> [  175.858355]  ? percpu_counter_add_batch+0x4b/0x60
> [  175.859280]  ? __do_munmap+0x288/0x390
> [  175.860020]  exit_to_usermode_loop+0x4c/0xa8
> [  175.860859]  do_syscall_64+0x152/0x170
> [  175.861595]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
> [  175.862586] RIP: 0033:0x7ffff76a8ec7
> [  175.863292] Code: Bad RIP value.
> [  175.863928] RSP: 002b:00007ffff4422eb8 EFLAGS: 00000212 ORIG_RAX:
> 000000000000000b
> [  175.865396] RAX: 0000000000000000 RBX: 00007ffff7ff7280 RCX: 00007ffff76a8ec7
> [  175.866799] RDX: 00007fffe3422000 RSI: 0000000008000000 RDI: 00007fffdb422000
> [  175.868194] RBP: 0000000000001000 R08: ffffffffffffffff R09: 0000000000000000
> [  175.869582] R10: 0000000000000022 R11: 0000000000000212 R12: 00007ffff4422fc0
> [  175.870984] R13: 0000000000000001 R14: 00007fffffffc1b0 R15: 00007ffff44239c0
> [  175.872350] Modules linked in: ip6t_rpfilter ip6t_REJECT
> nf_reject_ipv6 xt_conntrack ip_set nfnetlink ebtable_nat
> ebtable_broute bridge stp llc ip6table_nat ip6table_mangle
> ip6table_raw ip6table_security iptable_nat nf_nat nf_conntrack
> nf_defrag_ipv6 nf_defrag_ipv4 iptable_mangle iptable_raw
> iptable_security ebtable_filter ebtables ip6table_filter ip6_tables
> sunrpc sb_edac crct10dif_pclmul crc32_pclmul ghash_clmulni_intel
> kvm_intel kvm ppdev irqbypass parport_pc parport virtio_balloon pcspkr
> i2c_piix4 joydev xfs libcrc32c cirrus drm_kms_helper ttm drm e1000
> crc32c_intel virtio_blk serio_raw ata_generic floppy pata_acpi
> qemu_fw_cfg
> [  175.883153] ---[ end trace 5b67f12a67d1f373 ]---
>
> I should be able to rebuild the kernels/qemu and test this patch set
> over the next day or two.
Thanks.
>
> Thanks.
>
> - Alex
-- 
Regards
Nitesh


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [RFC][Patch v9 3/6] KVM: Enables the kernel to report isolated pages

[Nitesh Narayan Lal]

[-- Attachment #1.1: Type: text/plain, Size: 10580 bytes --]


On 3/6/19 4:30 PM, Alexander Duyck wrote:
> On Wed, Mar 6, 2019 at 7:51 AM Nitesh Narayan Lal <nitesh@redhat.com> wrote:
>> This patch enables the kernel to report the isolated pages
>> to the host via virtio balloon driver.
>> In order to do so a new virtuqeue (hinting_vq) is added to the
>> virtio balloon driver. As the host responds back after freeing
>> the pages, all the isolated pages are returned back to the buddy
>> via __free_one_page().
>>
>> Signed-off-by: Nitesh Narayan Lal <nitesh@redhat.com>
> I ran into a few build issues due to this patch. Comments below.
>
>> ---
>>  drivers/virtio/virtio_balloon.c     | 72 ++++++++++++++++++++++++++++-
>>  include/linux/page_hinting.h        |  4 ++
>>  include/uapi/linux/virtio_balloon.h |  8 ++++
>>  virt/kvm/page_hinting.c             | 18 ++++++--
>>  4 files changed, 98 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
>> index 728ecd1eea30..cfe7574b5204 100644
>> --- a/drivers/virtio/virtio_balloon.c
>> +++ b/drivers/virtio/virtio_balloon.c
>> @@ -57,13 +57,15 @@ enum virtio_balloon_vq {
>>         VIRTIO_BALLOON_VQ_INFLATE,
>>         VIRTIO_BALLOON_VQ_DEFLATE,
>>         VIRTIO_BALLOON_VQ_STATS,
>> +       VIRTIO_BALLOON_VQ_HINTING,
>>         VIRTIO_BALLOON_VQ_FREE_PAGE,
>>         VIRTIO_BALLOON_VQ_MAX
>>  };
>>
>>  struct virtio_balloon {
>>         struct virtio_device *vdev;
>> -       struct virtqueue *inflate_vq, *deflate_vq, *stats_vq, *free_page_vq;
>> +       struct virtqueue *inflate_vq, *deflate_vq, *stats_vq, *free_page_vq,
>> +                                                               *hinting_vq;
>>
>>         /* Balloon's own wq for cpu-intensive work items */
>>         struct workqueue_struct *balloon_wq;
>> @@ -122,6 +124,56 @@ static struct virtio_device_id id_table[] = {
>>         { 0 },
>>  };
>>
>> +#ifdef CONFIG_KVM_FREE_PAGE_HINTING
>> +int virtballoon_page_hinting(struct virtio_balloon *vb,
>> +                            void *hinting_req,
>> +                            int entries)
>> +{
>> +       struct scatterlist sg;
>> +       struct virtqueue *vq = vb->hinting_vq;
>> +       int err;
>> +       int unused;
>> +       struct virtio_balloon_hint_req *hint_req;
>> +       u64 gpaddr;
>> +
>> +       hint_req = kmalloc(sizeof(struct virtio_balloon_hint_req), GFP_KERNEL);
>> +       while (virtqueue_get_buf(vq, &unused))
>> +               ;
>> +
>> +       gpaddr = virt_to_phys(hinting_req);
>> +       hint_req->phys_addr = cpu_to_virtio64(vb->vdev, gpaddr);
>> +       hint_req->count = cpu_to_virtio32(vb->vdev, entries);
>> +       sg_init_one(&sg, hint_req, sizeof(struct virtio_balloon_hint_req));
>> +       err = virtqueue_add_outbuf(vq, &sg, 1, hint_req, GFP_KERNEL);
>> +       if (!err)
>> +               virtqueue_kick(vb->hinting_vq);
>> +       else
>> +               kfree(hint_req);
>> +       return err;
>> +}
>> +
>> +static void hinting_ack(struct virtqueue *vq)
>> +{
>> +       int len = sizeof(struct virtio_balloon_hint_req);
>> +       struct virtio_balloon_hint_req *hint_req = virtqueue_get_buf(vq, &len);
>> +       void *v_addr = phys_to_virt(hint_req->phys_addr);
>> +
>> +       release_buddy_pages(v_addr, hint_req->count);
>> +       kfree(hint_req);
>> +}
>> +
> You use release_buddy_pages here, but never exported it in the call
> down below. Since this can be built as a module and I believe the page
> hinting can be built either into the kernel or as a seperate module
> shouldn't you be exporting it?
Thanks for pointing this out.
>
>> +static void enable_hinting(struct virtio_balloon *vb)
>> +{
>> +       request_hypercall = (void *)&virtballoon_page_hinting;
>> +       balloon_ptr = vb;
>> +}
>> +
>> +static void disable_hinting(void)
>> +{
>> +       balloon_ptr = NULL;
>> +}
>> +#endif
>> +
>>  static u32 page_to_balloon_pfn(struct page *page)
>>  {
>>         unsigned long pfn = page_to_pfn(page);
>> @@ -481,6 +533,7 @@ static int init_vqs(struct virtio_balloon *vb)
>>         names[VIRTIO_BALLOON_VQ_DEFLATE] = "deflate";
>>         names[VIRTIO_BALLOON_VQ_STATS] = NULL;
>>         names[VIRTIO_BALLOON_VQ_FREE_PAGE] = NULL;
>> +       names[VIRTIO_BALLOON_VQ_HINTING] = NULL;
>>
>>         if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_STATS_VQ)) {
>>                 names[VIRTIO_BALLOON_VQ_STATS] = "stats";
>> @@ -492,11 +545,18 @@ static int init_vqs(struct virtio_balloon *vb)
>>                 callbacks[VIRTIO_BALLOON_VQ_FREE_PAGE] = NULL;
>>         }
>>
>> +       if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_HINTING)) {
>> +               names[VIRTIO_BALLOON_VQ_HINTING] = "hinting_vq";
>> +               callbacks[VIRTIO_BALLOON_VQ_HINTING] = hinting_ack;
>> +       }
>>         err = vb->vdev->config->find_vqs(vb->vdev, VIRTIO_BALLOON_VQ_MAX,
>>                                          vqs, callbacks, names, NULL, NULL);
>>         if (err)
>>                 return err;
>>
>> +       if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_HINTING))
>> +               vb->hinting_vq = vqs[VIRTIO_BALLOON_VQ_HINTING];
>> +
>>         vb->inflate_vq = vqs[VIRTIO_BALLOON_VQ_INFLATE];
>>         vb->deflate_vq = vqs[VIRTIO_BALLOON_VQ_DEFLATE];
>>         if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_STATS_VQ)) {
>> @@ -908,6 +968,11 @@ static int virtballoon_probe(struct virtio_device *vdev)
>>                 if (err)
>>                         goto out_del_balloon_wq;
>>         }
>> +
>> +#ifdef CONFIG_KVM_FREE_PAGE_HINTING
>> +       if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_HINTING))
>> +               enable_hinting(vb);
>> +#endif
>>         virtio_device_ready(vdev);
>>
>>         if (towards_target(vb))
>> @@ -950,6 +1015,10 @@ static void virtballoon_remove(struct virtio_device *vdev)
>>         cancel_work_sync(&vb->update_balloon_size_work);
>>         cancel_work_sync(&vb->update_balloon_stats_work);
>>
>> +#ifdef CONFIG_KVM_FREE_PAGE_HINTING
>> +       if (virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_HINTING))
>> +               disable_hinting();
>> +#endif
>>         if (virtio_has_feature(vdev, VIRTIO_BALLOON_F_FREE_PAGE_HINT)) {
>>                 cancel_work_sync(&vb->report_free_page_work);
>>                 destroy_workqueue(vb->balloon_wq);
>> @@ -1009,6 +1078,7 @@ static unsigned int features[] = {
>>         VIRTIO_BALLOON_F_MUST_TELL_HOST,
>>         VIRTIO_BALLOON_F_STATS_VQ,
>>         VIRTIO_BALLOON_F_DEFLATE_ON_OOM,
>> +       VIRTIO_BALLOON_F_HINTING,
>>         VIRTIO_BALLOON_F_FREE_PAGE_HINT,
>>         VIRTIO_BALLOON_F_PAGE_POISON,
>>  };
>> diff --git a/include/linux/page_hinting.h b/include/linux/page_hinting.h
>> index d554a2581826..a32af8851081 100644
>> --- a/include/linux/page_hinting.h
>> +++ b/include/linux/page_hinting.h
>> @@ -11,6 +11,8 @@
>>  #define HINTING_THRESHOLD      128
>>  #define FREE_PAGE_HINTING_MIN_ORDER    (MAX_ORDER - 1)
>>
>> +extern void *balloon_ptr;
>> +
>>  void guest_free_page_enqueue(struct page *page, int order);
>>  void guest_free_page_try_hinting(void);
>>  extern int __isolate_free_page(struct page *page, unsigned int order);
>> @@ -18,3 +20,5 @@ extern void __free_one_page(struct page *page, unsigned long pfn,
>>                             struct zone *zone, unsigned int order,
>>                             int migratetype);
>>  void release_buddy_pages(void *obj_to_free, int entries);
>> +extern int (*request_hypercall)(void *balloon_ptr,
>> +                               void *hinting_req, int entries);
>> diff --git a/include/uapi/linux/virtio_balloon.h b/include/uapi/linux/virtio_balloon.h
>> index a1966cd7b677..a7e909d77447 100644
>> --- a/include/uapi/linux/virtio_balloon.h
>> +++ b/include/uapi/linux/virtio_balloon.h
>> @@ -29,6 +29,7 @@
>>  #include <linux/virtio_types.h>
>>  #include <linux/virtio_ids.h>
>>  #include <linux/virtio_config.h>
>> +#include <linux/page_hinting.h>
>>
>>  /* The feature bitmap for virtio balloon */
>>  #define VIRTIO_BALLOON_F_MUST_TELL_HOST        0 /* Tell before reclaiming pages */
> So I am pretty sure that this isn't valid. You have a file in
> include/uapi/linux referencing one in include/linux. As such when the
> userspace headers are built off of this they cannot access the kernel
> include file.
>
>> @@ -36,6 +37,7 @@
>>  #define VIRTIO_BALLOON_F_DEFLATE_ON_OOM        2 /* Deflate balloon on OOM */
>>  #define VIRTIO_BALLOON_F_FREE_PAGE_HINT        3 /* VQ to report free pages */
>>  #define VIRTIO_BALLOON_F_PAGE_POISON   4 /* Guest is using page poisoning */
>> +#define VIRTIO_BALLOON_F_HINTING       5 /* Page hinting virtqueue */
>>
>>  /* Size of a PFN in the balloon interface. */
>>  #define VIRTIO_BALLOON_PFN_SHIFT 12
>> @@ -108,4 +110,10 @@ struct virtio_balloon_stat {
>>         __virtio64 val;
>>  } __attribute__((packed));
>>
>> +#ifdef CONFIG_KVM_FREE_PAGE_HINTING
>> +struct virtio_balloon_hint_req {
>> +       __virtio64 phys_addr;
>> +       __virtio64 count;
>> +};
>> +#endif
>>  #endif /* _LINUX_VIRTIO_BALLOON_H */
>> diff --git a/virt/kvm/page_hinting.c b/virt/kvm/page_hinting.c
>> index 9885b372b5a9..eb0c0ddfe990 100644
>> --- a/virt/kvm/page_hinting.c
>> +++ b/virt/kvm/page_hinting.c
>> @@ -31,11 +31,16 @@ struct guest_isolated_pages {
>>         unsigned int order;
>>  };
>>
>> -void release_buddy_pages(void *obj_to_free, int entries)
>> +int (*request_hypercall)(void *balloon_ptr, void *hinting_req, int entries);
>> +EXPORT_SYMBOL(request_hypercall);
>> +void *balloon_ptr;
>> +EXPORT_SYMBOL(balloon_ptr);
>> +
> Why are you using a standard EXPORT_SYMBOL here instead of
> EXPORT_SYMBOL_GPL? It seems like these are core functions that can
> impact the memory allocator. It might make more sense to use
> EXPORT_SYMBOL_GPL.
>
>> +void release_buddy_pages(void *hinting_req, int entries)
>>  {
>>         int i = 0;
>>         int mt = 0;
>> -       struct guest_isolated_pages *isolated_pages_obj = obj_to_free;
>> +       struct guest_isolated_pages *isolated_pages_obj = hinting_req;
>>
>>         while (i < entries) {
>>                 struct page *page = pfn_to_page(isolated_pages_obj[i].pfn);
> See my comment above, I am pretty sure you need to be exporting this.
> I had to change this in order to be able to build.
Thanks, I will take note and correct it in the next version.
-- 
Regards
Nitesh


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [RFC][Patch v9 2/6] KVM: Enables the kernel to isolate guest free pages

[Alexander Duyck]

On Wed, Mar 6, 2019 at 7:51 AM Nitesh Narayan Lal <nitesh@redhat.com> wrote:
>
> This patch enables the kernel to scan the per cpu array
> which carries head pages from the buddy free list of order
> FREE_PAGE_HINTING_MIN_ORDER (MAX_ORDER - 1) by
> guest_free_page_hinting().
> guest_free_page_hinting() scans the entire per cpu array by
> acquiring a zone lock corresponding to the pages which are
> being scanned. If the page is still free and present in the
> buddy it tries to isolate the page and adds it to a
> dynamically allocated array.
>
> Once this scanning process is complete and if there are any
> isolated pages added to the dynamically allocated array
> guest_free_page_report() is invoked. However, before this the
> per-cpu array index is reset so that it can continue capturing
> the pages from buddy free list.
>
> In this patch guest_free_page_report() simply releases the pages back
> to the buddy by using __free_one_page()
>
> Signed-off-by: Nitesh Narayan Lal <nitesh@redhat.com>

I'm pretty sure this code is not thread safe and has a few various issues.

> ---
>  include/linux/page_hinting.h |   5 ++
>  mm/page_alloc.c              |   2 +-
>  virt/kvm/page_hinting.c      | 154 +++++++++++++++++++++++++++++++++++
>  3 files changed, 160 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/page_hinting.h b/include/linux/page_hinting.h
> index 90254c582789..d554a2581826 100644
> --- a/include/linux/page_hinting.h
> +++ b/include/linux/page_hinting.h
> @@ -13,3 +13,8 @@
>
>  void guest_free_page_enqueue(struct page *page, int order);
>  void guest_free_page_try_hinting(void);
> +extern int __isolate_free_page(struct page *page, unsigned int order);
> +extern void __free_one_page(struct page *page, unsigned long pfn,
> +                           struct zone *zone, unsigned int order,
> +                           int migratetype);
> +void release_buddy_pages(void *obj_to_free, int entries);
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 684d047f33ee..d38b7eea207b 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -814,7 +814,7 @@ static inline int page_is_buddy(struct page *page, struct page *buddy,
>   * -- nyc
>   */
>
> -static inline void __free_one_page(struct page *page,
> +inline void __free_one_page(struct page *page,
>                 unsigned long pfn,
>                 struct zone *zone, unsigned int order,
>                 int migratetype)
> diff --git a/virt/kvm/page_hinting.c b/virt/kvm/page_hinting.c
> index 48b4b5e796b0..9885b372b5a9 100644
> --- a/virt/kvm/page_hinting.c
> +++ b/virt/kvm/page_hinting.c
> @@ -1,5 +1,9 @@
>  #include <linux/mm.h>
>  #include <linux/page_hinting.h>
> +#include <linux/page_ref.h>
> +#include <linux/kvm_host.h>
> +#include <linux/kernel.h>
> +#include <linux/sort.h>
>
>  /*
>   * struct guest_free_pages- holds array of guest freed PFN's along with an
> @@ -16,6 +20,54 @@ struct guest_free_pages {
>
>  DEFINE_PER_CPU(struct guest_free_pages, free_pages_obj);
>
> +/*
> + * struct guest_isolated_pages- holds the buddy isolated pages which are
> + * supposed to be freed by the host.
> + * @pfn: page frame number for the isolated page.
> + * @order: order of the isolated page.
> + */
> +struct guest_isolated_pages {
> +       unsigned long pfn;
> +       unsigned int order;
> +};
> +
> +void release_buddy_pages(void *obj_to_free, int entries)
> +{
> +       int i = 0;
> +       int mt = 0;
> +       struct guest_isolated_pages *isolated_pages_obj = obj_to_free;
> +
> +       while (i < entries) {
> +               struct page *page = pfn_to_page(isolated_pages_obj[i].pfn);
> +
> +               mt = get_pageblock_migratetype(page);
> +               __free_one_page(page, page_to_pfn(page), page_zone(page),
> +                               isolated_pages_obj[i].order, mt);
> +               i++;
> +       }
> +       kfree(isolated_pages_obj);
> +}

You shouldn't be accessing __free_one_page without holding the zone
lock for the page. You might consider confining yourself to one zone
worth of hints at a time. Then you can acquire the lock once, and then
return the memory you have freed.

This is one of the reasons why I am thinking maybe a bit in the page
and then spinning on that bit in arch_alloc_page might be a nice way
to get around this. Then you only have to take the zone lock when you
are finding the pages you want to hint on and setting the bit
indicating they are mid hint. Otherwise you have to take the zone lock
to pull pages out, and to put them back in and the likelihood of a
lock collision is much higher.

> +
> +void guest_free_page_report(struct guest_isolated_pages *isolated_pages_obj,
> +                           int entries)
> +{
> +       release_buddy_pages(isolated_pages_obj, entries);
> +}
> +
> +static int sort_zonenum(const void *a1, const void *b1)
> +{
> +       const unsigned long *a = a1;
> +       const unsigned long *b = b1;
> +
> +       if (page_zonenum(pfn_to_page(a[0])) > page_zonenum(pfn_to_page(b[0])))
> +               return 1;
> +
> +       if (page_zonenum(pfn_to_page(a[0])) < page_zonenum(pfn_to_page(b[0])))
> +               return -1;
> +
> +       return 0;
> +}
> +
>  struct page *get_buddy_page(struct page *page)
>  {
>         unsigned long pfn = page_to_pfn(page);
> @@ -33,9 +85,111 @@ struct page *get_buddy_page(struct page *page)
>  static void guest_free_page_hinting(void)
>  {
>         struct guest_free_pages *hinting_obj = &get_cpu_var(free_pages_obj);
> +       struct guest_isolated_pages *isolated_pages_obj;
> +       int idx = 0, ret = 0;
> +       struct zone *zone_cur, *zone_prev;
> +       unsigned long flags = 0;
> +       int hyp_idx = 0;
> +       int free_pages_idx = hinting_obj->free_pages_idx;
> +
> +       isolated_pages_obj = kmalloc(MAX_FGPT_ENTRIES *
> +                       sizeof(struct guest_isolated_pages), GFP_KERNEL);
> +       if (!isolated_pages_obj) {
> +               hinting_obj->free_pages_idx = 0;
> +               put_cpu_var(hinting_obj);
> +               return;
> +               /* return some logical error here*/
> +       }
> +
> +       sort(hinting_obj->free_page_arr, free_pages_idx,
> +            sizeof(unsigned long), sort_zonenum, NULL);
> +
> +       while (idx < free_pages_idx) {
> +               unsigned long pfn = hinting_obj->free_page_arr[idx];
> +               unsigned long pfn_end = hinting_obj->free_page_arr[idx] +
> +                       (1 << FREE_PAGE_HINTING_MIN_ORDER) - 1;
> +
> +               zone_cur = page_zone(pfn_to_page(pfn));
> +               if (idx == 0) {
> +                       zone_prev = zone_cur;
> +                       spin_lock_irqsave(&zone_cur->lock, flags);
> +               } else if (zone_prev != zone_cur) {
> +                       spin_unlock_irqrestore(&zone_prev->lock, flags);
> +                       spin_lock_irqsave(&zone_cur->lock, flags);
> +                       zone_prev = zone_cur;
> +               }
> +
> +               while (pfn <= pfn_end) {
> +                       struct page *page = pfn_to_page(pfn);
> +                       struct page *buddy_page = NULL;
> +
> +                       if (PageCompound(page)) {
> +                               struct page *head_page = compound_head(page);
> +                               unsigned long head_pfn = page_to_pfn(head_page);
> +                               unsigned int alloc_pages =
> +                                       1 << compound_order(head_page);
> +
> +                               pfn = head_pfn + alloc_pages;
> +                               continue;
> +                       }
> +

I don't think the buddy allocator has compound pages.

> +                       if (page_ref_count(page)) {
> +                               pfn++;
> +                               continue;
> +                       }
> +

A ref count of 0 doesn't mean the page isn't in use. It could be in
use by something such as SLUB for instance.

> +                       if (PageBuddy(page) && page_private(page) >=
> +                           FREE_PAGE_HINTING_MIN_ORDER) {
> +                               int buddy_order = page_private(page);
> +
> +                               ret = __isolate_free_page(page, buddy_order);
> +                               if (ret) {
> +                                       isolated_pages_obj[hyp_idx].pfn = pfn;
> +                                       isolated_pages_obj[hyp_idx].order =
> +                                                               buddy_order;
> +                                       hyp_idx += 1;
> +                               }
> +                               pfn = pfn + (1 << buddy_order);
> +                               continue;
> +                       }
> +

So this is where things start to get ugly. Basically because we were
acquiring the hints when they were freed we end up needing to check
either this page, and the PFN for all of the higher order pages this
page could be a part of. Since we are currently limiting ourselves to
MAX_ORDER - 1 it shouldn't be too expensive. I don't recall if your
get_buddy_page already had that limitation coded in but we should
probably look at doing that there. Then we can just skip the PageBuddy
check up here and have it automatically start walking all pages your
original page could be a part of looking for the highest page order
that might still be free.

> +                       buddy_page = get_buddy_page(page);
> +                       if (buddy_page && page_private(buddy_page) >=
> +                           FREE_PAGE_HINTING_MIN_ORDER) {
> +                               int buddy_order = page_private(buddy_page);
> +
> +                               ret = __isolate_free_page(buddy_page,
> +                                                         buddy_order);
> +                               if (ret) {
> +                                       unsigned long buddy_pfn =
> +                                               page_to_pfn(buddy_page);
> +
> +                                       isolated_pages_obj[hyp_idx].pfn =
> +                                                               buddy_pfn;
> +                                       isolated_pages_obj[hyp_idx].order =
> +                                                               buddy_order;
> +                                       hyp_idx += 1;
> +                               }
> +                               pfn = page_to_pfn(buddy_page) +
> +                                       (1 << buddy_order);
> +                               continue;
> +                       }

This is essentially just a duplicate of the code above. As I mentioned
before it would probably make sense to just combine this block with
that one.

> +                       pfn++;
> +               }
> +               hinting_obj->free_page_arr[idx] = 0;
> +               idx++;
> +               if (idx == free_pages_idx)
> +                       spin_unlock_irqrestore(&zone_cur->lock, flags);
> +       }
>
>         hinting_obj->free_pages_idx = 0;
>         put_cpu_var(hinting_obj);
> +
> +       if (hyp_idx > 0)
> +               guest_free_page_report(isolated_pages_obj, hyp_idx);
> +       else
> +               kfree(isolated_pages_obj);
> +               /* return some logical error here*/
>  }
>
>  int if_exist(struct page *page)
> --
> 2.17.2
>

Re: [RFC][Patch v9 0/6] KVM: Guest Free Page Hinting

[Alexander Duyck]

On Thu, Mar 7, 2019 at 5:09 AM Nitesh Narayan Lal <nitesh@redhat.com> wrote:
>
>
> On 3/6/19 5:05 PM, Alexander Duyck wrote:
> > On Wed, Mar 6, 2019 at 11:07 AM Nitesh Narayan Lal <nitesh@redhat.com> wrote:
> >>
> >> On 3/6/19 1:00 PM, Alexander Duyck wrote:
> >>> On Wed, Mar 6, 2019 at 7:51 AM Nitesh Narayan Lal <nitesh@redhat.com> wrote:
> >>>> The following patch-set proposes an efficient mechanism for handing freed memory between the guest and the host. It enables the guests with no page cache to rapidly free and reclaims memory to and from the host respectively.
> >>>>
> >>>> Benefit:
> >>>> With this patch-series, in our test-case, executed on a single system and single NUMA node with 15GB memory, we were able to successfully launch 5 guests(each with 5 GB memory) when page hinting was enabled and 3 without it. (Detailed explanation of the test procedure is provided at the bottom under Test - 1).
> >>>>
> >>>> Changelog in v9:
> >>>>         * Guest free page hinting hook is now invoked after a page has been merged in the buddy.
> >>>>         * Free pages only with order FREE_PAGE_HINTING_MIN_ORDER(currently defined as MAX_ORDER - 1) are captured.
> >>>>         * Removed kthread which was earlier used to perform the scanning, isolation & reporting of free pages.
> >>> Without a kthread this has the potential to get really ugly really
> >>> fast. If we are going to run asynchronously we should probably be
> >>> truly asynchonous and just place a few pieces of data in the page that
> >>> a worker thread can use to identify which pages have been hinted and
> >>> which pages have not.
> >> Can you please explain what do you mean by truly asynchronous?
> >>
> >> With this implementation also I am not reporting the pages synchronously.
> > The problem is you are making it pseudo synchronous by having to push
> > pages off to a side buffer aren't you? In my mind we should be able to
> > have the page hinting go on with little to no interference with
> > existing page allocation and freeing.
> We have to opt one of the two options:
> 1. Block allocation by using a flag or acquire a lock to prevent the
> usage of pages we are hinting.
> 2. Remove the page set entirely from the buddy. (This is what I am doing
> right now)
>
> The reason I would prefer the second approach is that we are not
> blocking the allocation in any way and as we are only working with a
> smaller set of pages we should be fine.
> However, with the current approach as we are reporting asynchronously
> there is a chance that we end up hinting more than 2-3 times for a
> single workload run. In situation where this could lead to low memory
> condition in the guest, the hinting will anyways fail as the guest will
> not allow page isolation.
> I can possibly try and test the same to ensure that we don't get OOM due
> to hinting when the guest is under memory pressure.

So in either case you are essentially blocking allocation since the
memory cannot be used. My concern is more with guaranteeing forward
progress for as many CPUs as possible.

With your current design you have one minor issue in that you aren't
taking the lock to re-insert the pages back into the buddy allocator.
When you add that step in it means you are going to be blocking
allocation on that zone while you are reinserting the pages.

Also right now you are using the calls to free_one_page to generate a
list of hints where to search. I'm thinking that may not be the best
approach since what we want to do is provide hints on idle free pages,
not just pages that will be free for a short period of time.

To that end what I think w may want to do is instead just walk the LRU
list for a given zone/order in reverse order so that we can try to
identify the pages that are most likely to be cold and unused and
those are the first ones we want to be hinting on rather than the ones
that were just freed. If we can look at doing something like adding a
jiffies value to the page indicating when it was last freed we could
even have a good point for determining when we should stop processing
pages in a given zone/order list.

In reality the approach wouldn't be too different from what you are
doing now, the only real difference would be that we would just want
to walk the LRU list for the given zone/order rather then pulling
hints on what to free from the calls to free_one_page. In addition we
would need to add a couple bits to indicate if the page has been
hinted on, is in the middle of getting hinted on, and something such
as the jiffies value I mentioned which we could use to determine how
old the page is.

> >
> >>> Then we can have that one thread just walking
> >>> through the zone memory pulling out fixed size pieces at a time and
> >>> providing hints on that. By doing that we avoid the potential of
> >>> creating a batch of pages that eat up most of the system memory.
> >>>
> >>>>         * Pages, captured in the per cpu array are sorted based on the zone numbers. This is to avoid redundancy of acquiring zone locks.
> >>>>         * Dynamically allocated space is used to hold the isolated guest free pages.
> >>> I have concerns that doing this per CPU and allocating memory
> >>> dynamically can result in you losing a significant amount of memory as
> >>> it sits waiting to be hinted.
> >> It should not as the buddy will keep merging the pages and we are only
> >> capturing MAX_ORDER - 1.
> >> This was the issue with the last patch-series when I was capturing all
> >> order pages resulting in the per-cpu array to be filled with lower order
> >> pages.
> >>>>         * All the pages are reported asynchronously to the host via virtio driver.
> >>>>         * Pages are returned back to the guest buddy free list only when the host response is received.
> >>> I have been thinking about this. Instead of stealing the page couldn't
> >>> you simply flag it that there is a hint in progress and simply wait in
> >>> arch_alloc_page until the hint has been processed?
> >> With the flag, I am assuming you mean to block the allocation until
> >> hinting is going on, which is an issue. That was one of the issues
> >> discussed earlier which I wanted to solve with this implementation.
> > With the flag we would allow the allocation, but would have to
> > synchronize with the hinting at that point. I got the idea from the
> > way the s390 code works. They have both an arch_free_page and an
> > arch_alloc_page. If I understand correctly the arch_alloc_page is what
> > is meant to handle the case of a page that has been marked for
> > hinting, but may not have been hinted on yet. My thought for now is to
> > keep it simple and use a page flag to indicate that a page is
> > currently pending a hint.
> I am assuming this page flag will be located in the page structure.
> > We should be able to spin in such a case and
> > it would probably still perform better than a solution where we would
> > not have the memory available and possibly be under memory pressure.
> I had this same idea earlier. However, the thing about which I was not
> sure is if adding a flag in the page structure will be acceptable upstream.
> >
> >>> The problem is in
> >>> stealing pages you are going to introduce false OOM issues when the
> >>> memory isn't available because it is being hinted on.
> >> I think this situation will arise when the guest is under memory
> >> pressure. In such situations any attempt to perform isolation will
> >> anyways fail and we may not be reporting anything at that time.
> > What I want to avoid is the scenario where an application grabs a
> > large amount of memory, then frees said memory, and we are sitting on
> > it for some time because we decide to try and hint on the large chunk.
> I agree.
> > By processing this sometime after the pages are sent to the buddy
> > allocator in a separate thread, and by processing a small fixed window
> > of memory at a time we can avoid making freeing memory expensive, and
> > still provide the hints in a reasonable time frame.
>
> My impression is that the current window on which I am working may give
> issues for smaller size guests. But otherwise, we are already working
> with a smaller fixed window of memory.
>
> I can further restrict this to just 128 entries and test which would
> bring down the window of memory. Let me know what you think.

The problem is 128 entries is still pretty big when you consider you
are working with 4M pages. If I am not mistaken that is a half
gigabyte of memory. For lower order pages 128 would probably be fine,
but with the higher order pages we may want to contain things to
something smaller like 16MB to 64MB worth of memory.

> >
> >>>> Pending items:
> >>>>         * Make sure that the guest free page hinting's current implementation doesn't break hugepages or device assigned guests.
> >>>>         * Follow up on VIRTIO_BALLOON_F_PAGE_POISON's device side support. (It is currently missing)
> >>>>         * Compare reporting free pages via vring with vhost.
> >>>>         * Decide between MADV_DONTNEED and MADV_FREE.
> >>>>         * Analyze overall performance impact due to guest free page hinting.
> >>>>         * Come up with proper/traceable error-message/logs.
> >>> I'll try applying these patches and see if I can reproduce the results
> >>> you reported.
> >> Thanks. Let me know if you run into any issues.
> >>> With the last patch set I couldn't reproduce the results
> >>> as you reported them.
> >> If I remember correctly then the last time you only tried with multiple
> >> vcpus and not with 1 vcpu.
> > I had tried 1 vcpu, however I ended up running into some other issues
> > that made it difficult to even boot the system last week.
> >
> >>> It has me wondering if you were somehow seeing
> >>> the effects of a balloon instead of the actual memory hints as I
> >>> couldn't find any evidence of the memory ever actually being freed
> >>> back by the hints functionality.
> >> Can you please elaborate what kind of evidence you are looking for?
> >>
> >> I did trace the hints on the QEMU/host side.
> > It looks like the new patches are working as I am seeing the memory
> > freeing occurring this time around. Although it looks like this is
> > still generating traces from free_pcpages_bulk if I enable multiple
> > VCPUs:
> I am assuming with the changes you suggested you were able to run this
> patch-series. Is that correct?

Yes, I got it working by disabling SMP. I think I found and pointed
out the issue in your other patch where you were using __free_one_page
without holding the zone lock.

> >
> > [  175.823539] list_add corruption. next->prev should be prev
> > (ffff947c7ffd61e0), but was ffffc7a29f9e0008. (next=ffffc7a29f4c0008).
> > [  175.825978] ------------[ cut here ]------------
> > [  175.826889] kernel BUG at lib/list_debug.c:25!
> > [  175.827766] invalid opcode: 0000 [#1] SMP PTI
> > [  175.828621] CPU: 5 PID: 1344 Comm: page_fault1_thr Not tainted
> > 5.0.0-next-20190306-baseline+ #76
> > [  175.830312] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
> > BIOS Bochs 01/01/2011
> > [  175.831885] RIP: 0010:__list_add_valid+0x35/0x70
> > [  175.832784] Code: 18 48 8b 32 48 39 f0 75 39 48 39 c7 74 1e 48 39
> > fa 74 19 b8 01 00 00 00 c3 48 89 c1 48 c7 c7 80 b5 0f a9 31 c0 e8 8f
> > aa c8 ff <0f> 0b 48 89 c1 48 89 fe 31 c0 48 c7 c7 30 b6 0f a9 e8 79 aa
> > c8 ff
> > [  175.836379] RSP: 0018:ffffa717c40839b0 EFLAGS: 00010046
> > [  175.837394] RAX: 0000000000000075 RBX: ffff947c7ffd61e0 RCX: 0000000000000000
> > [  175.838779] RDX: 0000000000000000 RSI: ffff947c5f957188 RDI: ffff947c5f957188
> > [  175.840162] RBP: ffff947c7ffd61d0 R08: 000000000000026f R09: 0000000000000005
> > [  175.841539] R10: 0000000000000000 R11: ffffa717c4083730 R12: ffffc7a29f260008
> > [  175.842932] R13: ffff947c7ffd5d00 R14: ffffc7a29f4c0008 R15: ffffc7a29f260000
> > [  175.844319] FS:  0000000000000000(0000) GS:ffff947c5f940000(0000)
> > knlGS:0000000000000000
> > [  175.845896] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > [  175.847009] CR2: 00007fffe3421000 CR3: 000000051220e006 CR4: 0000000000160ee0
> > [  175.848390] Call Trace:
> > [  175.848896]  free_pcppages_bulk+0x4bc/0x6a0
> > [  175.849723]  free_unref_page_list+0x10d/0x190
> > [  175.850567]  release_pages+0x103/0x4a0
> > [  175.851313]  tlb_flush_mmu_free+0x36/0x50
> > [  175.852105]  unmap_page_range+0x963/0xd50
> > [  175.852897]  unmap_vmas+0x62/0xc0
> > [  175.853549]  exit_mmap+0xb5/0x1a0
> > [  175.854205]  mmput+0x5b/0x120
> > [  175.854794]  do_exit+0x273/0xc30
> > [  175.855426]  ? free_unref_page_commit+0x85/0xf0
> > [  175.856312]  do_group_exit+0x39/0xa0
> > [  175.857018]  get_signal+0x172/0x7c0
> > [  175.857703]  do_signal+0x36/0x620
> > [  175.858355]  ? percpu_counter_add_batch+0x4b/0x60
> > [  175.859280]  ? __do_munmap+0x288/0x390
> > [  175.860020]  exit_to_usermode_loop+0x4c/0xa8
> > [  175.860859]  do_syscall_64+0x152/0x170
> > [  175.861595]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
> > [  175.862586] RIP: 0033:0x7ffff76a8ec7
> > [  175.863292] Code: Bad RIP value.
> > [  175.863928] RSP: 002b:00007ffff4422eb8 EFLAGS: 00000212 ORIG_RAX:
> > 000000000000000b
> > [  175.865396] RAX: 0000000000000000 RBX: 00007ffff7ff7280 RCX: 00007ffff76a8ec7
> > [  175.866799] RDX: 00007fffe3422000 RSI: 0000000008000000 RDI: 00007fffdb422000
> > [  175.868194] RBP: 0000000000001000 R08: ffffffffffffffff R09: 0000000000000000
> > [  175.869582] R10: 0000000000000022 R11: 0000000000000212 R12: 00007ffff4422fc0
> > [  175.870984] R13: 0000000000000001 R14: 00007fffffffc1b0 R15: 00007ffff44239c0
> > [  175.872350] Modules linked in: ip6t_rpfilter ip6t_REJECT
> > nf_reject_ipv6 xt_conntrack ip_set nfnetlink ebtable_nat
> > ebtable_broute bridge stp llc ip6table_nat ip6table_mangle
> > ip6table_raw ip6table_security iptable_nat nf_nat nf_conntrack
> > nf_defrag_ipv6 nf_defrag_ipv4 iptable_mangle iptable_raw
> > iptable_security ebtable_filter ebtables ip6table_filter ip6_tables
> > sunrpc sb_edac crct10dif_pclmul crc32_pclmul ghash_clmulni_intel
> > kvm_intel kvm ppdev irqbypass parport_pc parport virtio_balloon pcspkr
> > i2c_piix4 joydev xfs libcrc32c cirrus drm_kms_helper ttm drm e1000
> > crc32c_intel virtio_blk serio_raw ata_generic floppy pata_acpi
> > qemu_fw_cfg
> > [  175.883153] ---[ end trace 5b67f12a67d1f373 ]---
> >
> > I should be able to rebuild the kernels/qemu and test this patch set
> > over the next day or two.
> Thanks.
> >
> > Thanks.
> >
> > - Alex
> --
> Regards
> Nitesh
>

Re: [RFC][Patch v9 0/6] KVM: Guest Free Page Hinting

[Michael S. Tsirkin]

On Wed, Mar 06, 2019 at 10:00:05AM -0800, Alexander Duyck wrote:
> I have been thinking about this. Instead of stealing the page couldn't
> you simply flag it that there is a hint in progress and simply wait in
> arch_alloc_page until the hint has been processed? The problem is in
> stealing pages you are going to introduce false OOM issues when the
> memory isn't available because it is being hinted on.

Can we not give them back in an OOM notifier?

-- 
MST

Re: [RFC][Patch v9 0/6] KVM: Guest Free Page Hinting

[Michael S. Tsirkin]

On Thu, Mar 07, 2019 at 10:45:58AM -0800, Alexander Duyck wrote:
> To that end what I think w may want to do is instead just walk the LRU
> list for a given zone/order in reverse order so that we can try to
> identify the pages that are most likely to be cold and unused and
> those are the first ones we want to be hinting on rather than the ones
> that were just freed. If we can look at doing something like adding a
> jiffies value to the page indicating when it was last freed we could
> even have a good point for determining when we should stop processing
> pages in a given zone/order list.
> 
> In reality the approach wouldn't be too different from what you are
> doing now, the only real difference would be that we would just want
> to walk the LRU list for the given zone/order rather then pulling
> hints on what to free from the calls to free_one_page. In addition we
> would need to add a couple bits to indicate if the page has been
> hinted on, is in the middle of getting hinted on, and something such
> as the jiffies value I mentioned which we could use to determine how
> old the page is.

Do we really need bits in the page?
Would it be bad to just have a separate hint list?

If you run out of free memory you can check the hint
list, if you find stuff there you can spin
or kick the hypervisor to hurry up.

Core mm/ changes, so nothing's easy, I know.

-- 
MST

Re: [RFC][Patch v9 2/6] KVM: Enables the kernel to isolate guest free pages

[Nitesh Narayan Lal]

[-- Attachment #1.1: Type: text/plain, Size: 12511 bytes --]


On 3/7/19 1:30 PM, Alexander Duyck wrote:
> On Wed, Mar 6, 2019 at 7:51 AM Nitesh Narayan Lal <nitesh@redhat.com> wrote:
>> This patch enables the kernel to scan the per cpu array
>> which carries head pages from the buddy free list of order
>> FREE_PAGE_HINTING_MIN_ORDER (MAX_ORDER - 1) by
>> guest_free_page_hinting().
>> guest_free_page_hinting() scans the entire per cpu array by
>> acquiring a zone lock corresponding to the pages which are
>> being scanned. If the page is still free and present in the
>> buddy it tries to isolate the page and adds it to a
>> dynamically allocated array.
>>
>> Once this scanning process is complete and if there are any
>> isolated pages added to the dynamically allocated array
>> guest_free_page_report() is invoked. However, before this the
>> per-cpu array index is reset so that it can continue capturing
>> the pages from buddy free list.
>>
>> In this patch guest_free_page_report() simply releases the pages back
>> to the buddy by using __free_one_page()
>>
>> Signed-off-by: Nitesh Narayan Lal <nitesh@redhat.com>
> I'm pretty sure this code is not thread safe and has a few various issues.
>
>> ---
>>  include/linux/page_hinting.h |   5 ++
>>  mm/page_alloc.c              |   2 +-
>>  virt/kvm/page_hinting.c      | 154 +++++++++++++++++++++++++++++++++++
>>  3 files changed, 160 insertions(+), 1 deletion(-)
>>
>> diff --git a/include/linux/page_hinting.h b/include/linux/page_hinting.h
>> index 90254c582789..d554a2581826 100644
>> --- a/include/linux/page_hinting.h
>> +++ b/include/linux/page_hinting.h
>> @@ -13,3 +13,8 @@
>>
>>  void guest_free_page_enqueue(struct page *page, int order);
>>  void guest_free_page_try_hinting(void);
>> +extern int __isolate_free_page(struct page *page, unsigned int order);
>> +extern void __free_one_page(struct page *page, unsigned long pfn,
>> +                           struct zone *zone, unsigned int order,
>> +                           int migratetype);
>> +void release_buddy_pages(void *obj_to_free, int entries);
>> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
>> index 684d047f33ee..d38b7eea207b 100644
>> --- a/mm/page_alloc.c
>> +++ b/mm/page_alloc.c
>> @@ -814,7 +814,7 @@ static inline int page_is_buddy(struct page *page, struct page *buddy,
>>   * -- nyc
>>   */
>>
>> -static inline void __free_one_page(struct page *page,
>> +inline void __free_one_page(struct page *page,
>>                 unsigned long pfn,
>>                 struct zone *zone, unsigned int order,
>>                 int migratetype)
>> diff --git a/virt/kvm/page_hinting.c b/virt/kvm/page_hinting.c
>> index 48b4b5e796b0..9885b372b5a9 100644
>> --- a/virt/kvm/page_hinting.c
>> +++ b/virt/kvm/page_hinting.c
>> @@ -1,5 +1,9 @@
>>  #include <linux/mm.h>
>>  #include <linux/page_hinting.h>
>> +#include <linux/page_ref.h>
>> +#include <linux/kvm_host.h>
>> +#include <linux/kernel.h>
>> +#include <linux/sort.h>
>>
>>  /*
>>   * struct guest_free_pages- holds array of guest freed PFN's along with an
>> @@ -16,6 +20,54 @@ struct guest_free_pages {
>>
>>  DEFINE_PER_CPU(struct guest_free_pages, free_pages_obj);
>>
>> +/*
>> + * struct guest_isolated_pages- holds the buddy isolated pages which are
>> + * supposed to be freed by the host.
>> + * @pfn: page frame number for the isolated page.
>> + * @order: order of the isolated page.
>> + */
>> +struct guest_isolated_pages {
>> +       unsigned long pfn;
>> +       unsigned int order;
>> +};
>> +
>> +void release_buddy_pages(void *obj_to_free, int entries)
>> +{
>> +       int i = 0;
>> +       int mt = 0;
>> +       struct guest_isolated_pages *isolated_pages_obj = obj_to_free;
>> +
>> +       while (i < entries) {
>> +               struct page *page = pfn_to_page(isolated_pages_obj[i].pfn);
>> +
>> +               mt = get_pageblock_migratetype(page);
>> +               __free_one_page(page, page_to_pfn(page), page_zone(page),
>> +                               isolated_pages_obj[i].order, mt);
>> +               i++;
>> +       }
>> +       kfree(isolated_pages_obj);
>> +}
> You shouldn't be accessing __free_one_page without holding the zone
> lock for the page. You might consider confining yourself to one zone
> worth of hints at a time. Then you can acquire the lock once, and then
> return the memory you have freed.
That is correct.
>
> This is one of the reasons why I am thinking maybe a bit in the page
> and then spinning on that bit in arch_alloc_page might be a nice way
> to get around this. Then you only have to take the zone lock when you
> are finding the pages you want to hint on and setting the bit
> indicating they are mid hint. Otherwise you have to take the zone lock
> to pull pages out, and to put them back in and the likelihood of a
> lock collision is much higher.
Do you think adding a new flag to the page structure will be acceptable?
>
>> +
>> +void guest_free_page_report(struct guest_isolated_pages *isolated_pages_obj,
>> +                           int entries)
>> +{
>> +       release_buddy_pages(isolated_pages_obj, entries);
>> +}
>> +
>> +static int sort_zonenum(const void *a1, const void *b1)
>> +{
>> +       const unsigned long *a = a1;
>> +       const unsigned long *b = b1;
>> +
>> +       if (page_zonenum(pfn_to_page(a[0])) > page_zonenum(pfn_to_page(b[0])))
>> +               return 1;
>> +
>> +       if (page_zonenum(pfn_to_page(a[0])) < page_zonenum(pfn_to_page(b[0])))
>> +               return -1;
>> +
>> +       return 0;
>> +}
>> +
>>  struct page *get_buddy_page(struct page *page)
>>  {
>>         unsigned long pfn = page_to_pfn(page);
>> @@ -33,9 +85,111 @@ struct page *get_buddy_page(struct page *page)
>>  static void guest_free_page_hinting(void)
>>  {
>>         struct guest_free_pages *hinting_obj = &get_cpu_var(free_pages_obj);
>> +       struct guest_isolated_pages *isolated_pages_obj;
>> +       int idx = 0, ret = 0;
>> +       struct zone *zone_cur, *zone_prev;
>> +       unsigned long flags = 0;
>> +       int hyp_idx = 0;
>> +       int free_pages_idx = hinting_obj->free_pages_idx;
>> +
>> +       isolated_pages_obj = kmalloc(MAX_FGPT_ENTRIES *
>> +                       sizeof(struct guest_isolated_pages), GFP_KERNEL);
>> +       if (!isolated_pages_obj) {
>> +               hinting_obj->free_pages_idx = 0;
>> +               put_cpu_var(hinting_obj);
>> +               return;
>> +               /* return some logical error here*/
>> +       }
>> +
>> +       sort(hinting_obj->free_page_arr, free_pages_idx,
>> +            sizeof(unsigned long), sort_zonenum, NULL);
>> +
>> +       while (idx < free_pages_idx) {
>> +               unsigned long pfn = hinting_obj->free_page_arr[idx];
>> +               unsigned long pfn_end = hinting_obj->free_page_arr[idx] +
>> +                       (1 << FREE_PAGE_HINTING_MIN_ORDER) - 1;
>> +
>> +               zone_cur = page_zone(pfn_to_page(pfn));
>> +               if (idx == 0) {
>> +                       zone_prev = zone_cur;
>> +                       spin_lock_irqsave(&zone_cur->lock, flags);
>> +               } else if (zone_prev != zone_cur) {
>> +                       spin_unlock_irqrestore(&zone_prev->lock, flags);
>> +                       spin_lock_irqsave(&zone_cur->lock, flags);
>> +                       zone_prev = zone_cur;
>> +               }
>> +
>> +               while (pfn <= pfn_end) {
>> +                       struct page *page = pfn_to_page(pfn);
>> +                       struct page *buddy_page = NULL;
>> +
>> +                       if (PageCompound(page)) {
>> +                               struct page *head_page = compound_head(page);
>> +                               unsigned long head_pfn = page_to_pfn(head_page);
>> +                               unsigned int alloc_pages =
>> +                                       1 << compound_order(head_page);
>> +
>> +                               pfn = head_pfn + alloc_pages;
>> +                               continue;
>> +                       }
>> +
> I don't think the buddy allocator has compound pages.
Yes, I don't need this.
>
>> +                       if (page_ref_count(page)) {
>> +                               pfn++;
>> +                               continue;
>> +                       }
>> +
> A ref count of 0 doesn't mean the page isn't in use. It could be in
> use by something such as SLUB for instance.
Yes but it is not the criteria by which we are isolating.

If PageBuddy() is returning true then only we actually try and isolate.

I can possibly remove the compound and page_ref_count() checks.

>
>> +                       if (PageBuddy(page) && page_private(page) >=
>> +                           FREE_PAGE_HINTING_MIN_ORDER) {
>> +                               int buddy_order = page_private(page);
>> +
>> +                               ret = __isolate_free_page(page, buddy_order);
>> +                               if (ret) {
>> +                                       isolated_pages_obj[hyp_idx].pfn = pfn;
>> +                                       isolated_pages_obj[hyp_idx].order =
>> +                                                               buddy_order;
>> +                                       hyp_idx += 1;
>> +                               }
>> +                               pfn = pfn + (1 << buddy_order);
>> +                               continue;
>> +                       }
>> +
> So this is where things start to get ugly. Basically because we were
> acquiring the hints when they were freed we end up needing to check
> either this page, and the PFN for all of the higher order pages this
> page could be a part of. Since we are currently limiting ourselves to
> MAX_ORDER - 1 it shouldn't be too expensive. I don't recall if your
> get_buddy_page already had that limitation coded in but we should
> probably look at doing that there. 
Do you mean the check for page order?
> Then we can just skip the PageBuddy
> check up here and have it automatically start walking all pages your
> original page could be a part of looking for the highest page order
> that might still be free.
>
>> +                       buddy_page = get_buddy_page(page);
>> +                       if (buddy_page && page_private(buddy_page) >=
>> +                           FREE_PAGE_HINTING_MIN_ORDER) {
>> +                               int buddy_order = page_private(buddy_page);
>> +
>> +                               ret = __isolate_free_page(buddy_page,
>> +                                                         buddy_order);
>> +                               if (ret) {
>> +                                       unsigned long buddy_pfn =
>> +                                               page_to_pfn(buddy_page);
>> +
>> +                                       isolated_pages_obj[hyp_idx].pfn =
>> +                                                               buddy_pfn;
>> +                                       isolated_pages_obj[hyp_idx].order =
>> +                                                               buddy_order;
>> +                                       hyp_idx += 1;
>> +                               }
>> +                               pfn = page_to_pfn(buddy_page) +
>> +                                       (1 << buddy_order);
>> +                               continue;
>> +                       }
> This is essentially just a duplicate of the code above. As I mentioned
> before it would probably make sense to just combine this block with
> that one.
Yeap, I should get rid of this. Now as we are capturing post buddy
merging we don't need this.
Thanks.
>
>> +                       pfn++;
>> +               }
>> +               hinting_obj->free_page_arr[idx] = 0;
>> +               idx++;
>> +               if (idx == free_pages_idx)
>> +                       spin_unlock_irqrestore(&zone_cur->lock, flags);
>> +       }
>>
>>         hinting_obj->free_pages_idx = 0;
>>         put_cpu_var(hinting_obj);
>> +
>> +       if (hyp_idx > 0)
>> +               guest_free_page_report(isolated_pages_obj, hyp_idx);
>> +       else
>> +               kfree(isolated_pages_obj);
>> +               /* return some logical error here*/
>>  }
>>
>>  int if_exist(struct page *page)
>> --
>> 2.17.2
>>
-- 
Regards
Nitesh


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [RFC][Patch v9 0/6] KVM: Guest Free Page Hinting

[David Hildenbrand]

On 07.03.19 19:53, Michael S. Tsirkin wrote:
> On Thu, Mar 07, 2019 at 10:45:58AM -0800, Alexander Duyck wrote:
>> To that end what I think w may want to do is instead just walk the LRU
>> list for a given zone/order in reverse order so that we can try to
>> identify the pages that are most likely to be cold and unused and
>> those are the first ones we want to be hinting on rather than the ones
>> that were just freed. If we can look at doing something like adding a
>> jiffies value to the page indicating when it was last freed we could
>> even have a good point for determining when we should stop processing
>> pages in a given zone/order list.
>>
>> In reality the approach wouldn't be too different from what you are
>> doing now, the only real difference would be that we would just want
>> to walk the LRU list for the given zone/order rather then pulling
>> hints on what to free from the calls to free_one_page. In addition we
>> would need to add a couple bits to indicate if the page has been
>> hinted on, is in the middle of getting hinted on, and something such
>> as the jiffies value I mentioned which we could use to determine how
>> old the page is.
> 
> Do we really need bits in the page?
> Would it be bad to just have a separate hint list?
> 
> If you run out of free memory you can check the hint
> list, if you find stuff there you can spin
> or kick the hypervisor to hurry up.
> 
> Core mm/ changes, so nothing's easy, I know.

We evaluated the idea of busy spinning on some bit/list entry a while
ago. While it sounds interesting, it is usually not what we want and has
other negative performance impacts.

Talking about "marking" pages, what we actually would want is to rework
the buddy to skip over these "marked" pages and only really spin in case
there are no other pages left. Allocation paths should only ever be
blocked if OOM, not if just some hinting activity is going on on another
VCPU.

However as you correctly say: "core mm changes". New page flag?
Basically impossible. Reuse another one? Can easily get horrbily
confusing and can easily get rejected upstream. What about the buddy
wanting to merge pages that are marked (assuming we also want something
< MAX_ORDER - 1)? This smells like possibly heavy core mm changes.

Lesson learned: Avoid such heavy changes. Especially in the first shot.

The interesting thing about Nitesh's aproach right now is that we can
easily rework these details later on. The host->guest interface will
stay the same. Instead of temporarily taking pages out of the buddy, we
could e.g. mark them and make the buddy or other users skip over them.

-- 

Thanks,

David / dhildenb

Re: [RFC][Patch v9 2/6] KVM: Enables the kernel to isolate guest free pages

[David Hildenbrand]

On 07.03.19 20:23, Nitesh Narayan Lal wrote:
> 
> On 3/7/19 1:30 PM, Alexander Duyck wrote:
>> On Wed, Mar 6, 2019 at 7:51 AM Nitesh Narayan Lal <nitesh@redhat.com> wrote:
>>> This patch enables the kernel to scan the per cpu array
>>> which carries head pages from the buddy free list of order
>>> FREE_PAGE_HINTING_MIN_ORDER (MAX_ORDER - 1) by
>>> guest_free_page_hinting().
>>> guest_free_page_hinting() scans the entire per cpu array by
>>> acquiring a zone lock corresponding to the pages which are
>>> being scanned. If the page is still free and present in the
>>> buddy it tries to isolate the page and adds it to a
>>> dynamically allocated array.
>>>
>>> Once this scanning process is complete and if there are any
>>> isolated pages added to the dynamically allocated array
>>> guest_free_page_report() is invoked. However, before this the
>>> per-cpu array index is reset so that it can continue capturing
>>> the pages from buddy free list.
>>>
>>> In this patch guest_free_page_report() simply releases the pages back
>>> to the buddy by using __free_one_page()
>>>
>>> Signed-off-by: Nitesh Narayan Lal <nitesh@redhat.com>
>> I'm pretty sure this code is not thread safe and has a few various issues.
>>
>>> ---
>>>  include/linux/page_hinting.h |   5 ++
>>>  mm/page_alloc.c              |   2 +-
>>>  virt/kvm/page_hinting.c      | 154 +++++++++++++++++++++++++++++++++++
>>>  3 files changed, 160 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/include/linux/page_hinting.h b/include/linux/page_hinting.h
>>> index 90254c582789..d554a2581826 100644
>>> --- a/include/linux/page_hinting.h
>>> +++ b/include/linux/page_hinting.h
>>> @@ -13,3 +13,8 @@
>>>
>>>  void guest_free_page_enqueue(struct page *page, int order);
>>>  void guest_free_page_try_hinting(void);
>>> +extern int __isolate_free_page(struct page *page, unsigned int order);
>>> +extern void __free_one_page(struct page *page, unsigned long pfn,
>>> +                           struct zone *zone, unsigned int order,
>>> +                           int migratetype);
>>> +void release_buddy_pages(void *obj_to_free, int entries);
>>> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
>>> index 684d047f33ee..d38b7eea207b 100644
>>> --- a/mm/page_alloc.c
>>> +++ b/mm/page_alloc.c
>>> @@ -814,7 +814,7 @@ static inline int page_is_buddy(struct page *page, struct page *buddy,
>>>   * -- nyc
>>>   */
>>>
>>> -static inline void __free_one_page(struct page *page,
>>> +inline void __free_one_page(struct page *page,
>>>                 unsigned long pfn,
>>>                 struct zone *zone, unsigned int order,
>>>                 int migratetype)
>>> diff --git a/virt/kvm/page_hinting.c b/virt/kvm/page_hinting.c
>>> index 48b4b5e796b0..9885b372b5a9 100644
>>> --- a/virt/kvm/page_hinting.c
>>> +++ b/virt/kvm/page_hinting.c
>>> @@ -1,5 +1,9 @@
>>>  #include <linux/mm.h>
>>>  #include <linux/page_hinting.h>
>>> +#include <linux/page_ref.h>
>>> +#include <linux/kvm_host.h>
>>> +#include <linux/kernel.h>
>>> +#include <linux/sort.h>
>>>
>>>  /*
>>>   * struct guest_free_pages- holds array of guest freed PFN's along with an
>>> @@ -16,6 +20,54 @@ struct guest_free_pages {
>>>
>>>  DEFINE_PER_CPU(struct guest_free_pages, free_pages_obj);
>>>
>>> +/*
>>> + * struct guest_isolated_pages- holds the buddy isolated pages which are
>>> + * supposed to be freed by the host.
>>> + * @pfn: page frame number for the isolated page.
>>> + * @order: order of the isolated page.
>>> + */
>>> +struct guest_isolated_pages {
>>> +       unsigned long pfn;
>>> +       unsigned int order;
>>> +};
>>> +
>>> +void release_buddy_pages(void *obj_to_free, int entries)
>>> +{
>>> +       int i = 0;
>>> +       int mt = 0;
>>> +       struct guest_isolated_pages *isolated_pages_obj = obj_to_free;
>>> +
>>> +       while (i < entries) {
>>> +               struct page *page = pfn_to_page(isolated_pages_obj[i].pfn);
>>> +
>>> +               mt = get_pageblock_migratetype(page);
>>> +               __free_one_page(page, page_to_pfn(page), page_zone(page),
>>> +                               isolated_pages_obj[i].order, mt);
>>> +               i++;
>>> +       }
>>> +       kfree(isolated_pages_obj);
>>> +}
>> You shouldn't be accessing __free_one_page without holding the zone
>> lock for the page. You might consider confining yourself to one zone
>> worth of hints at a time. Then you can acquire the lock once, and then
>> return the memory you have freed.
> That is correct.
>>
>> This is one of the reasons why I am thinking maybe a bit in the page
>> and then spinning on that bit in arch_alloc_page might be a nice way
>> to get around this. Then you only have to take the zone lock when you
>> are finding the pages you want to hint on and setting the bit
>> indicating they are mid hint. Otherwise you have to take the zone lock
>> to pull pages out, and to put them back in and the likelihood of a
>> lock collision is much higher.
> Do you think adding a new flag to the page structure will be acceptable?

My lesson learned: forget it. If (at all) reuse some other one that
might be safe in that context. Hard to tell if that is even possible and
will be accepted upstream.

Spinning is not the solution. What you would want is the buddy to
actually skip over these pages and only try to use them (-> spin) when
OOM. Core mm changes (see my other reply).

This all sounds like future work which can be built on top of this work.


-- 

Thanks,

David / dhildenb

Re: [RFC][Patch v9 1/6] KVM: Guest free page hinting support

[Nitesh Narayan Lal]

[-- Attachment #1.1: Type: text/plain, Size: 11137 bytes --]


On 3/6/19 6:43 PM, Alexander Duyck wrote:
> On Wed, Mar 6, 2019 at 7:51 AM Nitesh Narayan Lal <nitesh@redhat.com> wrote:
>> This patch adds the following:
>> 1. Functional skeleton for the guest implementation. It enables the
>> guest to maintain the PFN of head buddy free pages of order
>> FREE_PAGE_HINTING_MIN_ORDER (currently defined as MAX_ORDER - 1)
>> in a per-cpu array.
>> Guest uses guest_free_page_enqueue() to enqueue the free pages post buddy
>> merging to the above mentioned per-cpu array.
>> guest_free_page_try_hinting() is used to initiate hinting operation once
>> the collected entries of the per-cpu array reaches or exceeds
>> HINTING_THRESHOLD (128). Having larger array size(MAX_FGPT_ENTRIES = 256)
>> than HINTING_THRESHOLD allows us to capture more pages specifically when
>> guest_free_page_enqueue() is called from free_pcppages_bulk().
>> For now guest_free_page_hinting() just resets the array index to continue
>> capturing of the freed pages.
>> 2. Enables the support for x86 architecture.
>>
>> Signed-off-by: Nitesh Narayan Lal <nitesh@redhat.com>
>> ---
>>  arch/x86/Kbuild              |  2 +-
>>  arch/x86/kvm/Kconfig         |  8 +++
>>  arch/x86/kvm/Makefile        |  2 +
>>  include/linux/page_hinting.h | 15 ++++++
>>  mm/page_alloc.c              |  5 ++
>>  virt/kvm/page_hinting.c      | 98 ++++++++++++++++++++++++++++++++++++
>>  6 files changed, 129 insertions(+), 1 deletion(-)
>>  create mode 100644 include/linux/page_hinting.h
>>  create mode 100644 virt/kvm/page_hinting.c
>>
>> diff --git a/arch/x86/Kbuild b/arch/x86/Kbuild
>> index c625f57472f7..3244df4ee311 100644
>> --- a/arch/x86/Kbuild
>> +++ b/arch/x86/Kbuild
>> @@ -2,7 +2,7 @@ obj-y += entry/
>>
>>  obj-$(CONFIG_PERF_EVENTS) += events/
>>
>> -obj-$(CONFIG_KVM) += kvm/
>> +obj-$(subst m,y,$(CONFIG_KVM)) += kvm/
>>
>>  # Xen paravirtualization support
>>  obj-$(CONFIG_XEN) += xen/
>> diff --git a/arch/x86/kvm/Kconfig b/arch/x86/kvm/Kconfig
>> index 72fa955f4a15..2fae31459706 100644
>> --- a/arch/x86/kvm/Kconfig
>> +++ b/arch/x86/kvm/Kconfig
>> @@ -96,6 +96,14 @@ config KVM_MMU_AUDIT
>>          This option adds a R/W kVM module parameter 'mmu_audit', which allows
>>          auditing of KVM MMU events at runtime.
>>
>> +# KVM_FREE_PAGE_HINTING will allow the guest to report the free pages to the
>> +# host in regular interval of time.
>> +config KVM_FREE_PAGE_HINTING
>> +       def_bool y
>> +       depends on KVM
>> +       select VIRTIO
>> +       select VIRTIO_BALLOON
>> +
>>  # OK, it's a little counter-intuitive to do this, but it puts it neatly under
>>  # the virtualization menu.
>>  source "drivers/vhost/Kconfig"
>> diff --git a/arch/x86/kvm/Makefile b/arch/x86/kvm/Makefile
>> index 69b3a7c30013..78640a80501e 100644
>> --- a/arch/x86/kvm/Makefile
>> +++ b/arch/x86/kvm/Makefile
>> @@ -16,6 +16,8 @@ kvm-y                 += x86.o mmu.o emulate.o i8259.o irq.o lapic.o \
>>                            i8254.o ioapic.o irq_comm.o cpuid.o pmu.o mtrr.o \
>>                            hyperv.o page_track.o debugfs.o
>>
>> +obj-$(CONFIG_KVM_FREE_PAGE_HINTING)    += $(KVM)/page_hinting.o
>> +
>>  kvm-intel-y            += vmx/vmx.o vmx/vmenter.o vmx/pmu_intel.o vmx/vmcs12.o vmx/evmcs.o vmx/nested.o
>>  kvm-amd-y              += svm.o pmu_amd.o
>>
>> diff --git a/include/linux/page_hinting.h b/include/linux/page_hinting.h
>> new file mode 100644
>> index 000000000000..90254c582789
>> --- /dev/null
>> +++ b/include/linux/page_hinting.h
>> @@ -0,0 +1,15 @@
>> +#include <linux/gfp.h>
>> +/*
>> + * Size of the array which is used to store the freed pages is defined by
>> + * MAX_FGPT_ENTRIES.
>> + */
>> +#define MAX_FGPT_ENTRIES       256
>> +/*
>> + * Threshold value after which hinting needs to be initiated on the captured
>> + * free pages.
>> + */
>> +#define HINTING_THRESHOLD      128
>> +#define FREE_PAGE_HINTING_MIN_ORDER    (MAX_ORDER - 1)
>> +
>> +void guest_free_page_enqueue(struct page *page, int order);
>> +void guest_free_page_try_hinting(void);
>> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
>> index d295c9bc01a8..684d047f33ee 100644
>> --- a/mm/page_alloc.c
>> +++ b/mm/page_alloc.c
>> @@ -67,6 +67,7 @@
>>  #include <linux/lockdep.h>
>>  #include <linux/nmi.h>
>>  #include <linux/psi.h>
>> +#include <linux/page_hinting.h>
>>
>>  #include <asm/sections.h>
>>  #include <asm/tlbflush.h>
>> @@ -1194,9 +1195,11 @@ static void free_pcppages_bulk(struct zone *zone, int count,
>>                         mt = get_pageblock_migratetype(page);
>>
>>                 __free_one_page(page, page_to_pfn(page), zone, 0, mt);
>> +               guest_free_page_enqueue(page, 0);
>>                 trace_mm_page_pcpu_drain(page, 0, mt);
>>         }
>>         spin_unlock(&zone->lock);
>> +       guest_free_page_try_hinting();
>>  }
>>
> Trying to enqueue pages from here seems like a really bad idea. You
> are essentially putting yourself in a hot-path for order 0 pages and
> going to cause significant bottlenecks.
>
>>  static void free_one_page(struct zone *zone,
>> @@ -1210,7 +1213,9 @@ static void free_one_page(struct zone *zone,
>>                 migratetype = get_pfnblock_migratetype(page, pfn);
>>         }
>>         __free_one_page(page, pfn, zone, order, migratetype);
>> +       guest_free_page_enqueue(page, order);
>>         spin_unlock(&zone->lock);
>> +       guest_free_page_try_hinting();
>>  }
> I really think it would be better to leave the page assembly to the
> buddy allocator. Instead you may want to focus on somehow tagging the
> pages as being recently freed but not hinted on so that you can come
> back later to work on them.
I think this will lead us to the same discussion which we are having
under other patch about having a page flag. Let's discuss it there.
>
>>  static void __meminit __init_single_page(struct page *page, unsigned long pfn,
>> diff --git a/virt/kvm/page_hinting.c b/virt/kvm/page_hinting.c
>> new file mode 100644
>> index 000000000000..48b4b5e796b0
>> --- /dev/null
>> +++ b/virt/kvm/page_hinting.c
>> @@ -0,0 +1,98 @@
>> +#include <linux/mm.h>
>> +#include <linux/page_hinting.h>
>> +
>> +/*
>> + * struct guest_free_pages- holds array of guest freed PFN's along with an
>> + * index variable to track total freed PFN's.
>> + * @free_pfn_arr: array to store the page frame number of all the pages which
>> + * are freed by the guest.
>> + * @guest_free_pages_idx: index to track the number entries stored in
>> + * free_pfn_arr.
>> + */
>> +struct guest_free_pages {
>> +       unsigned long free_page_arr[MAX_FGPT_ENTRIES];
>> +       int free_pages_idx;
>> +};
>> +
>> +DEFINE_PER_CPU(struct guest_free_pages, free_pages_obj);
>> +
>> +struct page *get_buddy_page(struct page *page)
>> +{
>> +       unsigned long pfn = page_to_pfn(page);
>> +       unsigned int order;
>> +
>> +       for (order = 0; order < MAX_ORDER; order++) {
>> +               struct page *page_head = page - (pfn & ((1 << order) - 1));
>> +
>> +               if (PageBuddy(page_head) && page_private(page_head) >= order)
>> +                       return page_head;
>> +       }
>> +       return NULL;
>> +}
>> +
> You would be much better off just letting the buddy allocator take care of this.
>
> I really think the spot I had my arch_merge_page call would work much
> better than this. The buddy allocator is already optimized to handle
> merging the pages and such so we should really let it do its job
> rather than reinventing it ourselves.
Yes I can have my hook in __free_one_page() but then in order to avoid
duplicate hints we need to have some page flag bit.
>
>> +static void guest_free_page_hinting(void)
>> +{
>> +       struct guest_free_pages *hinting_obj = &get_cpu_var(free_pages_obj);
>> +
>> +       hinting_obj->free_pages_idx = 0;
>> +       put_cpu_var(hinting_obj);
>> +}
>> +
> Shouldn't this be guarded with a local_irq_save to prevent someone
> from possibly performing an enqueue on the same CPU as the one you are
> resetting the work on, or is just the preempt_disable int he
> get_cpu_var enough to handle the case? If so could we get away with
> the same thing for the guest_free_page_enqueue?
I am not sure about this, I will take a look at it.
>
>> +int if_exist(struct page *page)
>> +{
>> +       int i = 0;
>> +       struct guest_free_pages *hinting_obj = this_cpu_ptr(&free_pages_obj);
>> +
>> +       while (i < MAX_FGPT_ENTRIES) {
>> +               if (page_to_pfn(page) == hinting_obj->free_page_arr[i])
>> +                       return 1;
>> +               i++;
>> +       }
>> +       return 0;
>> +}
>> +
> Doing a linear search for the page is going to be painful. Also this
> is only searching a per-cpu list. What if you have this split over a
> couple of CPUs?
That's correct if there is the same page in multiple per cpu array. Then
the isolation request corresponding to the per cpu array in which it's
added at a later point of time will fail.
>
>> +void guest_free_page_enqueue(struct page *page, int order)
>> +{
>> +       unsigned long flags;
>> +       struct guest_free_pages *hinting_obj;
>> +       int l_idx;
>> +
>> +       /*
>> +        * use of global variables may trigger a race condition between irq and
>> +        * process context causing unwanted overwrites. This will be replaced
>> +        * with a better solution to prevent such race conditions.
>> +        */
>> +       local_irq_save(flags);
>> +       hinting_obj = this_cpu_ptr(&free_pages_obj);
>> +       l_idx = hinting_obj->free_pages_idx;
>> +       if (l_idx != MAX_FGPT_ENTRIES) {
>> +               if (PageBuddy(page) && page_private(page) >=
>> +                   FREE_PAGE_HINTING_MIN_ORDER) {
>> +                       hinting_obj->free_page_arr[l_idx] = page_to_pfn(page);
>> +                       hinting_obj->free_pages_idx += 1;
>> +               } else {
>> +                       struct page *buddy_page = get_buddy_page(page);
>> +
>> +                       if (buddy_page && page_private(buddy_page) >=
>> +                           FREE_PAGE_HINTING_MIN_ORDER &&
>> +                           !if_exist(buddy_page)) {
>> +                               unsigned long buddy_pfn =
>> +                                       page_to_pfn(buddy_page);
>> +
>> +                               hinting_obj->free_page_arr[l_idx] =
>> +                                                       buddy_pfn;
>> +                               hinting_obj->free_pages_idx += 1;
>> +                       }
>> +               }
>> +       }
>> +       local_irq_restore(flags);
>> +}
>> +
>> +void guest_free_page_try_hinting(void)
>> +{
>> +       struct guest_free_pages *hinting_obj;
>> +
>> +       hinting_obj = this_cpu_ptr(&free_pages_obj);
>> +       if (hinting_obj->free_pages_idx >= HINTING_THRESHOLD)
>> +               guest_free_page_hinting();
>> +}
>> --
>> 2.17.2
>>
-- 
Regards
Nitesh


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [RFC][Patch v9 0/6] KVM: Guest Free Page Hinting

[Nitesh Narayan Lal]

[-- Attachment #1.1: Type: text/plain, Size: 15085 bytes --]


On 3/7/19 1:45 PM, Alexander Duyck wrote:
> On Thu, Mar 7, 2019 at 5:09 AM Nitesh Narayan Lal <nitesh@redhat.com> wrote:
>>
>> On 3/6/19 5:05 PM, Alexander Duyck wrote:
>>> On Wed, Mar 6, 2019 at 11:07 AM Nitesh Narayan Lal <nitesh@redhat.com> wrote:
>>>> On 3/6/19 1:00 PM, Alexander Duyck wrote:
>>>>> On Wed, Mar 6, 2019 at 7:51 AM Nitesh Narayan Lal <nitesh@redhat.com> wrote:
>>>>>> The following patch-set proposes an efficient mechanism for handing freed memory between the guest and the host. It enables the guests with no page cache to rapidly free and reclaims memory to and from the host respectively.
>>>>>>
>>>>>> Benefit:
>>>>>> With this patch-series, in our test-case, executed on a single system and single NUMA node with 15GB memory, we were able to successfully launch 5 guests(each with 5 GB memory) when page hinting was enabled and 3 without it. (Detailed explanation of the test procedure is provided at the bottom under Test - 1).
>>>>>>
>>>>>> Changelog in v9:
>>>>>>         * Guest free page hinting hook is now invoked after a page has been merged in the buddy.
>>>>>>         * Free pages only with order FREE_PAGE_HINTING_MIN_ORDER(currently defined as MAX_ORDER - 1) are captured.
>>>>>>         * Removed kthread which was earlier used to perform the scanning, isolation & reporting of free pages.
>>>>> Without a kthread this has the potential to get really ugly really
>>>>> fast. If we are going to run asynchronously we should probably be
>>>>> truly asynchonous and just place a few pieces of data in the page that
>>>>> a worker thread can use to identify which pages have been hinted and
>>>>> which pages have not.
>>>> Can you please explain what do you mean by truly asynchronous?
>>>>
>>>> With this implementation also I am not reporting the pages synchronously.
>>> The problem is you are making it pseudo synchronous by having to push
>>> pages off to a side buffer aren't you? In my mind we should be able to
>>> have the page hinting go on with little to no interference with
>>> existing page allocation and freeing.
>> We have to opt one of the two options:
>> 1. Block allocation by using a flag or acquire a lock to prevent the
>> usage of pages we are hinting.
>> 2. Remove the page set entirely from the buddy. (This is what I am doing
>> right now)
>>
>> The reason I would prefer the second approach is that we are not
>> blocking the allocation in any way and as we are only working with a
>> smaller set of pages we should be fine.
>> However, with the current approach as we are reporting asynchronously
>> there is a chance that we end up hinting more than 2-3 times for a
>> single workload run. In situation where this could lead to low memory
>> condition in the guest, the hinting will anyways fail as the guest will
>> not allow page isolation.
>> I can possibly try and test the same to ensure that we don't get OOM due
>> to hinting when the guest is under memory pressure.
> So in either case you are essentially blocking allocation since the
> memory cannot be used. My concern is more with guaranteeing forward
> progress for as many CPUs as possible.
>
> With your current design you have one minor issue in that you aren't
> taking the lock to re-insert the pages back into the buddy allocator.
> When you add that step in it means you are going to be blocking
> allocation on that zone while you are reinserting the pages.
>
> Also right now you are using the calls to free_one_page to generate a
> list of hints where to search. I'm thinking that may not be the best
> approach since what we want to do is provide hints on idle free pages,
> not just pages that will be free for a short period of time.
>
> To that end what I think w may want to do is instead just walk the LRU
> list for a given zone/order in reverse order so that we can try to
> identify the pages that are most likely to be cold and unused and
> those are the first ones we want to be hinting on rather than the ones
> that were just freed. If we can look at doing something like adding a
> jiffies value to the page indicating when it was last freed we could
> even have a good point for determining when we should stop processing
> pages in a given zone/order list.
>
> In reality the approach wouldn't be too different from what you are
> doing now, the only real difference would be that we would just want
> to walk the LRU list for the given zone/order rather then pulling
> hints on what to free from the calls to free_one_page. In addition we
> would need to add a couple bits to indicate if the page has been
> hinted on, is in the middle of getting hinted on, and something such
> as the jiffies value I mentioned which we could use to determine how
> old the page is.
>
>>>>> Then we can have that one thread just walking
>>>>> through the zone memory pulling out fixed size pieces at a time and
>>>>> providing hints on that. By doing that we avoid the potential of
>>>>> creating a batch of pages that eat up most of the system memory.
>>>>>
>>>>>>         * Pages, captured in the per cpu array are sorted based on the zone numbers. This is to avoid redundancy of acquiring zone locks.
>>>>>>         * Dynamically allocated space is used to hold the isolated guest free pages.
>>>>> I have concerns that doing this per CPU and allocating memory
>>>>> dynamically can result in you losing a significant amount of memory as
>>>>> it sits waiting to be hinted.
>>>> It should not as the buddy will keep merging the pages and we are only
>>>> capturing MAX_ORDER - 1.
>>>> This was the issue with the last patch-series when I was capturing all
>>>> order pages resulting in the per-cpu array to be filled with lower order
>>>> pages.
>>>>>>         * All the pages are reported asynchronously to the host via virtio driver.
>>>>>>         * Pages are returned back to the guest buddy free list only when the host response is received.
>>>>> I have been thinking about this. Instead of stealing the page couldn't
>>>>> you simply flag it that there is a hint in progress and simply wait in
>>>>> arch_alloc_page until the hint has been processed?
>>>> With the flag, I am assuming you mean to block the allocation until
>>>> hinting is going on, which is an issue. That was one of the issues
>>>> discussed earlier which I wanted to solve with this implementation.
>>> With the flag we would allow the allocation, but would have to
>>> synchronize with the hinting at that point. I got the idea from the
>>> way the s390 code works. They have both an arch_free_page and an
>>> arch_alloc_page. If I understand correctly the arch_alloc_page is what
>>> is meant to handle the case of a page that has been marked for
>>> hinting, but may not have been hinted on yet. My thought for now is to
>>> keep it simple and use a page flag to indicate that a page is
>>> currently pending a hint.
>> I am assuming this page flag will be located in the page structure.
>>> We should be able to spin in such a case and
>>> it would probably still perform better than a solution where we would
>>> not have the memory available and possibly be under memory pressure.
>> I had this same idea earlier. However, the thing about which I was not
>> sure is if adding a flag in the page structure will be acceptable upstream.
>>>>> The problem is in
>>>>> stealing pages you are going to introduce false OOM issues when the
>>>>> memory isn't available because it is being hinted on.
>>>> I think this situation will arise when the guest is under memory
>>>> pressure. In such situations any attempt to perform isolation will
>>>> anyways fail and we may not be reporting anything at that time.
>>> What I want to avoid is the scenario where an application grabs a
>>> large amount of memory, then frees said memory, and we are sitting on
>>> it for some time because we decide to try and hint on the large chunk.
>> I agree.
>>> By processing this sometime after the pages are sent to the buddy
>>> allocator in a separate thread, and by processing a small fixed window
>>> of memory at a time we can avoid making freeing memory expensive, and
>>> still provide the hints in a reasonable time frame.
>> My impression is that the current window on which I am working may give
>> issues for smaller size guests. But otherwise, we are already working
>> with a smaller fixed window of memory.
>>
>> I can further restrict this to just 128 entries and test which would
>> bring down the window of memory. Let me know what you think.
> The problem is 128 entries is still pretty big when you consider you
> are working with 4M pages. If I am not mistaken that is a half
> gigabyte of memory. For lower order pages 128 would probably be fine,
> but with the higher order pages we may want to contain things to
> something smaller like 16MB to 64MB worth of memory.
This is something with which we can certainly play around or may even
make configurable.
For now, I think I will continue testing with 128.
>
>>>>>> Pending items:
>>>>>>         * Make sure that the guest free page hinting's current implementation doesn't break hugepages or device assigned guests.
>>>>>>         * Follow up on VIRTIO_BALLOON_F_PAGE_POISON's device side support. (It is currently missing)
>>>>>>         * Compare reporting free pages via vring with vhost.
>>>>>>         * Decide between MADV_DONTNEED and MADV_FREE.
>>>>>>         * Analyze overall performance impact due to guest free page hinting.
>>>>>>         * Come up with proper/traceable error-message/logs.
>>>>> I'll try applying these patches and see if I can reproduce the results
>>>>> you reported.
>>>> Thanks. Let me know if you run into any issues.
>>>>> With the last patch set I couldn't reproduce the results
>>>>> as you reported them.
>>>> If I remember correctly then the last time you only tried with multiple
>>>> vcpus and not with 1 vcpu.
>>> I had tried 1 vcpu, however I ended up running into some other issues
>>> that made it difficult to even boot the system last week.
>>>
>>>>> It has me wondering if you were somehow seeing
>>>>> the effects of a balloon instead of the actual memory hints as I
>>>>> couldn't find any evidence of the memory ever actually being freed
>>>>> back by the hints functionality.
>>>> Can you please elaborate what kind of evidence you are looking for?
>>>>
>>>> I did trace the hints on the QEMU/host side.
>>> It looks like the new patches are working as I am seeing the memory
>>> freeing occurring this time around. Although it looks like this is
>>> still generating traces from free_pcpages_bulk if I enable multiple
>>> VCPUs:
>> I am assuming with the changes you suggested you were able to run this
>> patch-series. Is that correct?
> Yes, I got it working by disabling SMP. I think I found and pointed
> out the issue in your other patch where you were using __free_one_page
> without holding the zone lock.
Yeah. Thanks.
>
>>> [  175.823539] list_add corruption. next->prev should be prev
>>> (ffff947c7ffd61e0), but was ffffc7a29f9e0008. (next=ffffc7a29f4c0008).
>>> [  175.825978] ------------[ cut here ]------------
>>> [  175.826889] kernel BUG at lib/list_debug.c:25!
>>> [  175.827766] invalid opcode: 0000 [#1] SMP PTI
>>> [  175.828621] CPU: 5 PID: 1344 Comm: page_fault1_thr Not tainted
>>> 5.0.0-next-20190306-baseline+ #76
>>> [  175.830312] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
>>> BIOS Bochs 01/01/2011
>>> [  175.831885] RIP: 0010:__list_add_valid+0x35/0x70
>>> [  175.832784] Code: 18 48 8b 32 48 39 f0 75 39 48 39 c7 74 1e 48 39
>>> fa 74 19 b8 01 00 00 00 c3 48 89 c1 48 c7 c7 80 b5 0f a9 31 c0 e8 8f
>>> aa c8 ff <0f> 0b 48 89 c1 48 89 fe 31 c0 48 c7 c7 30 b6 0f a9 e8 79 aa
>>> c8 ff
>>> [  175.836379] RSP: 0018:ffffa717c40839b0 EFLAGS: 00010046
>>> [  175.837394] RAX: 0000000000000075 RBX: ffff947c7ffd61e0 RCX: 0000000000000000
>>> [  175.838779] RDX: 0000000000000000 RSI: ffff947c5f957188 RDI: ffff947c5f957188
>>> [  175.840162] RBP: ffff947c7ffd61d0 R08: 000000000000026f R09: 0000000000000005
>>> [  175.841539] R10: 0000000000000000 R11: ffffa717c4083730 R12: ffffc7a29f260008
>>> [  175.842932] R13: ffff947c7ffd5d00 R14: ffffc7a29f4c0008 R15: ffffc7a29f260000
>>> [  175.844319] FS:  0000000000000000(0000) GS:ffff947c5f940000(0000)
>>> knlGS:0000000000000000
>>> [  175.845896] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>>> [  175.847009] CR2: 00007fffe3421000 CR3: 000000051220e006 CR4: 0000000000160ee0
>>> [  175.848390] Call Trace:
>>> [  175.848896]  free_pcppages_bulk+0x4bc/0x6a0
>>> [  175.849723]  free_unref_page_list+0x10d/0x190
>>> [  175.850567]  release_pages+0x103/0x4a0
>>> [  175.851313]  tlb_flush_mmu_free+0x36/0x50
>>> [  175.852105]  unmap_page_range+0x963/0xd50
>>> [  175.852897]  unmap_vmas+0x62/0xc0
>>> [  175.853549]  exit_mmap+0xb5/0x1a0
>>> [  175.854205]  mmput+0x5b/0x120
>>> [  175.854794]  do_exit+0x273/0xc30
>>> [  175.855426]  ? free_unref_page_commit+0x85/0xf0
>>> [  175.856312]  do_group_exit+0x39/0xa0
>>> [  175.857018]  get_signal+0x172/0x7c0
>>> [  175.857703]  do_signal+0x36/0x620
>>> [  175.858355]  ? percpu_counter_add_batch+0x4b/0x60
>>> [  175.859280]  ? __do_munmap+0x288/0x390
>>> [  175.860020]  exit_to_usermode_loop+0x4c/0xa8
>>> [  175.860859]  do_syscall_64+0x152/0x170
>>> [  175.861595]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
>>> [  175.862586] RIP: 0033:0x7ffff76a8ec7
>>> [  175.863292] Code: Bad RIP value.
>>> [  175.863928] RSP: 002b:00007ffff4422eb8 EFLAGS: 00000212 ORIG_RAX:
>>> 000000000000000b
>>> [  175.865396] RAX: 0000000000000000 RBX: 00007ffff7ff7280 RCX: 00007ffff76a8ec7
>>> [  175.866799] RDX: 00007fffe3422000 RSI: 0000000008000000 RDI: 00007fffdb422000
>>> [  175.868194] RBP: 0000000000001000 R08: ffffffffffffffff R09: 0000000000000000
>>> [  175.869582] R10: 0000000000000022 R11: 0000000000000212 R12: 00007ffff4422fc0
>>> [  175.870984] R13: 0000000000000001 R14: 00007fffffffc1b0 R15: 00007ffff44239c0
>>> [  175.872350] Modules linked in: ip6t_rpfilter ip6t_REJECT
>>> nf_reject_ipv6 xt_conntrack ip_set nfnetlink ebtable_nat
>>> ebtable_broute bridge stp llc ip6table_nat ip6table_mangle
>>> ip6table_raw ip6table_security iptable_nat nf_nat nf_conntrack
>>> nf_defrag_ipv6 nf_defrag_ipv4 iptable_mangle iptable_raw
>>> iptable_security ebtable_filter ebtables ip6table_filter ip6_tables
>>> sunrpc sb_edac crct10dif_pclmul crc32_pclmul ghash_clmulni_intel
>>> kvm_intel kvm ppdev irqbypass parport_pc parport virtio_balloon pcspkr
>>> i2c_piix4 joydev xfs libcrc32c cirrus drm_kms_helper ttm drm e1000
>>> crc32c_intel virtio_blk serio_raw ata_generic floppy pata_acpi
>>> qemu_fw_cfg
>>> [  175.883153] ---[ end trace 5b67f12a67d1f373 ]---
>>>
>>> I should be able to rebuild the kernels/qemu and test this patch set
>>> over the next day or two.
>> Thanks.
>>> Thanks.
>>>
>>> - Alex
>> --
>> Regards
>> Nitesh
>>
-- 
Regards
Nitesh


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [RFC][Patch v9 0/6] KVM: Guest Free Page Hinting

[David Hildenbrand]

On 07.03.19 19:45, Alexander Duyck wrote:
> On Thu, Mar 7, 2019 at 5:09 AM Nitesh Narayan Lal <nitesh@redhat.com> wrote:
>>
>>
>> On 3/6/19 5:05 PM, Alexander Duyck wrote:
>>> On Wed, Mar 6, 2019 at 11:07 AM Nitesh Narayan Lal <nitesh@redhat.com> wrote:
>>>>
>>>> On 3/6/19 1:00 PM, Alexander Duyck wrote:
>>>>> On Wed, Mar 6, 2019 at 7:51 AM Nitesh Narayan Lal <nitesh@redhat.com> wrote:
>>>>>> The following patch-set proposes an efficient mechanism for handing freed memory between the guest and the host. It enables the guests with no page cache to rapidly free and reclaims memory to and from the host respectively.
>>>>>>
>>>>>> Benefit:
>>>>>> With this patch-series, in our test-case, executed on a single system and single NUMA node with 15GB memory, we were able to successfully launch 5 guests(each with 5 GB memory) when page hinting was enabled and 3 without it. (Detailed explanation of the test procedure is provided at the bottom under Test - 1).
>>>>>>
>>>>>> Changelog in v9:
>>>>>>         * Guest free page hinting hook is now invoked after a page has been merged in the buddy.
>>>>>>         * Free pages only with order FREE_PAGE_HINTING_MIN_ORDER(currently defined as MAX_ORDER - 1) are captured.
>>>>>>         * Removed kthread which was earlier used to perform the scanning, isolation & reporting of free pages.
>>>>> Without a kthread this has the potential to get really ugly really
>>>>> fast. If we are going to run asynchronously we should probably be
>>>>> truly asynchonous and just place a few pieces of data in the page that
>>>>> a worker thread can use to identify which pages have been hinted and
>>>>> which pages have not.
>>>> Can you please explain what do you mean by truly asynchronous?
>>>>
>>>> With this implementation also I am not reporting the pages synchronously.
>>> The problem is you are making it pseudo synchronous by having to push
>>> pages off to a side buffer aren't you? In my mind we should be able to
>>> have the page hinting go on with little to no interference with
>>> existing page allocation and freeing.
>> We have to opt one of the two options:
>> 1. Block allocation by using a flag or acquire a lock to prevent the
>> usage of pages we are hinting.
>> 2. Remove the page set entirely from the buddy. (This is what I am doing
>> right now)
>>
>> The reason I would prefer the second approach is that we are not
>> blocking the allocation in any way and as we are only working with a
>> smaller set of pages we should be fine.
>> However, with the current approach as we are reporting asynchronously
>> there is a chance that we end up hinting more than 2-3 times for a
>> single workload run. In situation where this could lead to low memory
>> condition in the guest, the hinting will anyways fail as the guest will
>> not allow page isolation.
>> I can possibly try and test the same to ensure that we don't get OOM due
>> to hinting when the guest is under memory pressure.
> 
> So in either case you are essentially blocking allocation since the
> memory cannot be used. My concern is more with guaranteeing forward
> progress for as many CPUs as possible.
> 
> With your current design you have one minor issue in that you aren't
> taking the lock to re-insert the pages back into the buddy allocator.
> When you add that step in it means you are going to be blocking
> allocation on that zone while you are reinserting the pages.
> 
> Also right now you are using the calls to free_one_page to generate a
> list of hints where to search. I'm thinking that may not be the best
> approach since what we want to do is provide hints on idle free pages,
> not just pages that will be free for a short period of time.
> 
> To that end what I think w may want to do is instead just walk the LRU
> list for a given zone/order in reverse order so that we can try to
> identify the pages that are most likely to be cold and unused and
> those are the first ones we want to be hinting on rather than the ones
> that were just freed. If we can look at doing something like adding a
> jiffies value to the page indicating when it was last freed we could
> even have a good point for determining when we should stop processing
> pages in a given zone/order list.
> 
> In reality the approach wouldn't be too different from what you are
> doing now, the only real difference would be that we would just want
> to walk the LRU list for the given zone/order rather then pulling
> hints on what to free from the calls to free_one_page. In addition we
> would need to add a couple bits to indicate if the page has been
> hinted on, is in the middle of getting hinted on, and something such
> as the jiffies value I mentioned which we could use to determine how
> old the page is.
> 
>>>
>>>>> Then we can have that one thread just walking
>>>>> through the zone memory pulling out fixed size pieces at a time and
>>>>> providing hints on that. By doing that we avoid the potential of
>>>>> creating a batch of pages that eat up most of the system memory.
>>>>>
>>>>>>         * Pages, captured in the per cpu array are sorted based on the zone numbers. This is to avoid redundancy of acquiring zone locks.
>>>>>>         * Dynamically allocated space is used to hold the isolated guest free pages.
>>>>> I have concerns that doing this per CPU and allocating memory
>>>>> dynamically can result in you losing a significant amount of memory as
>>>>> it sits waiting to be hinted.
>>>> It should not as the buddy will keep merging the pages and we are only
>>>> capturing MAX_ORDER - 1.
>>>> This was the issue with the last patch-series when I was capturing all
>>>> order pages resulting in the per-cpu array to be filled with lower order
>>>> pages.
>>>>>>         * All the pages are reported asynchronously to the host via virtio driver.
>>>>>>         * Pages are returned back to the guest buddy free list only when the host response is received.
>>>>> I have been thinking about this. Instead of stealing the page couldn't
>>>>> you simply flag it that there is a hint in progress and simply wait in
>>>>> arch_alloc_page until the hint has been processed?
>>>> With the flag, I am assuming you mean to block the allocation until
>>>> hinting is going on, which is an issue. That was one of the issues
>>>> discussed earlier which I wanted to solve with this implementation.
>>> With the flag we would allow the allocation, but would have to
>>> synchronize with the hinting at that point. I got the idea from the
>>> way the s390 code works. They have both an arch_free_page and an
>>> arch_alloc_page. If I understand correctly the arch_alloc_page is what
>>> is meant to handle the case of a page that has been marked for
>>> hinting, but may not have been hinted on yet. My thought for now is to
>>> keep it simple and use a page flag to indicate that a page is
>>> currently pending a hint.
>> I am assuming this page flag will be located in the page structure.
>>> We should be able to spin in such a case and
>>> it would probably still perform better than a solution where we would
>>> not have the memory available and possibly be under memory pressure.
>> I had this same idea earlier. However, the thing about which I was not
>> sure is if adding a flag in the page structure will be acceptable upstream.
>>>
>>>>> The problem is in
>>>>> stealing pages you are going to introduce false OOM issues when the
>>>>> memory isn't available because it is being hinted on.
>>>> I think this situation will arise when the guest is under memory
>>>> pressure. In such situations any attempt to perform isolation will
>>>> anyways fail and we may not be reporting anything at that time.
>>> What I want to avoid is the scenario where an application grabs a
>>> large amount of memory, then frees said memory, and we are sitting on
>>> it for some time because we decide to try and hint on the large chunk.
>> I agree.
>>> By processing this sometime after the pages are sent to the buddy
>>> allocator in a separate thread, and by processing a small fixed window
>>> of memory at a time we can avoid making freeing memory expensive, and
>>> still provide the hints in a reasonable time frame.
>>
>> My impression is that the current window on which I am working may give
>> issues for smaller size guests. But otherwise, we are already working
>> with a smaller fixed window of memory.
>>
>> I can further restrict this to just 128 entries and test which would
>> bring down the window of memory. Let me know what you think.
> 
> The problem is 128 entries is still pretty big when you consider you
> are working with 4M pages. If I am not mistaken that is a half
> gigabyte of memory. For lower order pages 128 would probably be fine,
> but with the higher order pages we may want to contain things to
> something smaller like 16MB to 64MB worth of memory.
>

I agree, I also still consider it too big for 4MB pages. It would be
different e.g. for 128KB pages.

-- 

Thanks,

David / dhildenb

Re: [RFC][Patch v9 0/6] KVM: Guest Free Page Hinting

[Alexander Duyck]

On Thu, Mar 7, 2019 at 10:53 AM Michael S. Tsirkin <mst@redhat.com> wrote:
>
> On Thu, Mar 07, 2019 at 10:45:58AM -0800, Alexander Duyck wrote:
> > To that end what I think w may want to do is instead just walk the LRU
> > list for a given zone/order in reverse order so that we can try to
> > identify the pages that are most likely to be cold and unused and
> > those are the first ones we want to be hinting on rather than the ones
> > that were just freed. If we can look at doing something like adding a
> > jiffies value to the page indicating when it was last freed we could
> > even have a good point for determining when we should stop processing
> > pages in a given zone/order list.
> >
> > In reality the approach wouldn't be too different from what you are
> > doing now, the only real difference would be that we would just want
> > to walk the LRU list for the given zone/order rather then pulling
> > hints on what to free from the calls to free_one_page. In addition we
> > would need to add a couple bits to indicate if the page has been
> > hinted on, is in the middle of getting hinted on, and something such
> > as the jiffies value I mentioned which we could use to determine how
> > old the page is.
>
> Do we really need bits in the page?
> Would it be bad to just have a separate hint list?

The issue is lists are expensive to search. If we have a single bit in
the page we can check it as soon as we have the page.

> If you run out of free memory you can check the hint
> list, if you find stuff there you can spin
> or kick the hypervisor to hurry up.

This implies you are keeping a separate list of pages for what has
been hinted on. If we are pulling pages out of the LRU list for that
it will require the zone lock to move the pages back and forth and for
higher core counts that isn't going to scale very well, and if you are
trying to pull out a page that is currently being hinted on you will
run into the same issue of having to wait for the hint to be completed
before proceeding.

> Core mm/ changes, so nothing's easy, I know.

We might be able to reuse some existing page flags. For example, there
is the PG_young and PG_idle flags that would actually be a pretty good
fit in terms of what we are looking for in behavior. We could set
PG_young when the page is initially freed, then clear it when we start
to perform the hint, and set PG_idle once the hint has been completed.

The check for if we could use a page would be pretty fast as a result
as well since if PG_young or PG_idle are set it means the page is free
to use so the check in arch_alloc_page would be pretty cheap since we
could probably test for both bits in one read.

Re: [RFC][Patch v9 0/6] KVM: Guest Free Page Hinting

[David Hildenbrand]

On 07.03.19 22:14, Alexander Duyck wrote:
> On Thu, Mar 7, 2019 at 10:53 AM Michael S. Tsirkin <mst@redhat.com> wrote:
>>
>> On Thu, Mar 07, 2019 at 10:45:58AM -0800, Alexander Duyck wrote:
>>> To that end what I think w may want to do is instead just walk the LRU
>>> list for a given zone/order in reverse order so that we can try to
>>> identify the pages that are most likely to be cold and unused and
>>> those are the first ones we want to be hinting on rather than the ones
>>> that were just freed. If we can look at doing something like adding a
>>> jiffies value to the page indicating when it was last freed we could
>>> even have a good point for determining when we should stop processing
>>> pages in a given zone/order list.
>>>
>>> In reality the approach wouldn't be too different from what you are
>>> doing now, the only real difference would be that we would just want
>>> to walk the LRU list for the given zone/order rather then pulling
>>> hints on what to free from the calls to free_one_page. In addition we
>>> would need to add a couple bits to indicate if the page has been
>>> hinted on, is in the middle of getting hinted on, and something such
>>> as the jiffies value I mentioned which we could use to determine how
>>> old the page is.
>>
>> Do we really need bits in the page?
>> Would it be bad to just have a separate hint list?
> 
> The issue is lists are expensive to search. If we have a single bit in
> the page we can check it as soon as we have the page.
> 
>> If you run out of free memory you can check the hint
>> list, if you find stuff there you can spin
>> or kick the hypervisor to hurry up.
> 
> This implies you are keeping a separate list of pages for what has
> been hinted on. If we are pulling pages out of the LRU list for that
> it will require the zone lock to move the pages back and forth and for
> higher core counts that isn't going to scale very well, and if you are
> trying to pull out a page that is currently being hinted on you will
> run into the same issue of having to wait for the hint to be completed
> before proceeding.
> 
>> Core mm/ changes, so nothing's easy, I know.
> 
> We might be able to reuse some existing page flags. For example, there
> is the PG_young and PG_idle flags that would actually be a pretty good
> fit in terms of what we are looking for in behavior. We could set
> PG_young when the page is initially freed, then clear it when we start
> to perform the hint, and set PG_idle once the hint has been completed.

Just noting that when hinting, we have to set all affected sub-page bits
as far as I see.

> 
> The check for if we could use a page would be pretty fast as a result
> as well since if PG_young or PG_idle are set it means the page is free
> to use so the check in arch_alloc_page would be pretty cheap since we
> could probably test for both bits in one read.
> 

I still dislike spinning on ordinary allocation paths. If we want to go
that way, core mm has to consider these bits and try other pages first.

-- 

Thanks,

David / dhildenb

Re: [RFC][Patch v9 2/6] KVM: Enables the kernel to isolate guest free pages

[Alexander Duyck]

On Thu, Mar 7, 2019 at 11:30 AM David Hildenbrand <david@redhat.com> wrote:
>
> On 07.03.19 20:23, Nitesh Narayan Lal wrote:
> >
> > On 3/7/19 1:30 PM, Alexander Duyck wrote:
> >> On Wed, Mar 6, 2019 at 7:51 AM Nitesh Narayan Lal <nitesh@redhat.com> wrote:
> >>> This patch enables the kernel to scan the per cpu array
> >>> which carries head pages from the buddy free list of order
> >>> FREE_PAGE_HINTING_MIN_ORDER (MAX_ORDER - 1) by
> >>> guest_free_page_hinting().
> >>> guest_free_page_hinting() scans the entire per cpu array by
> >>> acquiring a zone lock corresponding to the pages which are
> >>> being scanned. If the page is still free and present in the
> >>> buddy it tries to isolate the page and adds it to a
> >>> dynamically allocated array.
> >>>
> >>> Once this scanning process is complete and if there are any
> >>> isolated pages added to the dynamically allocated array
> >>> guest_free_page_report() is invoked. However, before this the
> >>> per-cpu array index is reset so that it can continue capturing
> >>> the pages from buddy free list.
> >>>
> >>> In this patch guest_free_page_report() simply releases the pages back
> >>> to the buddy by using __free_one_page()
> >>>
> >>> Signed-off-by: Nitesh Narayan Lal <nitesh@redhat.com>
> >> I'm pretty sure this code is not thread safe and has a few various issues.
> >>
> >>> ---
> >>>  include/linux/page_hinting.h |   5 ++
> >>>  mm/page_alloc.c              |   2 +-
> >>>  virt/kvm/page_hinting.c      | 154 +++++++++++++++++++++++++++++++++++
> >>>  3 files changed, 160 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/include/linux/page_hinting.h b/include/linux/page_hinting.h
> >>> index 90254c582789..d554a2581826 100644
> >>> --- a/include/linux/page_hinting.h
> >>> +++ b/include/linux/page_hinting.h
> >>> @@ -13,3 +13,8 @@
> >>>
> >>>  void guest_free_page_enqueue(struct page *page, int order);
> >>>  void guest_free_page_try_hinting(void);
> >>> +extern int __isolate_free_page(struct page *page, unsigned int order);
> >>> +extern void __free_one_page(struct page *page, unsigned long pfn,
> >>> +                           struct zone *zone, unsigned int order,
> >>> +                           int migratetype);
> >>> +void release_buddy_pages(void *obj_to_free, int entries);
> >>> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> >>> index 684d047f33ee..d38b7eea207b 100644
> >>> --- a/mm/page_alloc.c
> >>> +++ b/mm/page_alloc.c
> >>> @@ -814,7 +814,7 @@ static inline int page_is_buddy(struct page *page, struct page *buddy,
> >>>   * -- nyc
> >>>   */
> >>>
> >>> -static inline void __free_one_page(struct page *page,
> >>> +inline void __free_one_page(struct page *page,
> >>>                 unsigned long pfn,
> >>>                 struct zone *zone, unsigned int order,
> >>>                 int migratetype)
> >>> diff --git a/virt/kvm/page_hinting.c b/virt/kvm/page_hinting.c
> >>> index 48b4b5e796b0..9885b372b5a9 100644
> >>> --- a/virt/kvm/page_hinting.c
> >>> +++ b/virt/kvm/page_hinting.c
> >>> @@ -1,5 +1,9 @@
> >>>  #include <linux/mm.h>
> >>>  #include <linux/page_hinting.h>
> >>> +#include <linux/page_ref.h>
> >>> +#include <linux/kvm_host.h>
> >>> +#include <linux/kernel.h>
> >>> +#include <linux/sort.h>
> >>>
> >>>  /*
> >>>   * struct guest_free_pages- holds array of guest freed PFN's along with an
> >>> @@ -16,6 +20,54 @@ struct guest_free_pages {
> >>>
> >>>  DEFINE_PER_CPU(struct guest_free_pages, free_pages_obj);
> >>>
> >>> +/*
> >>> + * struct guest_isolated_pages- holds the buddy isolated pages which are
> >>> + * supposed to be freed by the host.
> >>> + * @pfn: page frame number for the isolated page.
> >>> + * @order: order of the isolated page.
> >>> + */
> >>> +struct guest_isolated_pages {
> >>> +       unsigned long pfn;
> >>> +       unsigned int order;
> >>> +};
> >>> +
> >>> +void release_buddy_pages(void *obj_to_free, int entries)
> >>> +{
> >>> +       int i = 0;
> >>> +       int mt = 0;
> >>> +       struct guest_isolated_pages *isolated_pages_obj = obj_to_free;
> >>> +
> >>> +       while (i < entries) {
> >>> +               struct page *page = pfn_to_page(isolated_pages_obj[i].pfn);
> >>> +
> >>> +               mt = get_pageblock_migratetype(page);
> >>> +               __free_one_page(page, page_to_pfn(page), page_zone(page),
> >>> +                               isolated_pages_obj[i].order, mt);
> >>> +               i++;
> >>> +       }
> >>> +       kfree(isolated_pages_obj);
> >>> +}
> >> You shouldn't be accessing __free_one_page without holding the zone
> >> lock for the page. You might consider confining yourself to one zone
> >> worth of hints at a time. Then you can acquire the lock once, and then
> >> return the memory you have freed.
> > That is correct.
> >>
> >> This is one of the reasons why I am thinking maybe a bit in the page
> >> and then spinning on that bit in arch_alloc_page might be a nice way
> >> to get around this. Then you only have to take the zone lock when you
> >> are finding the pages you want to hint on and setting the bit
> >> indicating they are mid hint. Otherwise you have to take the zone lock
> >> to pull pages out, and to put them back in and the likelihood of a
> >> lock collision is much higher.
> > Do you think adding a new flag to the page structure will be acceptable?
>
> My lesson learned: forget it. If (at all) reuse some other one that
> might be safe in that context. Hard to tell if that is even possible and
> will be accepted upstream.

I was thinking we could probably just resort to reuse. Essentially
what we are looking at doing is idle page tracking so my thought is to
see if we can just reuse those bits in the buddy allocator. Then we
would essentially have 3 stages, young, "hinting", and idle.

> Spinning is not the solution. What you would want is the buddy to
> actually skip over these pages and only try to use them (-> spin) when
> OOM. Core mm changes (see my other reply).

It is more of a workaround. Ideally we should almost never encounter
this anyway as what we really want to be doing is performing hints on
cold pages, so hopefully we will be on the other end of the LRU list
from any active allocations.

> This all sounds like future work which can be built on top of this work.

Actually I was kind of thinking about this the other way. The simple
spin approach is a good first step. If we have a bit or two in the
page that tells us if the page is available or not we could then
follow-up with optimizations to only allocate either a young or idle
page and doesn't bother with pages being "hinted", at least in the
first pass.

As it currently stands we are only really performing hints on higher
order pages anyway so if we happen to encounter a slight delay under
memory pressure it probably wouldn't be that noticeable versus the
memory system having to go through and try to compact things from some
lower order pages. In my mind us introducing a delay in memory
allocation in the case of a collision would be preferable versus us
triggering allocation failures.

Re: [RFC][Patch v9 2/6] KVM: Enables the kernel to isolate guest free pages

[David Hildenbrand]

On 07.03.19 22:32, Alexander Duyck wrote:
> On Thu, Mar 7, 2019 at 11:30 AM David Hildenbrand <david@redhat.com> wrote:
>>
>> On 07.03.19 20:23, Nitesh Narayan Lal wrote:
>>>
>>> On 3/7/19 1:30 PM, Alexander Duyck wrote:
>>>> On Wed, Mar 6, 2019 at 7:51 AM Nitesh Narayan Lal <nitesh@redhat.com> wrote:
>>>>> This patch enables the kernel to scan the per cpu array
>>>>> which carries head pages from the buddy free list of order
>>>>> FREE_PAGE_HINTING_MIN_ORDER (MAX_ORDER - 1) by
>>>>> guest_free_page_hinting().
>>>>> guest_free_page_hinting() scans the entire per cpu array by
>>>>> acquiring a zone lock corresponding to the pages which are
>>>>> being scanned. If the page is still free and present in the
>>>>> buddy it tries to isolate the page and adds it to a
>>>>> dynamically allocated array.
>>>>>
>>>>> Once this scanning process is complete and if there are any
>>>>> isolated pages added to the dynamically allocated array
>>>>> guest_free_page_report() is invoked. However, before this the
>>>>> per-cpu array index is reset so that it can continue capturing
>>>>> the pages from buddy free list.
>>>>>
>>>>> In this patch guest_free_page_report() simply releases the pages back
>>>>> to the buddy by using __free_one_page()
>>>>>
>>>>> Signed-off-by: Nitesh Narayan Lal <nitesh@redhat.com>
>>>> I'm pretty sure this code is not thread safe and has a few various issues.
>>>>
>>>>> ---
>>>>>  include/linux/page_hinting.h |   5 ++
>>>>>  mm/page_alloc.c              |   2 +-
>>>>>  virt/kvm/page_hinting.c      | 154 +++++++++++++++++++++++++++++++++++
>>>>>  3 files changed, 160 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/include/linux/page_hinting.h b/include/linux/page_hinting.h
>>>>> index 90254c582789..d554a2581826 100644
>>>>> --- a/include/linux/page_hinting.h
>>>>> +++ b/include/linux/page_hinting.h
>>>>> @@ -13,3 +13,8 @@
>>>>>
>>>>>  void guest_free_page_enqueue(struct page *page, int order);
>>>>>  void guest_free_page_try_hinting(void);
>>>>> +extern int __isolate_free_page(struct page *page, unsigned int order);
>>>>> +extern void __free_one_page(struct page *page, unsigned long pfn,
>>>>> +                           struct zone *zone, unsigned int order,
>>>>> +                           int migratetype);
>>>>> +void release_buddy_pages(void *obj_to_free, int entries);
>>>>> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
>>>>> index 684d047f33ee..d38b7eea207b 100644
>>>>> --- a/mm/page_alloc.c
>>>>> +++ b/mm/page_alloc.c
>>>>> @@ -814,7 +814,7 @@ static inline int page_is_buddy(struct page *page, struct page *buddy,
>>>>>   * -- nyc
>>>>>   */
>>>>>
>>>>> -static inline void __free_one_page(struct page *page,
>>>>> +inline void __free_one_page(struct page *page,
>>>>>                 unsigned long pfn,
>>>>>                 struct zone *zone, unsigned int order,
>>>>>                 int migratetype)
>>>>> diff --git a/virt/kvm/page_hinting.c b/virt/kvm/page_hinting.c
>>>>> index 48b4b5e796b0..9885b372b5a9 100644
>>>>> --- a/virt/kvm/page_hinting.c
>>>>> +++ b/virt/kvm/page_hinting.c
>>>>> @@ -1,5 +1,9 @@
>>>>>  #include <linux/mm.h>
>>>>>  #include <linux/page_hinting.h>
>>>>> +#include <linux/page_ref.h>
>>>>> +#include <linux/kvm_host.h>
>>>>> +#include <linux/kernel.h>
>>>>> +#include <linux/sort.h>
>>>>>
>>>>>  /*
>>>>>   * struct guest_free_pages- holds array of guest freed PFN's along with an
>>>>> @@ -16,6 +20,54 @@ struct guest_free_pages {
>>>>>
>>>>>  DEFINE_PER_CPU(struct guest_free_pages, free_pages_obj);
>>>>>
>>>>> +/*
>>>>> + * struct guest_isolated_pages- holds the buddy isolated pages which are
>>>>> + * supposed to be freed by the host.
>>>>> + * @pfn: page frame number for the isolated page.
>>>>> + * @order: order of the isolated page.
>>>>> + */
>>>>> +struct guest_isolated_pages {
>>>>> +       unsigned long pfn;
>>>>> +       unsigned int order;
>>>>> +};
>>>>> +
>>>>> +void release_buddy_pages(void *obj_to_free, int entries)
>>>>> +{
>>>>> +       int i = 0;
>>>>> +       int mt = 0;
>>>>> +       struct guest_isolated_pages *isolated_pages_obj = obj_to_free;
>>>>> +
>>>>> +       while (i < entries) {
>>>>> +               struct page *page = pfn_to_page(isolated_pages_obj[i].pfn);
>>>>> +
>>>>> +               mt = get_pageblock_migratetype(page);
>>>>> +               __free_one_page(page, page_to_pfn(page), page_zone(page),
>>>>> +                               isolated_pages_obj[i].order, mt);
>>>>> +               i++;
>>>>> +       }
>>>>> +       kfree(isolated_pages_obj);
>>>>> +}
>>>> You shouldn't be accessing __free_one_page without holding the zone
>>>> lock for the page. You might consider confining yourself to one zone
>>>> worth of hints at a time. Then you can acquire the lock once, and then
>>>> return the memory you have freed.
>>> That is correct.
>>>>
>>>> This is one of the reasons why I am thinking maybe a bit in the page
>>>> and then spinning on that bit in arch_alloc_page might be a nice way
>>>> to get around this. Then you only have to take the zone lock when you
>>>> are finding the pages you want to hint on and setting the bit
>>>> indicating they are mid hint. Otherwise you have to take the zone lock
>>>> to pull pages out, and to put them back in and the likelihood of a
>>>> lock collision is much higher.
>>> Do you think adding a new flag to the page structure will be acceptable?
>>
>> My lesson learned: forget it. If (at all) reuse some other one that
>> might be safe in that context. Hard to tell if that is even possible and
>> will be accepted upstream.
> 
> I was thinking we could probably just resort to reuse. Essentially
> what we are looking at doing is idle page tracking so my thought is to
> see if we can just reuse those bits in the buddy allocator. Then we
> would essentially have 3 stages, young, "hinting", and idle.

Haven't thought this through, but I wonder if 2 stages would even be
enough right now, But well, you have a point that idle *might* reduce
the amount of pages hinted multiple time (although that might still
happen when we want to hint with different page sizes / buddy merging).

> 
>> Spinning is not the solution. What you would want is the buddy to
>> actually skip over these pages and only try to use them (-> spin) when
>> OOM. Core mm changes (see my other reply).
> 
> It is more of a workaround. Ideally we should almost never encounter
> this anyway as what we really want to be doing is performing hints on
> cold pages, so hopefully we will be on the other end of the LRU list
> from any active allocations.
> 
>> This all sounds like future work which can be built on top of this work.
> 
> Actually I was kind of thinking about this the other way. The simple
> spin approach is a good first step. If we have a bit or two in the
> page that tells us if the page is available or not we could then
> follow-up with optimizations to only allocate either a young or idle
> page and doesn't bother with pages being "hinted", at least in the
> first pass.
> 
> As it currently stands we are only really performing hints on higher
> order pages anyway so if we happen to encounter a slight delay under
> memory pressure it probably wouldn't be that noticeable versus the

Well, the issue is that with your approach one pending hinting request
might block all other VCPUs in the worst case until hitning is done.
Something that is not possible with Niteshs approach. It will never
block allocation paths (well apart from the zone lock and the OOM
thingy). And I think this is important.

It is a fundamental design problem until we fix core mm. Your other
synchronous approach doesn't have this problem either.

> memory system having to go through and try to compact things from some
> lower order pages. In my mind us introducing a delay in memory
> allocation in the case of a collision would be preferable versus us
> triggering allocation failures.
> 

Valid points, I think to see which approach would be the better starting
point is to have a version that does what you propose and compare it.
Essentially to find out how severe this "blocking other VCPUs" thingy
can be.

-- 

Thanks,

David / dhildenb

Re: [RFC][Patch v9 0/6] KVM: Guest Free Page Hinting

[Alexander Duyck]

On Thu, Mar 7, 2019 at 1:28 PM David Hildenbrand <david@redhat.com> wrote:
>
> On 07.03.19 22:14, Alexander Duyck wrote:
> > On Thu, Mar 7, 2019 at 10:53 AM Michael S. Tsirkin <mst@redhat.com> wrote:
> >>
> >> On Thu, Mar 07, 2019 at 10:45:58AM -0800, Alexander Duyck wrote:
> >>> To that end what I think w may want to do is instead just walk the LRU
> >>> list for a given zone/order in reverse order so that we can try to
> >>> identify the pages that are most likely to be cold and unused and
> >>> those are the first ones we want to be hinting on rather than the ones
> >>> that were just freed. If we can look at doing something like adding a
> >>> jiffies value to the page indicating when it was last freed we could
> >>> even have a good point for determining when we should stop processing
> >>> pages in a given zone/order list.
> >>>
> >>> In reality the approach wouldn't be too different from what you are
> >>> doing now, the only real difference would be that we would just want
> >>> to walk the LRU list for the given zone/order rather then pulling
> >>> hints on what to free from the calls to free_one_page. In addition we
> >>> would need to add a couple bits to indicate if the page has been
> >>> hinted on, is in the middle of getting hinted on, and something such
> >>> as the jiffies value I mentioned which we could use to determine how
> >>> old the page is.
> >>
> >> Do we really need bits in the page?
> >> Would it be bad to just have a separate hint list?
> >
> > The issue is lists are expensive to search. If we have a single bit in
> > the page we can check it as soon as we have the page.
> >
> >> If you run out of free memory you can check the hint
> >> list, if you find stuff there you can spin
> >> or kick the hypervisor to hurry up.
> >
> > This implies you are keeping a separate list of pages for what has
> > been hinted on. If we are pulling pages out of the LRU list for that
> > it will require the zone lock to move the pages back and forth and for
> > higher core counts that isn't going to scale very well, and if you are
> > trying to pull out a page that is currently being hinted on you will
> > run into the same issue of having to wait for the hint to be completed
> > before proceeding.
> >
> >> Core mm/ changes, so nothing's easy, I know.
> >
> > We might be able to reuse some existing page flags. For example, there
> > is the PG_young and PG_idle flags that would actually be a pretty good
> > fit in terms of what we are looking for in behavior. We could set
> > PG_young when the page is initially freed, then clear it when we start
> > to perform the hint, and set PG_idle once the hint has been completed.
>
> Just noting that when hinting, we have to set all affected sub-page bits
> as far as I see.

You may be correct there. One thing I hadn't thought about is what
happens if the page is split or merged up to a higher order. I guess I
could be talked into being okay with a side list that we maintain a
few pages in that are isolated from the rest.

> >
> > The check for if we could use a page would be pretty fast as a result
> > as well since if PG_young or PG_idle are set it means the page is free
> > to use so the check in arch_alloc_page would be pretty cheap since we
> > could probably test for both bits in one read.
> >
>
> I still dislike spinning on ordinary allocation paths. If we want to go
> that way, core mm has to consider these bits and try other pages first.

Agreed. I was just thinking that would be follow-on work since in my
mind the collision rate for these should be low.

Re: [RFC][Patch v9 2/6] KVM: Enables the kernel to isolate guest free pages

[Alexander Duyck]

On Thu, Mar 7, 2019 at 1:40 PM David Hildenbrand <david@redhat.com> wrote:
>
> On 07.03.19 22:32, Alexander Duyck wrote:
> > On Thu, Mar 7, 2019 at 11:30 AM David Hildenbrand <david@redhat.com> wrote:
> >>
> >> On 07.03.19 20:23, Nitesh Narayan Lal wrote:
> >>>
> >>> On 3/7/19 1:30 PM, Alexander Duyck wrote:
> >>>> On Wed, Mar 6, 2019 at 7:51 AM Nitesh Narayan Lal <nitesh@redhat.com> wrote:
> >>>>> This patch enables the kernel to scan the per cpu array
> >>>>> which carries head pages from the buddy free list of order
> >>>>> FREE_PAGE_HINTING_MIN_ORDER (MAX_ORDER - 1) by
> >>>>> guest_free_page_hinting().
> >>>>> guest_free_page_hinting() scans the entire per cpu array by
> >>>>> acquiring a zone lock corresponding to the pages which are
> >>>>> being scanned. If the page is still free and present in the
> >>>>> buddy it tries to isolate the page and adds it to a
> >>>>> dynamically allocated array.
> >>>>>
> >>>>> Once this scanning process is complete and if there are any
> >>>>> isolated pages added to the dynamically allocated array
> >>>>> guest_free_page_report() is invoked. However, before this the
> >>>>> per-cpu array index is reset so that it can continue capturing
> >>>>> the pages from buddy free list.
> >>>>>
> >>>>> In this patch guest_free_page_report() simply releases the pages back
> >>>>> to the buddy by using __free_one_page()
> >>>>>
> >>>>> Signed-off-by: Nitesh Narayan Lal <nitesh@redhat.com>
> >>>> I'm pretty sure this code is not thread safe and has a few various issues.
> >>>>
> >>>>> ---
> >>>>>  include/linux/page_hinting.h |   5 ++
> >>>>>  mm/page_alloc.c              |   2 +-
> >>>>>  virt/kvm/page_hinting.c      | 154 +++++++++++++++++++++++++++++++++++
> >>>>>  3 files changed, 160 insertions(+), 1 deletion(-)
> >>>>>
> >>>>> diff --git a/include/linux/page_hinting.h b/include/linux/page_hinting.h
> >>>>> index 90254c582789..d554a2581826 100644
> >>>>> --- a/include/linux/page_hinting.h
> >>>>> +++ b/include/linux/page_hinting.h
> >>>>> @@ -13,3 +13,8 @@
> >>>>>
> >>>>>  void guest_free_page_enqueue(struct page *page, int order);
> >>>>>  void guest_free_page_try_hinting(void);
> >>>>> +extern int __isolate_free_page(struct page *page, unsigned int order);
> >>>>> +extern void __free_one_page(struct page *page, unsigned long pfn,
> >>>>> +                           struct zone *zone, unsigned int order,
> >>>>> +                           int migratetype);
> >>>>> +void release_buddy_pages(void *obj_to_free, int entries);
> >>>>> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> >>>>> index 684d047f33ee..d38b7eea207b 100644
> >>>>> --- a/mm/page_alloc.c
> >>>>> +++ b/mm/page_alloc.c
> >>>>> @@ -814,7 +814,7 @@ static inline int page_is_buddy(struct page *page, struct page *buddy,
> >>>>>   * -- nyc
> >>>>>   */
> >>>>>
> >>>>> -static inline void __free_one_page(struct page *page,
> >>>>> +inline void __free_one_page(struct page *page,
> >>>>>                 unsigned long pfn,
> >>>>>                 struct zone *zone, unsigned int order,
> >>>>>                 int migratetype)
> >>>>> diff --git a/virt/kvm/page_hinting.c b/virt/kvm/page_hinting.c
> >>>>> index 48b4b5e796b0..9885b372b5a9 100644
> >>>>> --- a/virt/kvm/page_hinting.c
> >>>>> +++ b/virt/kvm/page_hinting.c
> >>>>> @@ -1,5 +1,9 @@
> >>>>>  #include <linux/mm.h>
> >>>>>  #include <linux/page_hinting.h>
> >>>>> +#include <linux/page_ref.h>
> >>>>> +#include <linux/kvm_host.h>
> >>>>> +#include <linux/kernel.h>
> >>>>> +#include <linux/sort.h>
> >>>>>
> >>>>>  /*
> >>>>>   * struct guest_free_pages- holds array of guest freed PFN's along with an
> >>>>> @@ -16,6 +20,54 @@ struct guest_free_pages {
> >>>>>
> >>>>>  DEFINE_PER_CPU(struct guest_free_pages, free_pages_obj);
> >>>>>
> >>>>> +/*
> >>>>> + * struct guest_isolated_pages- holds the buddy isolated pages which are
> >>>>> + * supposed to be freed by the host.
> >>>>> + * @pfn: page frame number for the isolated page.
> >>>>> + * @order: order of the isolated page.
> >>>>> + */
> >>>>> +struct guest_isolated_pages {
> >>>>> +       unsigned long pfn;
> >>>>> +       unsigned int order;
> >>>>> +};
> >>>>> +
> >>>>> +void release_buddy_pages(void *obj_to_free, int entries)
> >>>>> +{
> >>>>> +       int i = 0;
> >>>>> +       int mt = 0;
> >>>>> +       struct guest_isolated_pages *isolated_pages_obj = obj_to_free;
> >>>>> +
> >>>>> +       while (i < entries) {
> >>>>> +               struct page *page = pfn_to_page(isolated_pages_obj[i].pfn);
> >>>>> +
> >>>>> +               mt = get_pageblock_migratetype(page);
> >>>>> +               __free_one_page(page, page_to_pfn(page), page_zone(page),
> >>>>> +                               isolated_pages_obj[i].order, mt);
> >>>>> +               i++;
> >>>>> +       }
> >>>>> +       kfree(isolated_pages_obj);
> >>>>> +}
> >>>> You shouldn't be accessing __free_one_page without holding the zone
> >>>> lock for the page. You might consider confining yourself to one zone
> >>>> worth of hints at a time. Then you can acquire the lock once, and then
> >>>> return the memory you have freed.
> >>> That is correct.
> >>>>
> >>>> This is one of the reasons why I am thinking maybe a bit in the page
> >>>> and then spinning on that bit in arch_alloc_page might be a nice way
> >>>> to get around this. Then you only have to take the zone lock when you
> >>>> are finding the pages you want to hint on and setting the bit
> >>>> indicating they are mid hint. Otherwise you have to take the zone lock
> >>>> to pull pages out, and to put them back in and the likelihood of a
> >>>> lock collision is much higher.
> >>> Do you think adding a new flag to the page structure will be acceptable?
> >>
> >> My lesson learned: forget it. If (at all) reuse some other one that
> >> might be safe in that context. Hard to tell if that is even possible and
> >> will be accepted upstream.
> >
> > I was thinking we could probably just resort to reuse. Essentially
> > what we are looking at doing is idle page tracking so my thought is to
> > see if we can just reuse those bits in the buddy allocator. Then we
> > would essentially have 3 stages, young, "hinting", and idle.
>
> Haven't thought this through, but I wonder if 2 stages would even be
> enough right now, But well, you have a point that idle *might* reduce
> the amount of pages hinted multiple time (although that might still
> happen when we want to hint with different page sizes / buddy merging).

Splitting wouldn't be so much an issue as merging. The problem is if
you are merging pages you have to assume the page is no longer hinted,
and need to hint for the new higher order page. The worst case
scenerio would be a page that is hinted, merged, split, and then has
to be hinted again because the information on hit being hinted is
lost.

> >
> >> Spinning is not the solution. What you would want is the buddy to
> >> actually skip over these pages and only try to use them (-> spin) when
> >> OOM. Core mm changes (see my other reply).
> >
> > It is more of a workaround. Ideally we should almost never encounter
> > this anyway as what we really want to be doing is performing hints on
> > cold pages, so hopefully we will be on the other end of the LRU list
> > from any active allocations.
> >
> >> This all sounds like future work which can be built on top of this work.
> >
> > Actually I was kind of thinking about this the other way. The simple
> > spin approach is a good first step. If we have a bit or two in the
> > page that tells us if the page is available or not we could then
> > follow-up with optimizations to only allocate either a young or idle
> > page and doesn't bother with pages being "hinted", at least in the
> > first pass.
> >
> > As it currently stands we are only really performing hints on higher
> > order pages anyway so if we happen to encounter a slight delay under
> > memory pressure it probably wouldn't be that noticeable versus the
>
> Well, the issue is that with your approach one pending hinting request
> might block all other VCPUs in the worst case until hitning is done.
> Something that is not possible with Niteshs approach. It will never
> block allocation paths (well apart from the zone lock and the OOM
> thingy). And I think this is important.
>
> It is a fundamental design problem until we fix core mm. Your other
> synchronous approach doesn't have this problem either.

Even with the approach I had there are still possibilities for all
VCPUs eventually becoming hung if the host is holding the write lock
on the mmap semaphore.

My initial thought was to try and reduce the amount of time we need to
sit on the zone lock since we have to hold it to isolate the pages,
and then to put them back in the buddy. However the idle bits approach
will be just as difficult to deal with due to potential for splits and
merges while performing the hint.

> > memory system having to go through and try to compact things from some
> > lower order pages. In my mind us introducing a delay in memory
> > allocation in the case of a collision would be preferable versus us
> > triggering allocation failures.
> >
>
> Valid points, I think to see which approach would be the better starting
> point is to have a version that does what you propose and compare it.
> Essentially to find out how severe this "blocking other VCPUs" thingy
> can be.

I figure if nothing else the current solution probably is just in need
of a few tweaks. In my mind the simplest solution is still to have a
single bit somewhere for tracking what pages we have hinted on on
which ones we haven't. However we could probably skip the second bit
and just put the pages in isolation while we are performing the hint
and that would get rid of the need for a second bit.

With us hinting currently on MAX_ORDER - 1 pages only that actually
takes care of the risk of a merge really wiping out any data about
what has been hinted on and what hasn't.

The only other thing I still want to try and see if I can do is to add
a jiffies value to the page private data in the case of the buddy
pages. With that we could track the age of the page so it becomes
easier to only target pages that are truly going cold rather than
trying to grab pages that were added to the freelist recently.

Re: [RFC][Patch v9 0/6] KVM: Guest Free Page Hinting

[Michael S. Tsirkin]

On Thu, Mar 07, 2019 at 08:27:32PM +0100, David Hildenbrand wrote:
> On 07.03.19 19:53, Michael S. Tsirkin wrote:
> > On Thu, Mar 07, 2019 at 10:45:58AM -0800, Alexander Duyck wrote:
> >> To that end what I think w may want to do is instead just walk the LRU
> >> list for a given zone/order in reverse order so that we can try to
> >> identify the pages that are most likely to be cold and unused and
> >> those are the first ones we want to be hinting on rather than the ones
> >> that were just freed. If we can look at doing something like adding a
> >> jiffies value to the page indicating when it was last freed we could
> >> even have a good point for determining when we should stop processing
> >> pages in a given zone/order list.
> >>
> >> In reality the approach wouldn't be too different from what you are
> >> doing now, the only real difference would be that we would just want
> >> to walk the LRU list for the given zone/order rather then pulling
> >> hints on what to free from the calls to free_one_page. In addition we
> >> would need to add a couple bits to indicate if the page has been
> >> hinted on, is in the middle of getting hinted on, and something such
> >> as the jiffies value I mentioned which we could use to determine how
> >> old the page is.
> > 
> > Do we really need bits in the page?
> > Would it be bad to just have a separate hint list?
> > 
> > If you run out of free memory you can check the hint
> > list, if you find stuff there you can spin
> > or kick the hypervisor to hurry up.
> > 
> > Core mm/ changes, so nothing's easy, I know.
> 
> We evaluated the idea of busy spinning on some bit/list entry a while
> ago. While it sounds interesting, it is usually not what we want and has
> other negative performance impacts.
> 
> Talking about "marking" pages, what we actually would want is to rework
> the buddy to skip over these "marked" pages and only really spin in case
> there are no other pages left. Allocation paths should only ever be
> blocked if OOM, not if just some hinting activity is going on on another
> VCPU.
> 
> However as you correctly say: "core mm changes". New page flag?
> Basically impossible.

Well not exactly. page bits are at a premium but only for
*allocated* pages. pages in the buddy are free and there are
some unused bits for these.

> Reuse another one? Can easily get horrbily
> confusing and can easily get rejected upstream. What about the buddy
> wanting to merge pages that are marked (assuming we also want something
> < MAX_ORDER - 1)? This smells like possibly heavy core mm changes.
> 
> Lesson learned: Avoid such heavy changes. Especially in the first shot.
> 
> The interesting thing about Nitesh's aproach right now is that we can
> easily rework these details later on. The host->guest interface will
> stay the same. Instead of temporarily taking pages out of the buddy, we
> could e.g. mark them and make the buddy or other users skip over them.
> 
> -- 
> 
> Thanks,
> 
> David / dhildenb

Re: [RFC][Patch v9 2/6] KVM: Enables the kernel to isolate guest free pages

[Michael S. Tsirkin]

On Thu, Mar 07, 2019 at 02:35:53PM -0800, Alexander Duyck wrote:
> With us hinting currently on MAX_ORDER - 1 pages only that actually
> takes care of the risk of a merge really wiping out any data about
> what has been hinted on and what hasn't.

Oh nice. I had this feeling MAX_ORDER - 1 specifically will
turn out being a better choice than something related to THP.
Now there's an actual reason why this makes things easier!

-- 
MST

Re: [RFC][Patch v9 2/6] KVM: Enables the kernel to isolate guest free pages

[Michael S. Tsirkin]

On Thu, Mar 07, 2019 at 02:35:53PM -0800, Alexander Duyck wrote:
> The only other thing I still want to try and see if I can do is to add
> a jiffies value to the page private data in the case of the buddy
> pages.

Actually there's one extra thing I think we should do, and that is make
sure we do not leave less than X% off the free memory at a time.
This way chances of triggering an OOM are lower.

> With that we could track the age of the page so it becomes
> easier to only target pages that are truly going cold rather than
> trying to grab pages that were added to the freelist recently.

I like that but I have a vague memory of discussing this with Rik van
Riel and him saying it's actually better to take away recently used
ones. Can't see why would that be but maybe I remember wrong. Rik - am I
just confused?


-- 
MST

Re: [RFC][Patch v9 0/6] KVM: Guest Free Page Hinting

[David Hildenbrand]

On 08.03.19 03:24, Michael S. Tsirkin wrote:
> On Thu, Mar 07, 2019 at 08:27:32PM +0100, David Hildenbrand wrote:
>> On 07.03.19 19:53, Michael S. Tsirkin wrote:
>>> On Thu, Mar 07, 2019 at 10:45:58AM -0800, Alexander Duyck wrote:
>>>> To that end what I think w may want to do is instead just walk the LRU
>>>> list for a given zone/order in reverse order so that we can try to
>>>> identify the pages that are most likely to be cold and unused and
>>>> those are the first ones we want to be hinting on rather than the ones
>>>> that were just freed. If we can look at doing something like adding a
>>>> jiffies value to the page indicating when it was last freed we could
>>>> even have a good point for determining when we should stop processing
>>>> pages in a given zone/order list.
>>>>
>>>> In reality the approach wouldn't be too different from what you are
>>>> doing now, the only real difference would be that we would just want
>>>> to walk the LRU list for the given zone/order rather then pulling
>>>> hints on what to free from the calls to free_one_page. In addition we
>>>> would need to add a couple bits to indicate if the page has been
>>>> hinted on, is in the middle of getting hinted on, and something such
>>>> as the jiffies value I mentioned which we could use to determine how
>>>> old the page is.
>>>
>>> Do we really need bits in the page?
>>> Would it be bad to just have a separate hint list?
>>>
>>> If you run out of free memory you can check the hint
>>> list, if you find stuff there you can spin
>>> or kick the hypervisor to hurry up.
>>>
>>> Core mm/ changes, so nothing's easy, I know.
>>
>> We evaluated the idea of busy spinning on some bit/list entry a while
>> ago. While it sounds interesting, it is usually not what we want and has
>> other negative performance impacts.
>>
>> Talking about "marking" pages, what we actually would want is to rework
>> the buddy to skip over these "marked" pages and only really spin in case
>> there are no other pages left. Allocation paths should only ever be
>> blocked if OOM, not if just some hinting activity is going on on another
>> VCPU.
>>
>> However as you correctly say: "core mm changes". New page flag?
>> Basically impossible.
> 
> Well not exactly. page bits are at a premium but only for
> *allocated* pages. pages in the buddy are free and there are
> some unused bits for these.
> 
As I said, we have to be very careful here.

Most parts of struct page can me modified by *the owner* of the page. In
case the page is online but not allocated, buddy is the owner. Not some
kvm/virtio thingy that hooks into some callback.

Manipulating random page bits of buddy pages in *some* kernel module I
consider problematic and will most probably not be accepted upstream.

What could work is, factoring out these parts e.g. into
mm/page_hinting.c, then it gets part of the core mm in some way. Which
would actually be a nice thing to do either way we go.


-- 

Thanks,

David / dhildenb

Re: [RFC][Patch v9 2/6] KVM: Enables the kernel to isolate guest free pages

[Alexander Duyck]

On Thu, Mar 7, 2019 at 6:32 PM Michael S. Tsirkin <mst@redhat.com> wrote:
>
> On Thu, Mar 07, 2019 at 02:35:53PM -0800, Alexander Duyck wrote:
> > The only other thing I still want to try and see if I can do is to add
> > a jiffies value to the page private data in the case of the buddy
> > pages.
>
> Actually there's one extra thing I think we should do, and that is make
> sure we do not leave less than X% off the free memory at a time.
> This way chances of triggering an OOM are lower.

If nothing else we could probably look at doing a watermark of some
sort so we have to have X amount of memory free but not hinted before
we will start providing the hints. It would just be a matter of
tracking how much memory we have hinted on versus the amount of memory
that has been pulled from that pool. It is another reason why we
probably want a bit in the buddy pages somewhere to indicate if a page
has been hinted or not as we can then use that to determine if we have
to account for it in the statistics.

> > With that we could track the age of the page so it becomes
> > easier to only target pages that are truly going cold rather than
> > trying to grab pages that were added to the freelist recently.
>
> I like that but I have a vague memory of discussing this with Rik van
> Riel and him saying it's actually better to take away recently used
> ones. Can't see why would that be but maybe I remember wrong. Rik - am I
> just confused?

It is probably to cut down on the need for disk writes in the case of
swap. If that is the case it ends up being a trade off.

The sooner we hint the less likely it is that we will need to write a
given page to disk. However the sooner we hint, the more likely it is
we will need to trigger a page fault and pull back in a zero page to
populate the last page we were working on. The sweet spot will be that
period of time that is somewhere in between so we don't trigger
unnecessary page faults and we don't need to perform additional swap
reads/writes.

Re: [RFC][Patch v9 2/6] KVM: Enables the kernel to isolate guest free pages

[Michael S. Tsirkin]

On Fri, Mar 08, 2019 at 10:06:14AM -0800, Alexander Duyck wrote:
> On Thu, Mar 7, 2019 at 6:32 PM Michael S. Tsirkin <mst@redhat.com> wrote:
> >
> > On Thu, Mar 07, 2019 at 02:35:53PM -0800, Alexander Duyck wrote:
> > > The only other thing I still want to try and see if I can do is to add
> > > a jiffies value to the page private data in the case of the buddy
> > > pages.
> >
> > Actually there's one extra thing I think we should do, and that is make
> > sure we do not leave less than X% off the free memory at a time.
> > This way chances of triggering an OOM are lower.
> 
> If nothing else we could probably look at doing a watermark of some
> sort so we have to have X amount of memory free but not hinted before
> we will start providing the hints. It would just be a matter of
> tracking how much memory we have hinted on versus the amount of memory
> that has been pulled from that pool. It is another reason why we
> probably want a bit in the buddy pages somewhere to indicate if a page
> has been hinted or not as we can then use that to determine if we have
> to account for it in the statistics.
> 
> > > With that we could track the age of the page so it becomes
> > > easier to only target pages that are truly going cold rather than
> > > trying to grab pages that were added to the freelist recently.
> >
> > I like that but I have a vague memory of discussing this with Rik van
> > Riel and him saying it's actually better to take away recently used
> > ones. Can't see why would that be but maybe I remember wrong. Rik - am I
> > just confused?
> 
> It is probably to cut down on the need for disk writes in the case of
> swap. If that is the case it ends up being a trade off.
> 
> The sooner we hint the less likely it is that we will need to write a
> given page to disk. However the sooner we hint, the more likely it is
> we will need to trigger a page fault and pull back in a zero page to
> populate the last page we were working on. The sweet spot will be that
> period of time that is somewhere in between so we don't trigger
> unnecessary page faults and we don't need to perform additional swap
> reads/writes.

Right but the question is - is it better to hint on
least recently used, or most recently used pages?
It looks like LRU should be better, but I vaguely rememeber there
were arguments for why most recently used might be better.
Can't figure out why, maybe I am remembering wrong.

-- 
MST

Re: [RFC][Patch v9 2/6] KVM: Enables the kernel to isolate guest free pages

[Nitesh Narayan Lal]

[-- Attachment #1.1: Type: text/plain, Size: 2816 bytes --]


On 3/8/19 1:06 PM, Alexander Duyck wrote:
> On Thu, Mar 7, 2019 at 6:32 PM Michael S. Tsirkin <mst@redhat.com> wrote:
>> On Thu, Mar 07, 2019 at 02:35:53PM -0800, Alexander Duyck wrote:
>>> The only other thing I still want to try and see if I can do is to add
>>> a jiffies value to the page private data in the case of the buddy
>>> pages.
>> Actually there's one extra thing I think we should do, and that is make
>> sure we do not leave less than X% off the free memory at a time.
>> This way chances of triggering an OOM are lower.
> If nothing else we could probably look at doing a watermark of some
> sort so we have to have X amount of memory free but not hinted before
> we will start providing the hints. It would just be a matter of
> tracking how much memory we have hinted on versus the amount of memory
> that has been pulled from that pool.
This is to avoid false OOM in the guest?
>  It is another reason why we
> probably want a bit in the buddy pages somewhere to indicate if a page
> has been hinted or not as we can then use that to determine if we have
> to account for it in the statistics.

The one benefit which I can see of having an explicit bit is that it
will help us to have a single hook away from the hot path within buddy
merging code (just like your arch_merge_page) and still avoid duplicate
hints while releasing pages.

I still have to check PG_idle and PG_young which you mentioned but I
don't think we can reuse any existing bits.

If we really want to have something like a watermark, then can't we use
zone->free_pages before isolating to see how many free pages are there
and put a threshold on it? (__isolate_free_page() does a similar thing
but it does that on per request basis).

>
>>> With that we could track the age of the page so it becomes
>>> easier to only target pages that are truly going cold rather than
>>> trying to grab pages that were added to the freelist recently.
>> I like that but I have a vague memory of discussing this with Rik van
>> Riel and him saying it's actually better to take away recently used
>> ones. Can't see why would that be but maybe I remember wrong. Rik - am I
>> just confused?
> It is probably to cut down on the need for disk writes in the case of
> swap. If that is the case it ends up being a trade off.
>
> The sooner we hint the less likely it is that we will need to write a
> given page to disk. However the sooner we hint, the more likely it is
> we will need to trigger a page fault and pull back in a zero page to
> populate the last page we were working on. The sweet spot will be that
> period of time that is somewhere in between so we don't trigger
> unnecessary page faults and we don't need to perform additional swap
> reads/writes.
-- 
Regards
Nitesh


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [RFC][Patch v9 2/6] KVM: Enables the kernel to isolate guest free pages

[Alexander Duyck]

On Fri, Mar 8, 2019 at 11:10 AM Nitesh Narayan Lal <nitesh@redhat.com> wrote:
>
>
> On 3/8/19 1:06 PM, Alexander Duyck wrote:
> > On Thu, Mar 7, 2019 at 6:32 PM Michael S. Tsirkin <mst@redhat.com> wrote:
> >> On Thu, Mar 07, 2019 at 02:35:53PM -0800, Alexander Duyck wrote:
> >>> The only other thing I still want to try and see if I can do is to add
> >>> a jiffies value to the page private data in the case of the buddy
> >>> pages.
> >> Actually there's one extra thing I think we should do, and that is make
> >> sure we do not leave less than X% off the free memory at a time.
> >> This way chances of triggering an OOM are lower.
> > If nothing else we could probably look at doing a watermark of some
> > sort so we have to have X amount of memory free but not hinted before
> > we will start providing the hints. It would just be a matter of
> > tracking how much memory we have hinted on versus the amount of memory
> > that has been pulled from that pool.
> This is to avoid false OOM in the guest?

Partially, though it would still be possible. Basically it would just
be a way of determining when we have hinted "enough". Basically it
doesn't do us much good to be hinting on free memory if the guest is
already constrained and just going to reallocate the memory shortly
after we hinted on it. The idea is with a watermark we can avoid
hinting until we start having pages that are actually going to stay
free for a while.

> >  It is another reason why we
> > probably want a bit in the buddy pages somewhere to indicate if a page
> > has been hinted or not as we can then use that to determine if we have
> > to account for it in the statistics.
>
> The one benefit which I can see of having an explicit bit is that it
> will help us to have a single hook away from the hot path within buddy
> merging code (just like your arch_merge_page) and still avoid duplicate
> hints while releasing pages.
>
> I still have to check PG_idle and PG_young which you mentioned but I
> don't think we can reuse any existing bits.

Those are bits that are already there for 64b. I think those exist in
the page extension for 32b systems. If I am not mistaken they are only
used in VMA mapped memory. What I was getting at is that those are the
bits we could think about reusing.

> If we really want to have something like a watermark, then can't we use
> zone->free_pages before isolating to see how many free pages are there
> and put a threshold on it? (__isolate_free_page() does a similar thing
> but it does that on per request basis).

Right. That is only part of it though since that tells you how many
free pages are there. But how many of those free pages are hinted?
That is the part we would need to track separately and then then
compare to free_pages to determine if we need to start hinting on more
memory or not.

> >
> >>> With that we could track the age of the page so it becomes
> >>> easier to only target pages that are truly going cold rather than
> >>> trying to grab pages that were added to the freelist recently.
> >> I like that but I have a vague memory of discussing this with Rik van
> >> Riel and him saying it's actually better to take away recently used
> >> ones. Can't see why would that be but maybe I remember wrong. Rik - am I
> >> just confused?
> > It is probably to cut down on the need for disk writes in the case of
> > swap. If that is the case it ends up being a trade off.
> >
> > The sooner we hint the less likely it is that we will need to write a
> > given page to disk. However the sooner we hint, the more likely it is
> > we will need to trigger a page fault and pull back in a zero page to
> > populate the last page we were working on. The sweet spot will be that
> > period of time that is somewhere in between so we don't trigger
> > unnecessary page faults and we don't need to perform additional swap
> > reads/writes.
> --
> Regards
> Nitesh
>

Re: [RFC][Patch v9 2/6] KVM: Enables the kernel to isolate guest free pages

[Nitesh Narayan Lal]

[-- Attachment #1.1: Type: text/plain, Size: 4341 bytes --]

On 3/8/19 2:25 PM, Alexander Duyck wrote:
> On Fri, Mar 8, 2019 at 11:10 AM Nitesh Narayan Lal <nitesh@redhat.com> wrote:
>>
>> On 3/8/19 1:06 PM, Alexander Duyck wrote:
>>> On Thu, Mar 7, 2019 at 6:32 PM Michael S. Tsirkin <mst@redhat.com> wrote:
>>>> On Thu, Mar 07, 2019 at 02:35:53PM -0800, Alexander Duyck wrote:
>>>>> The only other thing I still want to try and see if I can do is to add
>>>>> a jiffies value to the page private data in the case of the buddy
>>>>> pages.
>>>> Actually there's one extra thing I think we should do, and that is make
>>>> sure we do not leave less than X% off the free memory at a time.
>>>> This way chances of triggering an OOM are lower.
>>> If nothing else we could probably look at doing a watermark of some
>>> sort so we have to have X amount of memory free but not hinted before
>>> we will start providing the hints. It would just be a matter of
>>> tracking how much memory we have hinted on versus the amount of memory
>>> that has been pulled from that pool.
>> This is to avoid false OOM in the guest?
> Partially, though it would still be possible. Basically it would just
> be a way of determining when we have hinted "enough". Basically it
> doesn't do us much good to be hinting on free memory if the guest is
> already constrained and just going to reallocate the memory shortly
> after we hinted on it. The idea is with a watermark we can avoid
> hinting until we start having pages that are actually going to stay
> free for a while.
>
>>>  It is another reason why we
>>> probably want a bit in the buddy pages somewhere to indicate if a page
>>> has been hinted or not as we can then use that to determine if we have
>>> to account for it in the statistics.
>> The one benefit which I can see of having an explicit bit is that it
>> will help us to have a single hook away from the hot path within buddy
>> merging code (just like your arch_merge_page) and still avoid duplicate
>> hints while releasing pages.
>>
>> I still have to check PG_idle and PG_young which you mentioned but I
>> don't think we can reuse any existing bits.
> Those are bits that are already there for 64b. I think those exist in
> the page extension for 32b systems. If I am not mistaken they are only
> used in VMA mapped memory. What I was getting at is that those are the
> bits we could think about reusing.
>
>> If we really want to have something like a watermark, then can't we use
>> zone->free_pages before isolating to see how many free pages are there
>> and put a threshold on it? (__isolate_free_page() does a similar thing
>> but it does that on per request basis).
> Right. That is only part of it though since that tells you how many
> free pages are there. But how many of those free pages are hinted?
> That is the part we would need to track separately and then then
> compare to free_pages to determine if we need to start hinting on more
> memory or not.
Only pages which are isolated will be hinted, and once a page is
isolated it will not be counted in the zone free pages.
Feel free to correct me if I am wrong.
If I am understanding it correctly you only want to hint the idle pages,
is that right?
>
>>>>> With that we could track the age of the page so it becomes
>>>>> easier to only target pages that are truly going cold rather than
>>>>> trying to grab pages that were added to the freelist recently.
>>>> I like that but I have a vague memory of discussing this with Rik van
>>>> Riel and him saying it's actually better to take away recently used
>>>> ones. Can't see why would that be but maybe I remember wrong. Rik - am I
>>>> just confused?
>>> It is probably to cut down on the need for disk writes in the case of
>>> swap. If that is the case it ends up being a trade off.
>>>
>>> The sooner we hint the less likely it is that we will need to write a
>>> given page to disk. However the sooner we hint, the more likely it is
>>> we will need to trigger a page fault and pull back in a zero page to
>>> populate the last page we were working on. The sweet spot will be that
>>> period of time that is somewhere in between so we don't trigger
>>> unnecessary page faults and we don't need to perform additional swap
>>> reads/writes.
>> --
>> Regards
>> Nitesh
>>
-- 
Regards
Nitesh


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [RFC][Patch v9 2/6] KVM: Enables the kernel to isolate guest free pages

[Alexander Duyck]

On Fri, Mar 8, 2019 at 11:39 AM Nitesh Narayan Lal <nitesh@redhat.com> wrote:
>
> On 3/8/19 2:25 PM, Alexander Duyck wrote:
> > On Fri, Mar 8, 2019 at 11:10 AM Nitesh Narayan Lal <nitesh@redhat.com> wrote:
> >>
> >> On 3/8/19 1:06 PM, Alexander Duyck wrote:
> >>> On Thu, Mar 7, 2019 at 6:32 PM Michael S. Tsirkin <mst@redhat.com> wrote:
> >>>> On Thu, Mar 07, 2019 at 02:35:53PM -0800, Alexander Duyck wrote:
> >>>>> The only other thing I still want to try and see if I can do is to add
> >>>>> a jiffies value to the page private data in the case of the buddy
> >>>>> pages.
> >>>> Actually there's one extra thing I think we should do, and that is make
> >>>> sure we do not leave less than X% off the free memory at a time.
> >>>> This way chances of triggering an OOM are lower.
> >>> If nothing else we could probably look at doing a watermark of some
> >>> sort so we have to have X amount of memory free but not hinted before
> >>> we will start providing the hints. It would just be a matter of
> >>> tracking how much memory we have hinted on versus the amount of memory
> >>> that has been pulled from that pool.
> >> This is to avoid false OOM in the guest?
> > Partially, though it would still be possible. Basically it would just
> > be a way of determining when we have hinted "enough". Basically it
> > doesn't do us much good to be hinting on free memory if the guest is
> > already constrained and just going to reallocate the memory shortly
> > after we hinted on it. The idea is with a watermark we can avoid
> > hinting until we start having pages that are actually going to stay
> > free for a while.
> >
> >>>  It is another reason why we
> >>> probably want a bit in the buddy pages somewhere to indicate if a page
> >>> has been hinted or not as we can then use that to determine if we have
> >>> to account for it in the statistics.
> >> The one benefit which I can see of having an explicit bit is that it
> >> will help us to have a single hook away from the hot path within buddy
> >> merging code (just like your arch_merge_page) and still avoid duplicate
> >> hints while releasing pages.
> >>
> >> I still have to check PG_idle and PG_young which you mentioned but I
> >> don't think we can reuse any existing bits.
> > Those are bits that are already there for 64b. I think those exist in
> > the page extension for 32b systems. If I am not mistaken they are only
> > used in VMA mapped memory. What I was getting at is that those are the
> > bits we could think about reusing.
> >
> >> If we really want to have something like a watermark, then can't we use
> >> zone->free_pages before isolating to see how many free pages are there
> >> and put a threshold on it? (__isolate_free_page() does a similar thing
> >> but it does that on per request basis).
> > Right. That is only part of it though since that tells you how many
> > free pages are there. But how many of those free pages are hinted?
> > That is the part we would need to track separately and then then
> > compare to free_pages to determine if we need to start hinting on more
> > memory or not.
> Only pages which are isolated will be hinted, and once a page is
> isolated it will not be counted in the zone free pages.
> Feel free to correct me if I am wrong.

You are correct up to here. When we isolate the page it isn't counted
against the free pages. However after we complete the hint we end up
taking it out of isolation and returning it to the "free" state, so it
will be counted against the free pages.

> If I am understanding it correctly you only want to hint the idle pages,
> is that right?

Getting back to the ideas from our earlier discussion, we had 3 stages
for things. Free but not hinted, isolated due to hinting, and free and
hinted. So what we would need to do is identify the size of the first
pool that is free and not hinted by knowing the total number of free
pages, and then subtract the size of the pages that are hinted and
still free.

> >
> >>>>> With that we could track the age of the page so it becomes
> >>>>> easier to only target pages that are truly going cold rather than
> >>>>> trying to grab pages that were added to the freelist recently.
> >>>> I like that but I have a vague memory of discussing this with Rik van
> >>>> Riel and him saying it's actually better to take away recently used
> >>>> ones. Can't see why would that be but maybe I remember wrong. Rik - am I
> >>>> just confused?
> >>> It is probably to cut down on the need for disk writes in the case of
> >>> swap. If that is the case it ends up being a trade off.
> >>>
> >>> The sooner we hint the less likely it is that we will need to write a
> >>> given page to disk. However the sooner we hint, the more likely it is
> >>> we will need to trigger a page fault and pull back in a zero page to
> >>> populate the last page we were working on. The sweet spot will be that
> >>> period of time that is somewhere in between so we don't trigger
> >>> unnecessary page faults and we don't need to perform additional swap
> >>> reads/writes.
> >> --
> >> Regards
> >> Nitesh
> >>
> --
> Regards
> Nitesh
>

Re: [RFC][Patch v9 2/6] KVM: Enables the kernel to isolate guest free pages

[Nitesh Narayan Lal]

[-- Attachment #1.1: Type: text/plain, Size: 5980 bytes --]

On 3/8/19 4:39 PM, Alexander Duyck wrote:
> On Fri, Mar 8, 2019 at 11:39 AM Nitesh Narayan Lal <nitesh@redhat.com> wrote:
>> On 3/8/19 2:25 PM, Alexander Duyck wrote:
>>> On Fri, Mar 8, 2019 at 11:10 AM Nitesh Narayan Lal <nitesh@redhat.com> wrote:
>>>> On 3/8/19 1:06 PM, Alexander Duyck wrote:
>>>>> On Thu, Mar 7, 2019 at 6:32 PM Michael S. Tsirkin <mst@redhat.com> wrote:
>>>>>> On Thu, Mar 07, 2019 at 02:35:53PM -0800, Alexander Duyck wrote:
>>>>>>> The only other thing I still want to try and see if I can do is to add
>>>>>>> a jiffies value to the page private data in the case of the buddy
>>>>>>> pages.
>>>>>> Actually there's one extra thing I think we should do, and that is make
>>>>>> sure we do not leave less than X% off the free memory at a time.
>>>>>> This way chances of triggering an OOM are lower.
>>>>> If nothing else we could probably look at doing a watermark of some
>>>>> sort so we have to have X amount of memory free but not hinted before
>>>>> we will start providing the hints. It would just be a matter of
>>>>> tracking how much memory we have hinted on versus the amount of memory
>>>>> that has been pulled from that pool.
>>>> This is to avoid false OOM in the guest?
>>> Partially, though it would still be possible. Basically it would just
>>> be a way of determining when we have hinted "enough". Basically it
>>> doesn't do us much good to be hinting on free memory if the guest is
>>> already constrained and just going to reallocate the memory shortly
>>> after we hinted on it. The idea is with a watermark we can avoid
>>> hinting until we start having pages that are actually going to stay
>>> free for a while.
>>>
>>>>>  It is another reason why we
>>>>> probably want a bit in the buddy pages somewhere to indicate if a page
>>>>> has been hinted or not as we can then use that to determine if we have
>>>>> to account for it in the statistics.
>>>> The one benefit which I can see of having an explicit bit is that it
>>>> will help us to have a single hook away from the hot path within buddy
>>>> merging code (just like your arch_merge_page) and still avoid duplicate
>>>> hints while releasing pages.
>>>>
>>>> I still have to check PG_idle and PG_young which you mentioned but I
>>>> don't think we can reuse any existing bits.
>>> Those are bits that are already there for 64b. I think those exist in
>>> the page extension for 32b systems. If I am not mistaken they are only
>>> used in VMA mapped memory. What I was getting at is that those are the
>>> bits we could think about reusing.
>>>
>>>> If we really want to have something like a watermark, then can't we use
>>>> zone->free_pages before isolating to see how many free pages are there
>>>> and put a threshold on it? (__isolate_free_page() does a similar thing
>>>> but it does that on per request basis).
>>> Right. That is only part of it though since that tells you how many
>>> free pages are there. But how many of those free pages are hinted?
>>> That is the part we would need to track separately and then then
>>> compare to free_pages to determine if we need to start hinting on more
>>> memory or not.
>> Only pages which are isolated will be hinted, and once a page is
>> isolated it will not be counted in the zone free pages.
>> Feel free to correct me if I am wrong.
> You are correct up to here. When we isolate the page it isn't counted
> against the free pages. However after we complete the hint we end up
> taking it out of isolation and returning it to the "free" state, so it
> will be counted against the free pages.
>
>> If I am understanding it correctly you only want to hint the idle pages,
>> is that right?
> Getting back to the ideas from our earlier discussion, we had 3 stages
> for things. Free but not hinted, isolated due to hinting, and free and
> hinted. So what we would need to do is identify the size of the first
> pool that is free and not hinted by knowing the total number of free
> pages, and then subtract the size of the pages that are hinted and
> still free.
To summarize, for now, I think it makes sense to stick with the current
approach as this way we can avoid any locking in the allocation path and
reduce the number of hypercalls for a bunch of MAX_ORDER - 1 page.
For the next step other than the comments received in the code and what
I mentioned in the cover email, I would like to do the following:
1. Explore the watermark idea suggested by Alex and bring down memhog
execution time if possible.
2. Benchmark hinting v/s non-hinting more extensively.
Let me know if you have any specific suggestions in terms of the tools I
can run to do the same. (I am planning to run atleast netperf, hackbench
and stress for this).

>
>>>>>>> With that we could track the age of the page so it becomes
>>>>>>> easier to only target pages that are truly going cold rather than
>>>>>>> trying to grab pages that were added to the freelist recently.
>>>>>> I like that but I have a vague memory of discussing this with Rik van
>>>>>> Riel and him saying it's actually better to take away recently used
>>>>>> ones. Can't see why would that be but maybe I remember wrong. Rik - am I
>>>>>> just confused?
>>>>> It is probably to cut down on the need for disk writes in the case of
>>>>> swap. If that is the case it ends up being a trade off.
>>>>>
>>>>> The sooner we hint the less likely it is that we will need to write a
>>>>> given page to disk. However the sooner we hint, the more likely it is
>>>>> we will need to trigger a page fault and pull back in a zero page to
>>>>> populate the last page we were working on. The sweet spot will be that
>>>>> period of time that is somewhere in between so we don't trigger
>>>>> unnecessary page faults and we don't need to perform additional swap
>>>>> reads/writes.
>>>> --
>>>> Regards
>>>> Nitesh
>>>>
>> --
>> Regards
>> Nitesh
>>
-- 
Regards
Nitesh


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [RFC][Patch v9 0/6] KVM: Guest Free Page Hinting

[David Hildenbrand]

On 07.03.19 19:46, Michael S. Tsirkin wrote:
> On Wed, Mar 06, 2019 at 10:00:05AM -0800, Alexander Duyck wrote:
>> I have been thinking about this. Instead of stealing the page couldn't
>> you simply flag it that there is a hint in progress and simply wait in
>> arch_alloc_page until the hint has been processed? The problem is in
>> stealing pages you are going to introduce false OOM issues when the
>> memory isn't available because it is being hinted on.
> 
> Can we not give them back in an OOM notifier?
> 

In the OOM notifier we might simply return "pages made available" as
long as some pages are currently being hinted. We can use an atomic_t to
track the number of requests that are sill being processed by the
hypervisor.

The larger the page granularity we have, the less likely the issue in
running into this. But yes, it might happen if the starts align.

-- 

Thanks,

David / dhildenb

Re: [RFC][Patch v9 2/6] KVM: Enables the kernel to isolate guest free pages

[Alexander Duyck]

On Tue, Mar 12, 2019 at 12:46 PM Nitesh Narayan Lal <nitesh@redhat.com> wrote:
>
> On 3/8/19 4:39 PM, Alexander Duyck wrote:
> > On Fri, Mar 8, 2019 at 11:39 AM Nitesh Narayan Lal <nitesh@redhat.com> wrote:
> >> On 3/8/19 2:25 PM, Alexander Duyck wrote:
> >>> On Fri, Mar 8, 2019 at 11:10 AM Nitesh Narayan Lal <nitesh@redhat.com> wrote:
> >>>> On 3/8/19 1:06 PM, Alexander Duyck wrote:
> >>>>> On Thu, Mar 7, 2019 at 6:32 PM Michael S. Tsirkin <mst@redhat.com> wrote:
> >>>>>> On Thu, Mar 07, 2019 at 02:35:53PM -0800, Alexander Duyck wrote:
> >>>>>>> The only other thing I still want to try and see if I can do is to add
> >>>>>>> a jiffies value to the page private data in the case of the buddy
> >>>>>>> pages.
> >>>>>> Actually there's one extra thing I think we should do, and that is make
> >>>>>> sure we do not leave less than X% off the free memory at a time.
> >>>>>> This way chances of triggering an OOM are lower.
> >>>>> If nothing else we could probably look at doing a watermark of some
> >>>>> sort so we have to have X amount of memory free but not hinted before
> >>>>> we will start providing the hints. It would just be a matter of
> >>>>> tracking how much memory we have hinted on versus the amount of memory
> >>>>> that has been pulled from that pool.
> >>>> This is to avoid false OOM in the guest?
> >>> Partially, though it would still be possible. Basically it would just
> >>> be a way of determining when we have hinted "enough". Basically it
> >>> doesn't do us much good to be hinting on free memory if the guest is
> >>> already constrained and just going to reallocate the memory shortly
> >>> after we hinted on it. The idea is with a watermark we can avoid
> >>> hinting until we start having pages that are actually going to stay
> >>> free for a while.
> >>>
> >>>>>  It is another reason why we
> >>>>> probably want a bit in the buddy pages somewhere to indicate if a page
> >>>>> has been hinted or not as we can then use that to determine if we have
> >>>>> to account for it in the statistics.
> >>>> The one benefit which I can see of having an explicit bit is that it
> >>>> will help us to have a single hook away from the hot path within buddy
> >>>> merging code (just like your arch_merge_page) and still avoid duplicate
> >>>> hints while releasing pages.
> >>>>
> >>>> I still have to check PG_idle and PG_young which you mentioned but I
> >>>> don't think we can reuse any existing bits.
> >>> Those are bits that are already there for 64b. I think those exist in
> >>> the page extension for 32b systems. If I am not mistaken they are only
> >>> used in VMA mapped memory. What I was getting at is that those are the
> >>> bits we could think about reusing.
> >>>
> >>>> If we really want to have something like a watermark, then can't we use
> >>>> zone->free_pages before isolating to see how many free pages are there
> >>>> and put a threshold on it? (__isolate_free_page() does a similar thing
> >>>> but it does that on per request basis).
> >>> Right. That is only part of it though since that tells you how many
> >>> free pages are there. But how many of those free pages are hinted?
> >>> That is the part we would need to track separately and then then
> >>> compare to free_pages to determine if we need to start hinting on more
> >>> memory or not.
> >> Only pages which are isolated will be hinted, and once a page is
> >> isolated it will not be counted in the zone free pages.
> >> Feel free to correct me if I am wrong.
> > You are correct up to here. When we isolate the page it isn't counted
> > against the free pages. However after we complete the hint we end up
> > taking it out of isolation and returning it to the "free" state, so it
> > will be counted against the free pages.
> >
> >> If I am understanding it correctly you only want to hint the idle pages,
> >> is that right?
> > Getting back to the ideas from our earlier discussion, we had 3 stages
> > for things. Free but not hinted, isolated due to hinting, and free and
> > hinted. So what we would need to do is identify the size of the first
> > pool that is free and not hinted by knowing the total number of free
> > pages, and then subtract the size of the pages that are hinted and
> > still free.
> To summarize, for now, I think it makes sense to stick with the current
> approach as this way we can avoid any locking in the allocation path and
> reduce the number of hypercalls for a bunch of MAX_ORDER - 1 page.

I'm not sure what you are talking about by "avoid any locking in the
allocation path". Are you talking about the spin on idle bit, if so
then yes. However I have been testing your patches and I was correct
in the assumption that you forgot to handle the zone lock when you
were freeing __free_one_page. I just did a quick copy/paste from your
zone lock handling from the guest_free_page_hinting function into the
release_buddy_pages function and then I was able to enable multiple
CPUs without any issues.

> For the next step other than the comments received in the code and what
> I mentioned in the cover email, I would like to do the following:
> 1. Explore the watermark idea suggested by Alex and bring down memhog
> execution time if possible.

So there are a few things that are hurting us on the memhog test:
1. The current QEMU patch is only madvising 4K pages at a time, this
is disabling THP and hurts the test.

2. The fact that we madvise the pages away makes it so that we have to
fault the page back in in order to use it for the memhog test. In
order to avoid that penalty we may want to see if we can introduce
some sort of "timeout" on the pages so that we are only hinting away
old pages that have not been used for some period of time.

3. Currently we are still doing a large amount of processing in the
page free path. Ideally we should look at getting away from trying to
do so much per-cpu work and instead just have some small tasks that
put the data needed in the page, and then have a separate thread
walking the free_list checking that data, isolating the pages, hinting
them, and then returning them back to the free_list.

> 2. Benchmark hinting v/s non-hinting more extensively.
> Let me know if you have any specific suggestions in terms of the tools I
> can run to do the same. (I am planning to run atleast netperf, hackbench
> and stress for this).

So I have been running the memhog 32g test and the will-it-scale
page_fault1 test as my primary two tests for this so far.

What I have seen so far has been pretty promising. I had to do some
build fixes, fixes to QEMU to hint on the full size page instead of 4K
page, and fixes for locking so this isn't exactly your original patch
set, but with all that I am seeing data comparable to the original
patch set I had.

For memhog 32g I am seeing performance similar to a VM that was fresh
booted. I make that the comparison because you will have to take page
faults on a fresh boot as you access additional memory. However after
the first run of the runtime drops  from 22s to 20s without the
hinting enabled.

The big one that probably still needs some work will be the multi-cpu
scaling. With the per-cpu locking for the zone lock to pull pages out,
and put them back in the free list I am seeing what looks like about a
10% drop in the page_fault1 test. Here are the results as I have seen
so far on a 16 cpu 32G VM:

-- baseline --
./runtest.py page_fault1
tasks,processes,processes_idle,threads,threads_idle,linear
0,0,100,0,100,0
1,522242,93.73,514965,93.74,522242
2,929433,87.48,857280,87.50,1044484
3,1360651,81.25,1214224,81.48,1566726
4,1693709,75.01,1437156,76.33,2088968
5,2062392,68.77,1743294,70.78,2611210
6,2271363,62.54,1787238,66.75,3133452
7,2564479,56.33,1924684,61.77,3655694
8,2699897,50.09,2205783,54.28,4177936
9,2931697,43.85,2135788,50.20,4700178
10,2939384,37.63,2258725,45.04,5222420
11,3039010,31.41,2209401,41.04,5744662
12,3022976,25.19,2177655,35.68,6266904
13,3015683,18.98,2123546,31.73,6789146
14,2921798,12.77,2160489,27.30,7311388
15,2846758,6.51,1815036,17.40,7833630
16,2703146,0.36,2121018,18.21,8355872

-- modified rh patchset --
./runtest.py page_fault1
tasks,processes,processes_idle,threads,threads_idle,linear
0,0,100,0,100,0
1,527216,93.72,517459,93.70,527216
2,911239,87.48,843278,87.51,1054432
3,1295059,81.22,1193523,81.61,1581648
4,1649332,75.02,1439403,76.17,2108864
5,1985780,68.81,1745556,70.44,2636080
6,2174751,62.56,1769433,66.84,3163296
7,2433273,56.33,2121777,58.46,3690512
8,2537356,50.17,1901743,57.23,4217728
9,2737689,43.87,1859179,54.17,4744944
10,2718474,37.65,2188891,43.69,5272160
11,2743381,31.47,2205112,38.00,5799376
12,2738717,25.26,2117281,38.09,6326592
13,2643648,19.06,1887956,35.31,6853808
14,2598001,12.92,1916544,27.87,7381024
15,2498325,6.70,1992580,26.10,7908240
16,2424587,0.45,2137742,21.37,8435456

As we discussed earlier, it would probably be good to focus on only
pulling something like 4 to 8 (MAX_ORDER - 1) pages per round of
hinting. You might also look at only working one zone at a time. Then
what you could do is look at placing the pages you have already hinted
on at the tail end of the free_list and pull a new set of pages out to
hint on. You could do this all in one shot while holding the zone
lock.

Re: [RFC][Patch v9 2/6] KVM: Enables the kernel to isolate guest free pages

[David Hildenbrand]

On 12.03.19 22:13, Alexander Duyck wrote:
> On Tue, Mar 12, 2019 at 12:46 PM Nitesh Narayan Lal <nitesh@redhat.com> wrote:
>>
>> On 3/8/19 4:39 PM, Alexander Duyck wrote:
>>> On Fri, Mar 8, 2019 at 11:39 AM Nitesh Narayan Lal <nitesh@redhat.com> wrote:
>>>> On 3/8/19 2:25 PM, Alexander Duyck wrote:
>>>>> On Fri, Mar 8, 2019 at 11:10 AM Nitesh Narayan Lal <nitesh@redhat.com> wrote:
>>>>>> On 3/8/19 1:06 PM, Alexander Duyck wrote:
>>>>>>> On Thu, Mar 7, 2019 at 6:32 PM Michael S. Tsirkin <mst@redhat.com> wrote:
>>>>>>>> On Thu, Mar 07, 2019 at 02:35:53PM -0800, Alexander Duyck wrote:
>>>>>>>>> The only other thing I still want to try and see if I can do is to add
>>>>>>>>> a jiffies value to the page private data in the case of the buddy
>>>>>>>>> pages.
>>>>>>>> Actually there's one extra thing I think we should do, and that is make
>>>>>>>> sure we do not leave less than X% off the free memory at a time.
>>>>>>>> This way chances of triggering an OOM are lower.
>>>>>>> If nothing else we could probably look at doing a watermark of some
>>>>>>> sort so we have to have X amount of memory free but not hinted before
>>>>>>> we will start providing the hints. It would just be a matter of
>>>>>>> tracking how much memory we have hinted on versus the amount of memory
>>>>>>> that has been pulled from that pool.
>>>>>> This is to avoid false OOM in the guest?
>>>>> Partially, though it would still be possible. Basically it would just
>>>>> be a way of determining when we have hinted "enough". Basically it
>>>>> doesn't do us much good to be hinting on free memory if the guest is
>>>>> already constrained and just going to reallocate the memory shortly
>>>>> after we hinted on it. The idea is with a watermark we can avoid
>>>>> hinting until we start having pages that are actually going to stay
>>>>> free for a while.
>>>>>
>>>>>>>  It is another reason why we
>>>>>>> probably want a bit in the buddy pages somewhere to indicate if a page
>>>>>>> has been hinted or not as we can then use that to determine if we have
>>>>>>> to account for it in the statistics.
>>>>>> The one benefit which I can see of having an explicit bit is that it
>>>>>> will help us to have a single hook away from the hot path within buddy
>>>>>> merging code (just like your arch_merge_page) and still avoid duplicate
>>>>>> hints while releasing pages.
>>>>>>
>>>>>> I still have to check PG_idle and PG_young which you mentioned but I
>>>>>> don't think we can reuse any existing bits.
>>>>> Those are bits that are already there for 64b. I think those exist in
>>>>> the page extension for 32b systems. If I am not mistaken they are only
>>>>> used in VMA mapped memory. What I was getting at is that those are the
>>>>> bits we could think about reusing.
>>>>>
>>>>>> If we really want to have something like a watermark, then can't we use
>>>>>> zone->free_pages before isolating to see how many free pages are there
>>>>>> and put a threshold on it? (__isolate_free_page() does a similar thing
>>>>>> but it does that on per request basis).
>>>>> Right. That is only part of it though since that tells you how many
>>>>> free pages are there. But how many of those free pages are hinted?
>>>>> That is the part we would need to track separately and then then
>>>>> compare to free_pages to determine if we need to start hinting on more
>>>>> memory or not.
>>>> Only pages which are isolated will be hinted, and once a page is
>>>> isolated it will not be counted in the zone free pages.
>>>> Feel free to correct me if I am wrong.
>>> You are correct up to here. When we isolate the page it isn't counted
>>> against the free pages. However after we complete the hint we end up
>>> taking it out of isolation and returning it to the "free" state, so it
>>> will be counted against the free pages.
>>>
>>>> If I am understanding it correctly you only want to hint the idle pages,
>>>> is that right?
>>> Getting back to the ideas from our earlier discussion, we had 3 stages
>>> for things. Free but not hinted, isolated due to hinting, and free and
>>> hinted. So what we would need to do is identify the size of the first
>>> pool that is free and not hinted by knowing the total number of free
>>> pages, and then subtract the size of the pages that are hinted and
>>> still free.
>> To summarize, for now, I think it makes sense to stick with the current
>> approach as this way we can avoid any locking in the allocation path and
>> reduce the number of hypercalls for a bunch of MAX_ORDER - 1 page.
> 
> I'm not sure what you are talking about by "avoid any locking in the
> allocation path". Are you talking about the spin on idle bit, if so
> then yes. However I have been testing your patches and I was correct
> in the assumption that you forgot to handle the zone lock when you
> were freeing __free_one_page. I just did a quick copy/paste from your
> zone lock handling from the guest_free_page_hinting function into the
> release_buddy_pages function and then I was able to enable multiple
> CPUs without any issues.
> 
>> For the next step other than the comments received in the code and what
>> I mentioned in the cover email, I would like to do the following:
>> 1. Explore the watermark idea suggested by Alex and bring down memhog
>> execution time if possible.
> 
> So there are a few things that are hurting us on the memhog test:
> 1. The current QEMU patch is only madvising 4K pages at a time, this
> is disabling THP and hurts the test.
> 
> 2. The fact that we madvise the pages away makes it so that we have to
> fault the page back in in order to use it for the memhog test. In
> order to avoid that penalty we may want to see if we can introduce
> some sort of "timeout" on the pages so that we are only hinting away
> old pages that have not been used for some period of time.
> 
> 3. Currently we are still doing a large amount of processing in the
> page free path. Ideally we should look at getting away from trying to
> do so much per-cpu work and instead just have some small tasks that
> put the data needed in the page, and then have a separate thread
> walking the free_list checking that data, isolating the pages, hinting
> them, and then returning them back to the free_list.

This is highly debatable. Whenever the is concurrency, there is the need
for locking (well, at least synchronization - maybe using existing locks
like the zone lock). The other thread has to run somewhere. One thread
per VCPU might not what we want ... sorting this out might be more
complicated than it would seem. I would suggest to defer the discussion
of this change to a later stage. It can be easily reworked later - in
theory :)

1 and 2 you mention are the lower hanging fruits that will definitely
improve performance.

-- 

Thanks,

David / dhildenb

Re: [RFC][Patch v9 2/6] KVM: Enables the kernel to isolate guest free pages

[Alexander Duyck]

On Tue, Mar 12, 2019 at 2:53 PM David Hildenbrand <david@redhat.com> wrote:
>
> On 12.03.19 22:13, Alexander Duyck wrote:
> > On Tue, Mar 12, 2019 at 12:46 PM Nitesh Narayan Lal <nitesh@redhat.com> wrote:
> >>
> >> On 3/8/19 4:39 PM, Alexander Duyck wrote:
> >>> On Fri, Mar 8, 2019 at 11:39 AM Nitesh Narayan Lal <nitesh@redhat.com> wrote:
> >>>> On 3/8/19 2:25 PM, Alexander Duyck wrote:
> >>>>> On Fri, Mar 8, 2019 at 11:10 AM Nitesh Narayan Lal <nitesh@redhat.com> wrote:
> >>>>>> On 3/8/19 1:06 PM, Alexander Duyck wrote:
> >>>>>>> On Thu, Mar 7, 2019 at 6:32 PM Michael S. Tsirkin <mst@redhat.com> wrote:
> >>>>>>>> On Thu, Mar 07, 2019 at 02:35:53PM -0800, Alexander Duyck wrote:
> >>>>>>>>> The only other thing I still want to try and see if I can do is to add
> >>>>>>>>> a jiffies value to the page private data in the case of the buddy
> >>>>>>>>> pages.
> >>>>>>>> Actually there's one extra thing I think we should do, and that is make
> >>>>>>>> sure we do not leave less than X% off the free memory at a time.
> >>>>>>>> This way chances of triggering an OOM are lower.
> >>>>>>> If nothing else we could probably look at doing a watermark of some
> >>>>>>> sort so we have to have X amount of memory free but not hinted before
> >>>>>>> we will start providing the hints. It would just be a matter of
> >>>>>>> tracking how much memory we have hinted on versus the amount of memory
> >>>>>>> that has been pulled from that pool.
> >>>>>> This is to avoid false OOM in the guest?
> >>>>> Partially, though it would still be possible. Basically it would just
> >>>>> be a way of determining when we have hinted "enough". Basically it
> >>>>> doesn't do us much good to be hinting on free memory if the guest is
> >>>>> already constrained and just going to reallocate the memory shortly
> >>>>> after we hinted on it. The idea is with a watermark we can avoid
> >>>>> hinting until we start having pages that are actually going to stay
> >>>>> free for a while.
> >>>>>
> >>>>>>>  It is another reason why we
> >>>>>>> probably want a bit in the buddy pages somewhere to indicate if a page
> >>>>>>> has been hinted or not as we can then use that to determine if we have
> >>>>>>> to account for it in the statistics.
> >>>>>> The one benefit which I can see of having an explicit bit is that it
> >>>>>> will help us to have a single hook away from the hot path within buddy
> >>>>>> merging code (just like your arch_merge_page) and still avoid duplicate
> >>>>>> hints while releasing pages.
> >>>>>>
> >>>>>> I still have to check PG_idle and PG_young which you mentioned but I
> >>>>>> don't think we can reuse any existing bits.
> >>>>> Those are bits that are already there for 64b. I think those exist in
> >>>>> the page extension for 32b systems. If I am not mistaken they are only
> >>>>> used in VMA mapped memory. What I was getting at is that those are the
> >>>>> bits we could think about reusing.
> >>>>>
> >>>>>> If we really want to have something like a watermark, then can't we use
> >>>>>> zone->free_pages before isolating to see how many free pages are there
> >>>>>> and put a threshold on it? (__isolate_free_page() does a similar thing
> >>>>>> but it does that on per request basis).
> >>>>> Right. That is only part of it though since that tells you how many
> >>>>> free pages are there. But how many of those free pages are hinted?
> >>>>> That is the part we would need to track separately and then then
> >>>>> compare to free_pages to determine if we need to start hinting on more
> >>>>> memory or not.
> >>>> Only pages which are isolated will be hinted, and once a page is
> >>>> isolated it will not be counted in the zone free pages.
> >>>> Feel free to correct me if I am wrong.
> >>> You are correct up to here. When we isolate the page it isn't counted
> >>> against the free pages. However after we complete the hint we end up
> >>> taking it out of isolation and returning it to the "free" state, so it
> >>> will be counted against the free pages.
> >>>
> >>>> If I am understanding it correctly you only want to hint the idle pages,
> >>>> is that right?
> >>> Getting back to the ideas from our earlier discussion, we had 3 stages
> >>> for things. Free but not hinted, isolated due to hinting, and free and
> >>> hinted. So what we would need to do is identify the size of the first
> >>> pool that is free and not hinted by knowing the total number of free
> >>> pages, and then subtract the size of the pages that are hinted and
> >>> still free.
> >> To summarize, for now, I think it makes sense to stick with the current
> >> approach as this way we can avoid any locking in the allocation path and
> >> reduce the number of hypercalls for a bunch of MAX_ORDER - 1 page.
> >
> > I'm not sure what you are talking about by "avoid any locking in the
> > allocation path". Are you talking about the spin on idle bit, if so
> > then yes. However I have been testing your patches and I was correct
> > in the assumption that you forgot to handle the zone lock when you
> > were freeing __free_one_page. I just did a quick copy/paste from your
> > zone lock handling from the guest_free_page_hinting function into the
> > release_buddy_pages function and then I was able to enable multiple
> > CPUs without any issues.
> >
> >> For the next step other than the comments received in the code and what
> >> I mentioned in the cover email, I would like to do the following:
> >> 1. Explore the watermark idea suggested by Alex and bring down memhog
> >> execution time if possible.
> >
> > So there are a few things that are hurting us on the memhog test:
> > 1. The current QEMU patch is only madvising 4K pages at a time, this
> > is disabling THP and hurts the test.
> >
> > 2. The fact that we madvise the pages away makes it so that we have to
> > fault the page back in in order to use it for the memhog test. In
> > order to avoid that penalty we may want to see if we can introduce
> > some sort of "timeout" on the pages so that we are only hinting away
> > old pages that have not been used for some period of time.
> >
> > 3. Currently we are still doing a large amount of processing in the
> > page free path. Ideally we should look at getting away from trying to
> > do so much per-cpu work and instead just have some small tasks that
> > put the data needed in the page, and then have a separate thread
> > walking the free_list checking that data, isolating the pages, hinting
> > them, and then returning them back to the free_list.
>
> This is highly debatable. Whenever the is concurrency, there is the need
> for locking (well, at least synchronization - maybe using existing locks
> like the zone lock). The other thread has to run somewhere. One thread
> per VCPU might not what we want ... sorting this out might be more
> complicated than it would seem. I would suggest to defer the discussion
> of this change to a later stage. It can be easily reworked later - in
> theory :)

I'm not suggesting anything too complex for now. I would be happy with
just using the zone lock. The only other thing we would really need to
make it work is some sort of bit we could set once a page has been
hinted, and cleared when it is allocated. I"m leaning toward
PG_owner_priv_1 at this point since it doesn't seem to be used in the
buddy allocator but is heavily used/re-purposed in multiple other
spots.

> 1 and 2 you mention are the lower hanging fruits that will definitely
> improve performance.

Agreed. Although the challenge with 2 is getting to the page later
instead of trying to immediately hint on the page we just freed. That
is why I still thing 3 is going to tie in closely with 2.

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

Re: [RFC][Patch v9 2/6] KVM: Enables the kernel to isolate guest free pages

[Nitesh Narayan Lal]

[-- Attachment #1.1: Type: text/plain, Size: 10434 bytes --]


On 3/12/19 5:13 PM, Alexander Duyck wrote:
> On Tue, Mar 12, 2019 at 12:46 PM Nitesh Narayan Lal <nitesh@redhat.com> wrote:
>> On 3/8/19 4:39 PM, Alexander Duyck wrote:
>>> On Fri, Mar 8, 2019 at 11:39 AM Nitesh Narayan Lal <nitesh@redhat.com> wrote:
>>>> On 3/8/19 2:25 PM, Alexander Duyck wrote:
>>>>> On Fri, Mar 8, 2019 at 11:10 AM Nitesh Narayan Lal <nitesh@redhat.com> wrote:
>>>>>> On 3/8/19 1:06 PM, Alexander Duyck wrote:
>>>>>>> On Thu, Mar 7, 2019 at 6:32 PM Michael S. Tsirkin <mst@redhat.com> wrote:
>>>>>>>> On Thu, Mar 07, 2019 at 02:35:53PM -0800, Alexander Duyck wrote:
>>>>>>>>> The only other thing I still want to try and see if I can do is to add
>>>>>>>>> a jiffies value to the page private data in the case of the buddy
>>>>>>>>> pages.
>>>>>>>> Actually there's one extra thing I think we should do, and that is make
>>>>>>>> sure we do not leave less than X% off the free memory at a time.
>>>>>>>> This way chances of triggering an OOM are lower.
>>>>>>> If nothing else we could probably look at doing a watermark of some
>>>>>>> sort so we have to have X amount of memory free but not hinted before
>>>>>>> we will start providing the hints. It would just be a matter of
>>>>>>> tracking how much memory we have hinted on versus the amount of memory
>>>>>>> that has been pulled from that pool.
>>>>>> This is to avoid false OOM in the guest?
>>>>> Partially, though it would still be possible. Basically it would just
>>>>> be a way of determining when we have hinted "enough". Basically it
>>>>> doesn't do us much good to be hinting on free memory if the guest is
>>>>> already constrained and just going to reallocate the memory shortly
>>>>> after we hinted on it. The idea is with a watermark we can avoid
>>>>> hinting until we start having pages that are actually going to stay
>>>>> free for a while.
>>>>>
>>>>>>>  It is another reason why we
>>>>>>> probably want a bit in the buddy pages somewhere to indicate if a page
>>>>>>> has been hinted or not as we can then use that to determine if we have
>>>>>>> to account for it in the statistics.
>>>>>> The one benefit which I can see of having an explicit bit is that it
>>>>>> will help us to have a single hook away from the hot path within buddy
>>>>>> merging code (just like your arch_merge_page) and still avoid duplicate
>>>>>> hints while releasing pages.
>>>>>>
>>>>>> I still have to check PG_idle and PG_young which you mentioned but I
>>>>>> don't think we can reuse any existing bits.
>>>>> Those are bits that are already there for 64b. I think those exist in
>>>>> the page extension for 32b systems. If I am not mistaken they are only
>>>>> used in VMA mapped memory. What I was getting at is that those are the
>>>>> bits we could think about reusing.
>>>>>
>>>>>> If we really want to have something like a watermark, then can't we use
>>>>>> zone->free_pages before isolating to see how many free pages are there
>>>>>> and put a threshold on it? (__isolate_free_page() does a similar thing
>>>>>> but it does that on per request basis).
>>>>> Right. That is only part of it though since that tells you how many
>>>>> free pages are there. But how many of those free pages are hinted?
>>>>> That is the part we would need to track separately and then then
>>>>> compare to free_pages to determine if we need to start hinting on more
>>>>> memory or not.
>>>> Only pages which are isolated will be hinted, and once a page is
>>>> isolated it will not be counted in the zone free pages.
>>>> Feel free to correct me if I am wrong.
>>> You are correct up to here. When we isolate the page it isn't counted
>>> against the free pages. However after we complete the hint we end up
>>> taking it out of isolation and returning it to the "free" state, so it
>>> will be counted against the free pages.
>>>
>>>> If I am understanding it correctly you only want to hint the idle pages,
>>>> is that right?
>>> Getting back to the ideas from our earlier discussion, we had 3 stages
>>> for things. Free but not hinted, isolated due to hinting, and free and
>>> hinted. So what we would need to do is identify the size of the first
>>> pool that is free and not hinted by knowing the total number of free
>>> pages, and then subtract the size of the pages that are hinted and
>>> still free.
>> To summarize, for now, I think it makes sense to stick with the current
>> approach as this way we can avoid any locking in the allocation path and
>> reduce the number of hypercalls for a bunch of MAX_ORDER - 1 page.
> I'm not sure what you are talking about by "avoid any locking in the
> allocation path". Are you talking about the spin on idle bit, if so
> then yes. 
Yeap!
> However I have been testing your patches and I was correct
> in the assumption that you forgot to handle the zone lock when you
> were freeing __free_one_page.
Yes, these are the steps other than the comments you provided in the
code. (One of them is to fix release_buddy_page())
>  I just did a quick copy/paste from your
> zone lock handling from the guest_free_page_hinting function into the
> release_buddy_pages function and then I was able to enable multiple
> CPUs without any issues.
>
>> For the next step other than the comments received in the code and what
>> I mentioned in the cover email, I would like to do the following:
>> 1. Explore the watermark idea suggested by Alex and bring down memhog
>> execution time if possible.
> So there are a few things that are hurting us on the memhog test:
> 1. The current QEMU patch is only madvising 4K pages at a time, this
> is disabling THP and hurts the test.
Makes sense, thanks for pointing this out.
>
> 2. The fact that we madvise the pages away makes it so that we have to
> fault the page back in in order to use it for the memhog test. In
> order to avoid that penalty we may want to see if we can introduce
> some sort of "timeout" on the pages so that we are only hinting away
> old pages that have not been used for some period of time.

Possibly using MADVISE_FREE should also help in this, I will try this as
well.

If we could come up with something bit which we could reuse then we may
be able to  tackle this issue easily. I will look into this.

>
> 3. Currently we are still doing a large amount of processing in the
> page free path. Ideally we should look at getting away from trying to
> do so much per-cpu work and instead just have some small tasks that
> put the data needed in the page, and then have a separate thread
> walking the free_list checking that data, isolating the pages, hinting
> them, and then returning them back to the free_list.
I will probably defer this analysis for now, once we have other things
fixed. I can possibly evaluate/compare the performance impact with both
the approach and chose from them.
>
>> 2. Benchmark hinting v/s non-hinting more extensively.
>> Let me know if you have any specific suggestions in terms of the tools I
>> can run to do the same. (I am planning to run atleast netperf, hackbench
>> and stress for this).
> So I have been running the memhog 32g test and the will-it-scale
> page_fault1 test as my primary two tests for this so far.
>
> What I have seen so far has been pretty promising. I had to do some
> build fixes, fixes to QEMU to hint on the full size page instead of 4K
> page, and fixes for locking so this isn't exactly your original patch
> set, but with all that I am seeing data comparable to the original
> patch set I had.
>
> For memhog 32g I am seeing performance similar to a VM that was fresh
> booted. I make that the comparison because you will have to take page
> faults on a fresh boot as you access additional memory. However after
> the first run of the runtime drops  from 22s to 20s without the
> hinting enabled.
>
> The big one that probably still needs some work will be the multi-cpu
> scaling. With the per-cpu locking for the zone lock to pull pages out,
> and put them back in the free list I am seeing what looks like about a
> 10% drop in the page_fault1 test. Here are the results as I have seen
> so far on a 16 cpu 32G VM:
>
> -- baseline --
> ./runtest.py page_fault1
> tasks,processes,processes_idle,threads,threads_idle,linear
> 0,0,100,0,100,0
> 1,522242,93.73,514965,93.74,522242
> 2,929433,87.48,857280,87.50,1044484
> 3,1360651,81.25,1214224,81.48,1566726
> 4,1693709,75.01,1437156,76.33,2088968
> 5,2062392,68.77,1743294,70.78,2611210
> 6,2271363,62.54,1787238,66.75,3133452
> 7,2564479,56.33,1924684,61.77,3655694
> 8,2699897,50.09,2205783,54.28,4177936
> 9,2931697,43.85,2135788,50.20,4700178
> 10,2939384,37.63,2258725,45.04,5222420
> 11,3039010,31.41,2209401,41.04,5744662
> 12,3022976,25.19,2177655,35.68,6266904
> 13,3015683,18.98,2123546,31.73,6789146
> 14,2921798,12.77,2160489,27.30,7311388
> 15,2846758,6.51,1815036,17.40,7833630
> 16,2703146,0.36,2121018,18.21,8355872
>
> -- modified rh patchset --
> ./runtest.py page_fault1
> tasks,processes,processes_idle,threads,threads_idle,linear
> 0,0,100,0,100,0
> 1,527216,93.72,517459,93.70,527216
> 2,911239,87.48,843278,87.51,1054432
> 3,1295059,81.22,1193523,81.61,1581648
> 4,1649332,75.02,1439403,76.17,2108864
> 5,1985780,68.81,1745556,70.44,2636080
> 6,2174751,62.56,1769433,66.84,3163296
> 7,2433273,56.33,2121777,58.46,3690512
> 8,2537356,50.17,1901743,57.23,4217728
> 9,2737689,43.87,1859179,54.17,4744944
> 10,2718474,37.65,2188891,43.69,5272160
> 11,2743381,31.47,2205112,38.00,5799376
> 12,2738717,25.26,2117281,38.09,6326592
> 13,2643648,19.06,1887956,35.31,6853808
> 14,2598001,12.92,1916544,27.87,7381024
> 15,2498325,6.70,1992580,26.10,7908240
> 16,2424587,0.45,2137742,21.37,8435456
>
> As we discussed earlier, it would probably be good to focus on only
> pulling something like 4 to 8 (MAX_ORDER - 1) pages per round of
> hinting. 
I agree that I should bring down the page-set on which I am working.
> You might also look at only working one zone at a time. Then
> what you could do is look at placing the pages you have already hinted
> on at the tail end of the free_list and pull a new set of pages out to
> hint on.
I think for this we still need a way to check if a particular page is
hinted or not.
>  You could do this all in one shot while holding the zone
> lock.
-- 
Regards
Nitesh


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [RFC][Patch v9 2/6] KVM: Enables the kernel to isolate guest free pages

[David Hildenbrand]

On 13.03.19 12:54, Nitesh Narayan Lal wrote:
> 
> On 3/12/19 5:13 PM, Alexander Duyck wrote:
>> On Tue, Mar 12, 2019 at 12:46 PM Nitesh Narayan Lal <nitesh@redhat.com> wrote:
>>> On 3/8/19 4:39 PM, Alexander Duyck wrote:
>>>> On Fri, Mar 8, 2019 at 11:39 AM Nitesh Narayan Lal <nitesh@redhat.com> wrote:
>>>>> On 3/8/19 2:25 PM, Alexander Duyck wrote:
>>>>>> On Fri, Mar 8, 2019 at 11:10 AM Nitesh Narayan Lal <nitesh@redhat.com> wrote:
>>>>>>> On 3/8/19 1:06 PM, Alexander Duyck wrote:
>>>>>>>> On Thu, Mar 7, 2019 at 6:32 PM Michael S. Tsirkin <mst@redhat.com> wrote:
>>>>>>>>> On Thu, Mar 07, 2019 at 02:35:53PM -0800, Alexander Duyck wrote:
>>>>>>>>>> The only other thing I still want to try and see if I can do is to add
>>>>>>>>>> a jiffies value to the page private data in the case of the buddy
>>>>>>>>>> pages.
>>>>>>>>> Actually there's one extra thing I think we should do, and that is make
>>>>>>>>> sure we do not leave less than X% off the free memory at a time.
>>>>>>>>> This way chances of triggering an OOM are lower.
>>>>>>>> If nothing else we could probably look at doing a watermark of some
>>>>>>>> sort so we have to have X amount of memory free but not hinted before
>>>>>>>> we will start providing the hints. It would just be a matter of
>>>>>>>> tracking how much memory we have hinted on versus the amount of memory
>>>>>>>> that has been pulled from that pool.
>>>>>>> This is to avoid false OOM in the guest?
>>>>>> Partially, though it would still be possible. Basically it would just
>>>>>> be a way of determining when we have hinted "enough". Basically it
>>>>>> doesn't do us much good to be hinting on free memory if the guest is
>>>>>> already constrained and just going to reallocate the memory shortly
>>>>>> after we hinted on it. The idea is with a watermark we can avoid
>>>>>> hinting until we start having pages that are actually going to stay
>>>>>> free for a while.
>>>>>>
>>>>>>>>  It is another reason why we
>>>>>>>> probably want a bit in the buddy pages somewhere to indicate if a page
>>>>>>>> has been hinted or not as we can then use that to determine if we have
>>>>>>>> to account for it in the statistics.
>>>>>>> The one benefit which I can see of having an explicit bit is that it
>>>>>>> will help us to have a single hook away from the hot path within buddy
>>>>>>> merging code (just like your arch_merge_page) and still avoid duplicate
>>>>>>> hints while releasing pages.
>>>>>>>
>>>>>>> I still have to check PG_idle and PG_young which you mentioned but I
>>>>>>> don't think we can reuse any existing bits.
>>>>>> Those are bits that are already there for 64b. I think those exist in
>>>>>> the page extension for 32b systems. If I am not mistaken they are only
>>>>>> used in VMA mapped memory. What I was getting at is that those are the
>>>>>> bits we could think about reusing.
>>>>>>
>>>>>>> If we really want to have something like a watermark, then can't we use
>>>>>>> zone->free_pages before isolating to see how many free pages are there
>>>>>>> and put a threshold on it? (__isolate_free_page() does a similar thing
>>>>>>> but it does that on per request basis).
>>>>>> Right. That is only part of it though since that tells you how many
>>>>>> free pages are there. But how many of those free pages are hinted?
>>>>>> That is the part we would need to track separately and then then
>>>>>> compare to free_pages to determine if we need to start hinting on more
>>>>>> memory or not.
>>>>> Only pages which are isolated will be hinted, and once a page is
>>>>> isolated it will not be counted in the zone free pages.
>>>>> Feel free to correct me if I am wrong.
>>>> You are correct up to here. When we isolate the page it isn't counted
>>>> against the free pages. However after we complete the hint we end up
>>>> taking it out of isolation and returning it to the "free" state, so it
>>>> will be counted against the free pages.
>>>>
>>>>> If I am understanding it correctly you only want to hint the idle pages,
>>>>> is that right?
>>>> Getting back to the ideas from our earlier discussion, we had 3 stages
>>>> for things. Free but not hinted, isolated due to hinting, and free and
>>>> hinted. So what we would need to do is identify the size of the first
>>>> pool that is free and not hinted by knowing the total number of free
>>>> pages, and then subtract the size of the pages that are hinted and
>>>> still free.
>>> To summarize, for now, I think it makes sense to stick with the current
>>> approach as this way we can avoid any locking in the allocation path and
>>> reduce the number of hypercalls for a bunch of MAX_ORDER - 1 page.
>> I'm not sure what you are talking about by "avoid any locking in the
>> allocation path". Are you talking about the spin on idle bit, if so
>> then yes. 
> Yeap!
>> However I have been testing your patches and I was correct
>> in the assumption that you forgot to handle the zone lock when you
>> were freeing __free_one_page.
> Yes, these are the steps other than the comments you provided in the
> code. (One of them is to fix release_buddy_page())
>>  I just did a quick copy/paste from your
>> zone lock handling from the guest_free_page_hinting function into the
>> release_buddy_pages function and then I was able to enable multiple
>> CPUs without any issues.
>>
>>> For the next step other than the comments received in the code and what
>>> I mentioned in the cover email, I would like to do the following:
>>> 1. Explore the watermark idea suggested by Alex and bring down memhog
>>> execution time if possible.
>> So there are a few things that are hurting us on the memhog test:
>> 1. The current QEMU patch is only madvising 4K pages at a time, this
>> is disabling THP and hurts the test.
> Makes sense, thanks for pointing this out.
>>
>> 2. The fact that we madvise the pages away makes it so that we have to
>> fault the page back in in order to use it for the memhog test. In
>> order to avoid that penalty we may want to see if we can introduce
>> some sort of "timeout" on the pages so that we are only hinting away
>> old pages that have not been used for some period of time.
> 
> Possibly using MADVISE_FREE should also help in this, I will try this as
> well.

I was asking myself some time ago how MADVISE_FREE will be handled in
case of THP. Please let me know your findings :)

-- 

Thanks,

David / dhildenb

Re: [RFC][Patch v9 2/6] KVM: Enables the kernel to isolate guest free pages

[Nitesh Narayan Lal]

[-- Attachment #1.1: Type: text/plain, Size: 6801 bytes --]

On 3/13/19 8:17 AM, David Hildenbrand wrote:
> On 13.03.19 12:54, Nitesh Narayan Lal wrote:
>> On 3/12/19 5:13 PM, Alexander Duyck wrote:
>>> On Tue, Mar 12, 2019 at 12:46 PM Nitesh Narayan Lal <nitesh@redhat.com> wrote:
>>>> On 3/8/19 4:39 PM, Alexander Duyck wrote:
>>>>> On Fri, Mar 8, 2019 at 11:39 AM Nitesh Narayan Lal <nitesh@redhat.com> wrote:
>>>>>> On 3/8/19 2:25 PM, Alexander Duyck wrote:
>>>>>>> On Fri, Mar 8, 2019 at 11:10 AM Nitesh Narayan Lal <nitesh@redhat.com> wrote:
>>>>>>>> On 3/8/19 1:06 PM, Alexander Duyck wrote:
>>>>>>>>> On Thu, Mar 7, 2019 at 6:32 PM Michael S. Tsirkin <mst@redhat.com> wrote:
>>>>>>>>>> On Thu, Mar 07, 2019 at 02:35:53PM -0800, Alexander Duyck wrote:
>>>>>>>>>>> The only other thing I still want to try and see if I can do is to add
>>>>>>>>>>> a jiffies value to the page private data in the case of the buddy
>>>>>>>>>>> pages.
>>>>>>>>>> Actually there's one extra thing I think we should do, and that is make
>>>>>>>>>> sure we do not leave less than X% off the free memory at a time.
>>>>>>>>>> This way chances of triggering an OOM are lower.
>>>>>>>>> If nothing else we could probably look at doing a watermark of some
>>>>>>>>> sort so we have to have X amount of memory free but not hinted before
>>>>>>>>> we will start providing the hints. It would just be a matter of
>>>>>>>>> tracking how much memory we have hinted on versus the amount of memory
>>>>>>>>> that has been pulled from that pool.
>>>>>>>> This is to avoid false OOM in the guest?
>>>>>>> Partially, though it would still be possible. Basically it would just
>>>>>>> be a way of determining when we have hinted "enough". Basically it
>>>>>>> doesn't do us much good to be hinting on free memory if the guest is
>>>>>>> already constrained and just going to reallocate the memory shortly
>>>>>>> after we hinted on it. The idea is with a watermark we can avoid
>>>>>>> hinting until we start having pages that are actually going to stay
>>>>>>> free for a while.
>>>>>>>
>>>>>>>>>  It is another reason why we
>>>>>>>>> probably want a bit in the buddy pages somewhere to indicate if a page
>>>>>>>>> has been hinted or not as we can then use that to determine if we have
>>>>>>>>> to account for it in the statistics.
>>>>>>>> The one benefit which I can see of having an explicit bit is that it
>>>>>>>> will help us to have a single hook away from the hot path within buddy
>>>>>>>> merging code (just like your arch_merge_page) and still avoid duplicate
>>>>>>>> hints while releasing pages.
>>>>>>>>
>>>>>>>> I still have to check PG_idle and PG_young which you mentioned but I
>>>>>>>> don't think we can reuse any existing bits.
>>>>>>> Those are bits that are already there for 64b. I think those exist in
>>>>>>> the page extension for 32b systems. If I am not mistaken they are only
>>>>>>> used in VMA mapped memory. What I was getting at is that those are the
>>>>>>> bits we could think about reusing.
>>>>>>>
>>>>>>>> If we really want to have something like a watermark, then can't we use
>>>>>>>> zone->free_pages before isolating to see how many free pages are there
>>>>>>>> and put a threshold on it? (__isolate_free_page() does a similar thing
>>>>>>>> but it does that on per request basis).
>>>>>>> Right. That is only part of it though since that tells you how many
>>>>>>> free pages are there. But how many of those free pages are hinted?
>>>>>>> That is the part we would need to track separately and then then
>>>>>>> compare to free_pages to determine if we need to start hinting on more
>>>>>>> memory or not.
>>>>>> Only pages which are isolated will be hinted, and once a page is
>>>>>> isolated it will not be counted in the zone free pages.
>>>>>> Feel free to correct me if I am wrong.
>>>>> You are correct up to here. When we isolate the page it isn't counted
>>>>> against the free pages. However after we complete the hint we end up
>>>>> taking it out of isolation and returning it to the "free" state, so it
>>>>> will be counted against the free pages.
>>>>>
>>>>>> If I am understanding it correctly you only want to hint the idle pages,
>>>>>> is that right?
>>>>> Getting back to the ideas from our earlier discussion, we had 3 stages
>>>>> for things. Free but not hinted, isolated due to hinting, and free and
>>>>> hinted. So what we would need to do is identify the size of the first
>>>>> pool that is free and not hinted by knowing the total number of free
>>>>> pages, and then subtract the size of the pages that are hinted and
>>>>> still free.
>>>> To summarize, for now, I think it makes sense to stick with the current
>>>> approach as this way we can avoid any locking in the allocation path and
>>>> reduce the number of hypercalls for a bunch of MAX_ORDER - 1 page.
>>> I'm not sure what you are talking about by "avoid any locking in the
>>> allocation path". Are you talking about the spin on idle bit, if so
>>> then yes. 
>> Yeap!
>>> However I have been testing your patches and I was correct
>>> in the assumption that you forgot to handle the zone lock when you
>>> were freeing __free_one_page.
>> Yes, these are the steps other than the comments you provided in the
>> code. (One of them is to fix release_buddy_page())
>>>  I just did a quick copy/paste from your
>>> zone lock handling from the guest_free_page_hinting function into the
>>> release_buddy_pages function and then I was able to enable multiple
>>> CPUs without any issues.
>>>
>>>> For the next step other than the comments received in the code and what
>>>> I mentioned in the cover email, I would like to do the following:
>>>> 1. Explore the watermark idea suggested by Alex and bring down memhog
>>>> execution time if possible.
>>> So there are a few things that are hurting us on the memhog test:
>>> 1. The current QEMU patch is only madvising 4K pages at a time, this
>>> is disabling THP and hurts the test.
>> Makes sense, thanks for pointing this out.
>>> 2. The fact that we madvise the pages away makes it so that we have to
>>> fault the page back in in order to use it for the memhog test. In
>>> order to avoid that penalty we may want to see if we can introduce
>>> some sort of "timeout" on the pages so that we are only hinting away
>>> old pages that have not been used for some period of time.
>> Possibly using MADVISE_FREE should also help in this, I will try this as
>> well.
> I was asking myself some time ago how MADVISE_FREE will be handled in
> case of THP. Please let me know your findings :)
I will do that.
If we don't end up finding any appropriate page flag to track the age of
free page. I am wondering if I can somehow use bitmap to track the free
count for each PFN.
>
-- 
Regards
Nitesh


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [RFC][Patch v9 2/6] KVM: Enables the kernel to isolate guest free pages

[Alexander Duyck]

On Wed, Mar 13, 2019 at 5:18 AM David Hildenbrand <david@redhat.com> wrote:
>
> On 13.03.19 12:54, Nitesh Narayan Lal wrote:
> >
> > On 3/12/19 5:13 PM, Alexander Duyck wrote:
> >> On Tue, Mar 12, 2019 at 12:46 PM Nitesh Narayan Lal <nitesh@redhat.com> wrote:
> >>> On 3/8/19 4:39 PM, Alexander Duyck wrote:
> >>>> On Fri, Mar 8, 2019 at 11:39 AM Nitesh Narayan Lal <nitesh@redhat.com> wrote:
> >>>>> On 3/8/19 2:25 PM, Alexander Duyck wrote:
> >>>>>> On Fri, Mar 8, 2019 at 11:10 AM Nitesh Narayan Lal <nitesh@redhat.com> wrote:
> >>>>>>> On 3/8/19 1:06 PM, Alexander Duyck wrote:
> >>>>>>>> On Thu, Mar 7, 2019 at 6:32 PM Michael S. Tsirkin <mst@redhat.com> wrote:
> >>>>>>>>> On Thu, Mar 07, 2019 at 02:35:53PM -0800, Alexander Duyck wrote:
> >>>>>>>>>> The only other thing I still want to try and see if I can do is to add
> >>>>>>>>>> a jiffies value to the page private data in the case of the buddy
> >>>>>>>>>> pages.
> >>>>>>>>> Actually there's one extra thing I think we should do, and that is make
> >>>>>>>>> sure we do not leave less than X% off the free memory at a time.
> >>>>>>>>> This way chances of triggering an OOM are lower.
> >>>>>>>> If nothing else we could probably look at doing a watermark of some
> >>>>>>>> sort so we have to have X amount of memory free but not hinted before
> >>>>>>>> we will start providing the hints. It would just be a matter of
> >>>>>>>> tracking how much memory we have hinted on versus the amount of memory
> >>>>>>>> that has been pulled from that pool.
> >>>>>>> This is to avoid false OOM in the guest?
> >>>>>> Partially, though it would still be possible. Basically it would just
> >>>>>> be a way of determining when we have hinted "enough". Basically it
> >>>>>> doesn't do us much good to be hinting on free memory if the guest is
> >>>>>> already constrained and just going to reallocate the memory shortly
> >>>>>> after we hinted on it. The idea is with a watermark we can avoid
> >>>>>> hinting until we start having pages that are actually going to stay
> >>>>>> free for a while.
> >>>>>>
> >>>>>>>>  It is another reason why we
> >>>>>>>> probably want a bit in the buddy pages somewhere to indicate if a page
> >>>>>>>> has been hinted or not as we can then use that to determine if we have
> >>>>>>>> to account for it in the statistics.
> >>>>>>> The one benefit which I can see of having an explicit bit is that it
> >>>>>>> will help us to have a single hook away from the hot path within buddy
> >>>>>>> merging code (just like your arch_merge_page) and still avoid duplicate
> >>>>>>> hints while releasing pages.
> >>>>>>>
> >>>>>>> I still have to check PG_idle and PG_young which you mentioned but I
> >>>>>>> don't think we can reuse any existing bits.
> >>>>>> Those are bits that are already there for 64b. I think those exist in
> >>>>>> the page extension for 32b systems. If I am not mistaken they are only
> >>>>>> used in VMA mapped memory. What I was getting at is that those are the
> >>>>>> bits we could think about reusing.
> >>>>>>
> >>>>>>> If we really want to have something like a watermark, then can't we use
> >>>>>>> zone->free_pages before isolating to see how many free pages are there
> >>>>>>> and put a threshold on it? (__isolate_free_page() does a similar thing
> >>>>>>> but it does that on per request basis).
> >>>>>> Right. That is only part of it though since that tells you how many
> >>>>>> free pages are there. But how many of those free pages are hinted?
> >>>>>> That is the part we would need to track separately and then then
> >>>>>> compare to free_pages to determine if we need to start hinting on more
> >>>>>> memory or not.
> >>>>> Only pages which are isolated will be hinted, and once a page is
> >>>>> isolated it will not be counted in the zone free pages.
> >>>>> Feel free to correct me if I am wrong.
> >>>> You are correct up to here. When we isolate the page it isn't counted
> >>>> against the free pages. However after we complete the hint we end up
> >>>> taking it out of isolation and returning it to the "free" state, so it
> >>>> will be counted against the free pages.
> >>>>
> >>>>> If I am understanding it correctly you only want to hint the idle pages,
> >>>>> is that right?
> >>>> Getting back to the ideas from our earlier discussion, we had 3 stages
> >>>> for things. Free but not hinted, isolated due to hinting, and free and
> >>>> hinted. So what we would need to do is identify the size of the first
> >>>> pool that is free and not hinted by knowing the total number of free
> >>>> pages, and then subtract the size of the pages that are hinted and
> >>>> still free.
> >>> To summarize, for now, I think it makes sense to stick with the current
> >>> approach as this way we can avoid any locking in the allocation path and
> >>> reduce the number of hypercalls for a bunch of MAX_ORDER - 1 page.
> >> I'm not sure what you are talking about by "avoid any locking in the
> >> allocation path". Are you talking about the spin on idle bit, if so
> >> then yes.
> > Yeap!
> >> However I have been testing your patches and I was correct
> >> in the assumption that you forgot to handle the zone lock when you
> >> were freeing __free_one_page.
> > Yes, these are the steps other than the comments you provided in the
> > code. (One of them is to fix release_buddy_page())
> >>  I just did a quick copy/paste from your
> >> zone lock handling from the guest_free_page_hinting function into the
> >> release_buddy_pages function and then I was able to enable multiple
> >> CPUs without any issues.
> >>
> >>> For the next step other than the comments received in the code and what
> >>> I mentioned in the cover email, I would like to do the following:
> >>> 1. Explore the watermark idea suggested by Alex and bring down memhog
> >>> execution time if possible.
> >> So there are a few things that are hurting us on the memhog test:
> >> 1. The current QEMU patch is only madvising 4K pages at a time, this
> >> is disabling THP and hurts the test.
> > Makes sense, thanks for pointing this out.
> >>
> >> 2. The fact that we madvise the pages away makes it so that we have to
> >> fault the page back in in order to use it for the memhog test. In
> >> order to avoid that penalty we may want to see if we can introduce
> >> some sort of "timeout" on the pages so that we are only hinting away
> >> old pages that have not been used for some period of time.
> >
> > Possibly using MADVISE_FREE should also help in this, I will try this as
> > well.
>
> I was asking myself some time ago how MADVISE_FREE will be handled in
> case of THP. Please let me know your findings :)

The problem with MADVISE_FREE is that it will add additional
complication to the QEMU portion of all this as it only applies to
anonymous memory if I am not mistaken.

That also reminds me that one thing this patch set still doesn't
address is what do we do about a direct assigned device or some other
form of shared memory where we want to keep the virtual mapping
beneath the guest pinned to a given set of physical memory.

Re: [RFC][Patch v9 2/6] KVM: Enables the kernel to isolate guest free pages

[David Hildenbrand]

On 13.03.19 17:37, Alexander Duyck wrote:
> On Wed, Mar 13, 2019 at 5:18 AM David Hildenbrand <david@redhat.com> wrote:
>>
>> On 13.03.19 12:54, Nitesh Narayan Lal wrote:
>>>
>>> On 3/12/19 5:13 PM, Alexander Duyck wrote:
>>>> On Tue, Mar 12, 2019 at 12:46 PM Nitesh Narayan Lal <nitesh@redhat.com> wrote:
>>>>> On 3/8/19 4:39 PM, Alexander Duyck wrote:
>>>>>> On Fri, Mar 8, 2019 at 11:39 AM Nitesh Narayan Lal <nitesh@redhat.com> wrote:
>>>>>>> On 3/8/19 2:25 PM, Alexander Duyck wrote:
>>>>>>>> On Fri, Mar 8, 2019 at 11:10 AM Nitesh Narayan Lal <nitesh@redhat.com> wrote:
>>>>>>>>> On 3/8/19 1:06 PM, Alexander Duyck wrote:
>>>>>>>>>> On Thu, Mar 7, 2019 at 6:32 PM Michael S. Tsirkin <mst@redhat.com> wrote:
>>>>>>>>>>> On Thu, Mar 07, 2019 at 02:35:53PM -0800, Alexander Duyck wrote:
>>>>>>>>>>>> The only other thing I still want to try and see if I can do is to add
>>>>>>>>>>>> a jiffies value to the page private data in the case of the buddy
>>>>>>>>>>>> pages.
>>>>>>>>>>> Actually there's one extra thing I think we should do, and that is make
>>>>>>>>>>> sure we do not leave less than X% off the free memory at a time.
>>>>>>>>>>> This way chances of triggering an OOM are lower.
>>>>>>>>>> If nothing else we could probably look at doing a watermark of some
>>>>>>>>>> sort so we have to have X amount of memory free but not hinted before
>>>>>>>>>> we will start providing the hints. It would just be a matter of
>>>>>>>>>> tracking how much memory we have hinted on versus the amount of memory
>>>>>>>>>> that has been pulled from that pool.
>>>>>>>>> This is to avoid false OOM in the guest?
>>>>>>>> Partially, though it would still be possible. Basically it would just
>>>>>>>> be a way of determining when we have hinted "enough". Basically it
>>>>>>>> doesn't do us much good to be hinting on free memory if the guest is
>>>>>>>> already constrained and just going to reallocate the memory shortly
>>>>>>>> after we hinted on it. The idea is with a watermark we can avoid
>>>>>>>> hinting until we start having pages that are actually going to stay
>>>>>>>> free for a while.
>>>>>>>>
>>>>>>>>>>  It is another reason why we
>>>>>>>>>> probably want a bit in the buddy pages somewhere to indicate if a page
>>>>>>>>>> has been hinted or not as we can then use that to determine if we have
>>>>>>>>>> to account for it in the statistics.
>>>>>>>>> The one benefit which I can see of having an explicit bit is that it
>>>>>>>>> will help us to have a single hook away from the hot path within buddy
>>>>>>>>> merging code (just like your arch_merge_page) and still avoid duplicate
>>>>>>>>> hints while releasing pages.
>>>>>>>>>
>>>>>>>>> I still have to check PG_idle and PG_young which you mentioned but I
>>>>>>>>> don't think we can reuse any existing bits.
>>>>>>>> Those are bits that are already there for 64b. I think those exist in
>>>>>>>> the page extension for 32b systems. If I am not mistaken they are only
>>>>>>>> used in VMA mapped memory. What I was getting at is that those are the
>>>>>>>> bits we could think about reusing.
>>>>>>>>
>>>>>>>>> If we really want to have something like a watermark, then can't we use
>>>>>>>>> zone->free_pages before isolating to see how many free pages are there
>>>>>>>>> and put a threshold on it? (__isolate_free_page() does a similar thing
>>>>>>>>> but it does that on per request basis).
>>>>>>>> Right. That is only part of it though since that tells you how many
>>>>>>>> free pages are there. But how many of those free pages are hinted?
>>>>>>>> That is the part we would need to track separately and then then
>>>>>>>> compare to free_pages to determine if we need to start hinting on more
>>>>>>>> memory or not.
>>>>>>> Only pages which are isolated will be hinted, and once a page is
>>>>>>> isolated it will not be counted in the zone free pages.
>>>>>>> Feel free to correct me if I am wrong.
>>>>>> You are correct up to here. When we isolate the page it isn't counted
>>>>>> against the free pages. However after we complete the hint we end up
>>>>>> taking it out of isolation and returning it to the "free" state, so it
>>>>>> will be counted against the free pages.
>>>>>>
>>>>>>> If I am understanding it correctly you only want to hint the idle pages,
>>>>>>> is that right?
>>>>>> Getting back to the ideas from our earlier discussion, we had 3 stages
>>>>>> for things. Free but not hinted, isolated due to hinting, and free and
>>>>>> hinted. So what we would need to do is identify the size of the first
>>>>>> pool that is free and not hinted by knowing the total number of free
>>>>>> pages, and then subtract the size of the pages that are hinted and
>>>>>> still free.
>>>>> To summarize, for now, I think it makes sense to stick with the current
>>>>> approach as this way we can avoid any locking in the allocation path and
>>>>> reduce the number of hypercalls for a bunch of MAX_ORDER - 1 page.
>>>> I'm not sure what you are talking about by "avoid any locking in the
>>>> allocation path". Are you talking about the spin on idle bit, if so
>>>> then yes.
>>> Yeap!
>>>> However I have been testing your patches and I was correct
>>>> in the assumption that you forgot to handle the zone lock when you
>>>> were freeing __free_one_page.
>>> Yes, these are the steps other than the comments you provided in the
>>> code. (One of them is to fix release_buddy_page())
>>>>  I just did a quick copy/paste from your
>>>> zone lock handling from the guest_free_page_hinting function into the
>>>> release_buddy_pages function and then I was able to enable multiple
>>>> CPUs without any issues.
>>>>
>>>>> For the next step other than the comments received in the code and what
>>>>> I mentioned in the cover email, I would like to do the following:
>>>>> 1. Explore the watermark idea suggested by Alex and bring down memhog
>>>>> execution time if possible.
>>>> So there are a few things that are hurting us on the memhog test:
>>>> 1. The current QEMU patch is only madvising 4K pages at a time, this
>>>> is disabling THP and hurts the test.
>>> Makes sense, thanks for pointing this out.
>>>>
>>>> 2. The fact that we madvise the pages away makes it so that we have to
>>>> fault the page back in in order to use it for the memhog test. In
>>>> order to avoid that penalty we may want to see if we can introduce
>>>> some sort of "timeout" on the pages so that we are only hinting away
>>>> old pages that have not been used for some period of time.
>>>
>>> Possibly using MADVISE_FREE should also help in this, I will try this as
>>> well.
>>
>> I was asking myself some time ago how MADVISE_FREE will be handled in
>> case of THP. Please let me know your findings :)
> 
> The problem with MADVISE_FREE is that it will add additional
> complication to the QEMU portion of all this as it only applies to
> anonymous memory if I am not mistaken.

Just as MADV_DONTNEED. So nothing new. Future work.

-- 

Thanks,

David / dhildenb

Re: [RFC][Patch v9 2/6] KVM: Enables the kernel to isolate guest free pages

[Alexander Duyck]

On Wed, Mar 13, 2019 at 9:39 AM David Hildenbrand <david@redhat.com> wrote:
>
> On 13.03.19 17:37, Alexander Duyck wrote:
> > On Wed, Mar 13, 2019 at 5:18 AM David Hildenbrand <david@redhat.com> wrote:
> >>
> >> On 13.03.19 12:54, Nitesh Narayan Lal wrote:
> >>>
> >>> On 3/12/19 5:13 PM, Alexander Duyck wrote:
> >>>> On Tue, Mar 12, 2019 at 12:46 PM Nitesh Narayan Lal <nitesh@redhat.com> wrote:
> >>>>> On 3/8/19 4:39 PM, Alexander Duyck wrote:
> >>>>>> On Fri, Mar 8, 2019 at 11:39 AM Nitesh Narayan Lal <nitesh@redhat.com> wrote:
> >>>>>>> On 3/8/19 2:25 PM, Alexander Duyck wrote:
> >>>>>>>> On Fri, Mar 8, 2019 at 11:10 AM Nitesh Narayan Lal <nitesh@redhat.com> wrote:
> >>>>>>>>> On 3/8/19 1:06 PM, Alexander Duyck wrote:
> >>>>>>>>>> On Thu, Mar 7, 2019 at 6:32 PM Michael S. Tsirkin <mst@redhat.com> wrote:
> >>>>>>>>>>> On Thu, Mar 07, 2019 at 02:35:53PM -0800, Alexander Duyck wrote:
> >>>>>>>>>>>> The only other thing I still want to try and see if I can do is to add
> >>>>>>>>>>>> a jiffies value to the page private data in the case of the buddy
> >>>>>>>>>>>> pages.
> >>>>>>>>>>> Actually there's one extra thing I think we should do, and that is make
> >>>>>>>>>>> sure we do not leave less than X% off the free memory at a time.
> >>>>>>>>>>> This way chances of triggering an OOM are lower.
> >>>>>>>>>> If nothing else we could probably look at doing a watermark of some
> >>>>>>>>>> sort so we have to have X amount of memory free but not hinted before
> >>>>>>>>>> we will start providing the hints. It would just be a matter of
> >>>>>>>>>> tracking how much memory we have hinted on versus the amount of memory
> >>>>>>>>>> that has been pulled from that pool.
> >>>>>>>>> This is to avoid false OOM in the guest?
> >>>>>>>> Partially, though it would still be possible. Basically it would just
> >>>>>>>> be a way of determining when we have hinted "enough". Basically it
> >>>>>>>> doesn't do us much good to be hinting on free memory if the guest is
> >>>>>>>> already constrained and just going to reallocate the memory shortly
> >>>>>>>> after we hinted on it. The idea is with a watermark we can avoid
> >>>>>>>> hinting until we start having pages that are actually going to stay
> >>>>>>>> free for a while.
> >>>>>>>>
> >>>>>>>>>>  It is another reason why we
> >>>>>>>>>> probably want a bit in the buddy pages somewhere to indicate if a page
> >>>>>>>>>> has been hinted or not as we can then use that to determine if we have
> >>>>>>>>>> to account for it in the statistics.
> >>>>>>>>> The one benefit which I can see of having an explicit bit is that it
> >>>>>>>>> will help us to have a single hook away from the hot path within buddy
> >>>>>>>>> merging code (just like your arch_merge_page) and still avoid duplicate
> >>>>>>>>> hints while releasing pages.
> >>>>>>>>>
> >>>>>>>>> I still have to check PG_idle and PG_young which you mentioned but I
> >>>>>>>>> don't think we can reuse any existing bits.
> >>>>>>>> Those are bits that are already there for 64b. I think those exist in
> >>>>>>>> the page extension for 32b systems. If I am not mistaken they are only
> >>>>>>>> used in VMA mapped memory. What I was getting at is that those are the
> >>>>>>>> bits we could think about reusing.
> >>>>>>>>
> >>>>>>>>> If we really want to have something like a watermark, then can't we use
> >>>>>>>>> zone->free_pages before isolating to see how many free pages are there
> >>>>>>>>> and put a threshold on it? (__isolate_free_page() does a similar thing
> >>>>>>>>> but it does that on per request basis).
> >>>>>>>> Right. That is only part of it though since that tells you how many
> >>>>>>>> free pages are there. But how many of those free pages are hinted?
> >>>>>>>> That is the part we would need to track separately and then then
> >>>>>>>> compare to free_pages to determine if we need to start hinting on more
> >>>>>>>> memory or not.
> >>>>>>> Only pages which are isolated will be hinted, and once a page is
> >>>>>>> isolated it will not be counted in the zone free pages.
> >>>>>>> Feel free to correct me if I am wrong.
> >>>>>> You are correct up to here. When we isolate the page it isn't counted
> >>>>>> against the free pages. However after we complete the hint we end up
> >>>>>> taking it out of isolation and returning it to the "free" state, so it
> >>>>>> will be counted against the free pages.
> >>>>>>
> >>>>>>> If I am understanding it correctly you only want to hint the idle pages,
> >>>>>>> is that right?
> >>>>>> Getting back to the ideas from our earlier discussion, we had 3 stages
> >>>>>> for things. Free but not hinted, isolated due to hinting, and free and
> >>>>>> hinted. So what we would need to do is identify the size of the first
> >>>>>> pool that is free and not hinted by knowing the total number of free
> >>>>>> pages, and then subtract the size of the pages that are hinted and
> >>>>>> still free.
> >>>>> To summarize, for now, I think it makes sense to stick with the current
> >>>>> approach as this way we can avoid any locking in the allocation path and
> >>>>> reduce the number of hypercalls for a bunch of MAX_ORDER - 1 page.
> >>>> I'm not sure what you are talking about by "avoid any locking in the
> >>>> allocation path". Are you talking about the spin on idle bit, if so
> >>>> then yes.
> >>> Yeap!
> >>>> However I have been testing your patches and I was correct
> >>>> in the assumption that you forgot to handle the zone lock when you
> >>>> were freeing __free_one_page.
> >>> Yes, these are the steps other than the comments you provided in the
> >>> code. (One of them is to fix release_buddy_page())
> >>>>  I just did a quick copy/paste from your
> >>>> zone lock handling from the guest_free_page_hinting function into the
> >>>> release_buddy_pages function and then I was able to enable multiple
> >>>> CPUs without any issues.
> >>>>
> >>>>> For the next step other than the comments received in the code and what
> >>>>> I mentioned in the cover email, I would like to do the following:
> >>>>> 1. Explore the watermark idea suggested by Alex and bring down memhog
> >>>>> execution time if possible.
> >>>> So there are a few things that are hurting us on the memhog test:
> >>>> 1. The current QEMU patch is only madvising 4K pages at a time, this
> >>>> is disabling THP and hurts the test.
> >>> Makes sense, thanks for pointing this out.
> >>>>
> >>>> 2. The fact that we madvise the pages away makes it so that we have to
> >>>> fault the page back in in order to use it for the memhog test. In
> >>>> order to avoid that penalty we may want to see if we can introduce
> >>>> some sort of "timeout" on the pages so that we are only hinting away
> >>>> old pages that have not been used for some period of time.
> >>>
> >>> Possibly using MADVISE_FREE should also help in this, I will try this as
> >>> well.
> >>
> >> I was asking myself some time ago how MADVISE_FREE will be handled in
> >> case of THP. Please let me know your findings :)
> >
> > The problem with MADVISE_FREE is that it will add additional
> > complication to the QEMU portion of all this as it only applies to
> > anonymous memory if I am not mistaken.
>
> Just as MADV_DONTNEED. So nothing new. Future work.

I'm pretty sure you can use MADV_DONTNEED to free up file backed
memory, I don't believe this is the case for MADV_FREE, but maybe I am
mistaken.

On a side note I was just reviewing some stuff related to the reserved
bit and on-lining hotplug memory, and it just occurred to me that most
the PG_offline bit would be a good means to indicate that we hinted
away a page out of the buddy allocator, especially since it is already
used by the balloon drivers anyway.  We would just have to add a call
to make sure we clear it when we call __ClearPageBuddy. It looks like
that would currently be in del_page_from_free_area, at least for
linux-next.

I just wanted to get your thoughts on that as it seems like it might
be a good fit.

Thanks.

- Alex

Re: [RFC][Patch v9 2/6] KVM: Enables the kernel to isolate guest free pages

[David Hildenbrand]

On 13.03.19 23:54, Alexander Duyck wrote:
> On Wed, Mar 13, 2019 at 9:39 AM David Hildenbrand <david@redhat.com> wrote:
>>
>> On 13.03.19 17:37, Alexander Duyck wrote:
>>> On Wed, Mar 13, 2019 at 5:18 AM David Hildenbrand <david@redhat.com> wrote:
>>>>
>>>> On 13.03.19 12:54, Nitesh Narayan Lal wrote:
>>>>>
>>>>> On 3/12/19 5:13 PM, Alexander Duyck wrote:
>>>>>> On Tue, Mar 12, 2019 at 12:46 PM Nitesh Narayan Lal <nitesh@redhat.com> wrote:
>>>>>>> On 3/8/19 4:39 PM, Alexander Duyck wrote:
>>>>>>>> On Fri, Mar 8, 2019 at 11:39 AM Nitesh Narayan Lal <nitesh@redhat.com> wrote:
>>>>>>>>> On 3/8/19 2:25 PM, Alexander Duyck wrote:
>>>>>>>>>> On Fri, Mar 8, 2019 at 11:10 AM Nitesh Narayan Lal <nitesh@redhat.com> wrote:
>>>>>>>>>>> On 3/8/19 1:06 PM, Alexander Duyck wrote:
>>>>>>>>>>>> On Thu, Mar 7, 2019 at 6:32 PM Michael S. Tsirkin <mst@redhat.com> wrote:
>>>>>>>>>>>>> On Thu, Mar 07, 2019 at 02:35:53PM -0800, Alexander Duyck wrote:
>>>>>>>>>>>>>> The only other thing I still want to try and see if I can do is to add
>>>>>>>>>>>>>> a jiffies value to the page private data in the case of the buddy
>>>>>>>>>>>>>> pages.
>>>>>>>>>>>>> Actually there's one extra thing I think we should do, and that is make
>>>>>>>>>>>>> sure we do not leave less than X% off the free memory at a time.
>>>>>>>>>>>>> This way chances of triggering an OOM are lower.
>>>>>>>>>>>> If nothing else we could probably look at doing a watermark of some
>>>>>>>>>>>> sort so we have to have X amount of memory free but not hinted before
>>>>>>>>>>>> we will start providing the hints. It would just be a matter of
>>>>>>>>>>>> tracking how much memory we have hinted on versus the amount of memory
>>>>>>>>>>>> that has been pulled from that pool.
>>>>>>>>>>> This is to avoid false OOM in the guest?
>>>>>>>>>> Partially, though it would still be possible. Basically it would just
>>>>>>>>>> be a way of determining when we have hinted "enough". Basically it
>>>>>>>>>> doesn't do us much good to be hinting on free memory if the guest is
>>>>>>>>>> already constrained and just going to reallocate the memory shortly
>>>>>>>>>> after we hinted on it. The idea is with a watermark we can avoid
>>>>>>>>>> hinting until we start having pages that are actually going to stay
>>>>>>>>>> free for a while.
>>>>>>>>>>
>>>>>>>>>>>>  It is another reason why we
>>>>>>>>>>>> probably want a bit in the buddy pages somewhere to indicate if a page
>>>>>>>>>>>> has been hinted or not as we can then use that to determine if we have
>>>>>>>>>>>> to account for it in the statistics.
>>>>>>>>>>> The one benefit which I can see of having an explicit bit is that it
>>>>>>>>>>> will help us to have a single hook away from the hot path within buddy
>>>>>>>>>>> merging code (just like your arch_merge_page) and still avoid duplicate
>>>>>>>>>>> hints while releasing pages.
>>>>>>>>>>>
>>>>>>>>>>> I still have to check PG_idle and PG_young which you mentioned but I
>>>>>>>>>>> don't think we can reuse any existing bits.
>>>>>>>>>> Those are bits that are already there for 64b. I think those exist in
>>>>>>>>>> the page extension for 32b systems. If I am not mistaken they are only
>>>>>>>>>> used in VMA mapped memory. What I was getting at is that those are the
>>>>>>>>>> bits we could think about reusing.
>>>>>>>>>>
>>>>>>>>>>> If we really want to have something like a watermark, then can't we use
>>>>>>>>>>> zone->free_pages before isolating to see how many free pages are there
>>>>>>>>>>> and put a threshold on it? (__isolate_free_page() does a similar thing
>>>>>>>>>>> but it does that on per request basis).
>>>>>>>>>> Right. That is only part of it though since that tells you how many
>>>>>>>>>> free pages are there. But how many of those free pages are hinted?
>>>>>>>>>> That is the part we would need to track separately and then then
>>>>>>>>>> compare to free_pages to determine if we need to start hinting on more
>>>>>>>>>> memory or not.
>>>>>>>>> Only pages which are isolated will be hinted, and once a page is
>>>>>>>>> isolated it will not be counted in the zone free pages.
>>>>>>>>> Feel free to correct me if I am wrong.
>>>>>>>> You are correct up to here. When we isolate the page it isn't counted
>>>>>>>> against the free pages. However after we complete the hint we end up
>>>>>>>> taking it out of isolation and returning it to the "free" state, so it
>>>>>>>> will be counted against the free pages.
>>>>>>>>
>>>>>>>>> If I am understanding it correctly you only want to hint the idle pages,
>>>>>>>>> is that right?
>>>>>>>> Getting back to the ideas from our earlier discussion, we had 3 stages
>>>>>>>> for things. Free but not hinted, isolated due to hinting, and free and
>>>>>>>> hinted. So what we would need to do is identify the size of the first
>>>>>>>> pool that is free and not hinted by knowing the total number of free
>>>>>>>> pages, and then subtract the size of the pages that are hinted and
>>>>>>>> still free.
>>>>>>> To summarize, for now, I think it makes sense to stick with the current
>>>>>>> approach as this way we can avoid any locking in the allocation path and
>>>>>>> reduce the number of hypercalls for a bunch of MAX_ORDER - 1 page.
>>>>>> I'm not sure what you are talking about by "avoid any locking in the
>>>>>> allocation path". Are you talking about the spin on idle bit, if so
>>>>>> then yes.
>>>>> Yeap!
>>>>>> However I have been testing your patches and I was correct
>>>>>> in the assumption that you forgot to handle the zone lock when you
>>>>>> were freeing __free_one_page.
>>>>> Yes, these are the steps other than the comments you provided in the
>>>>> code. (One of them is to fix release_buddy_page())
>>>>>>  I just did a quick copy/paste from your
>>>>>> zone lock handling from the guest_free_page_hinting function into the
>>>>>> release_buddy_pages function and then I was able to enable multiple
>>>>>> CPUs without any issues.
>>>>>>
>>>>>>> For the next step other than the comments received in the code and what
>>>>>>> I mentioned in the cover email, I would like to do the following:
>>>>>>> 1. Explore the watermark idea suggested by Alex and bring down memhog
>>>>>>> execution time if possible.
>>>>>> So there are a few things that are hurting us on the memhog test:
>>>>>> 1. The current QEMU patch is only madvising 4K pages at a time, this
>>>>>> is disabling THP and hurts the test.
>>>>> Makes sense, thanks for pointing this out.
>>>>>>
>>>>>> 2. The fact that we madvise the pages away makes it so that we have to
>>>>>> fault the page back in in order to use it for the memhog test. In
>>>>>> order to avoid that penalty we may want to see if we can introduce
>>>>>> some sort of "timeout" on the pages so that we are only hinting away
>>>>>> old pages that have not been used for some period of time.
>>>>>
>>>>> Possibly using MADVISE_FREE should also help in this, I will try this as
>>>>> well.
>>>>
>>>> I was asking myself some time ago how MADVISE_FREE will be handled in
>>>> case of THP. Please let me know your findings :)
>>>
>>> The problem with MADVISE_FREE is that it will add additional
>>> complication to the QEMU portion of all this as it only applies to
>>> anonymous memory if I am not mistaken.
>>
>> Just as MADV_DONTNEED. So nothing new. Future work.
> 
> I'm pretty sure you can use MADV_DONTNEED to free up file backed
> memory, I don't believe this is the case for MADV_FREE, but maybe I am
> mistaken.

"MADV_DONTNEED cannot be applied to locked pages, Huge TLB pages, or
VM_PFNMAP pages."

For shmem, hugetlbfs and friends one has to use FALLOC_FL_PUNCH_HOLE as
far as I remember (e.g. QEMU postcopy migration has to use it).

So effectively, virtio-balloon can as of now only really deal with
anonymous memory. And it is the same case for free page hinting.

> 
> On a side note I was just reviewing some stuff related to the reserved
> bit and on-lining hotplug memory, and it just occurred to me that most
> the PG_offline bit would be a good means to indicate that we hinted
> away a page out of the buddy allocator, especially since it is already
> used by the balloon drivers anyway.  We would just have to add a call
> to make sure we clear it when we call __ClearPageBuddy. It looks like
> that would currently be in del_page_from_free_area, at least for
> linux-next.

Hmm, if we only knew who came up with PG_offline ... ;)

Unfortunately PG_offline is not a bit, it is mapcount value just like
PG_buddy. Well okay, it is a bit in the mapcount value - but as of now,
a page can only have one such "page type" at a time as far as I recall.

> 
> I just wanted to get your thoughts on that as it seems like it might
> be a good fit.

It would be if we could have multiple page types at a time. I haven't
had a look yet how realistic that would be. As you correctly noted,
balloon drivers use that bit as of now to mark pages that are logically
offline (here: "inflated").

> 
> Thanks.
> 
> - Alex
> 


-- 

Thanks,

David / dhildenb

Re: [RFC][Patch v9 0/6] KVM: Guest Free Page Hinting

[Nitesh Narayan Lal]

[-- Attachment #1.1: Type: text/plain, Size: 6150 bytes --]


On 3/6/19 1:12 PM, Michael S. Tsirkin wrote:
> On Wed, Mar 06, 2019 at 01:07:50PM -0500, Nitesh Narayan Lal wrote:
>> On 3/6/19 11:09 AM, Michael S. Tsirkin wrote:
>>> On Wed, Mar 06, 2019 at 10:50:42AM -0500, Nitesh Narayan Lal wrote:
>>>> The following patch-set proposes an efficient mechanism for handing freed memory between the guest and the host. It enables the guests with no page cache to rapidly free and reclaims memory to and from the host respectively.
>>>>
>>>> Benefit:
>>>> With this patch-series, in our test-case, executed on a single system and single NUMA node with 15GB memory, we were able to successfully launch 5 guests(each with 5 GB memory) when page hinting was enabled and 3 without it. (Detailed explanation of the test procedure is provided at the bottom under Test - 1).
>>>>
>>>> Changelog in v9:
>>>> 	* Guest free page hinting hook is now invoked after a page has been merged in the buddy.
>>>>         * Free pages only with order FREE_PAGE_HINTING_MIN_ORDER(currently defined as MAX_ORDER - 1) are captured.
>>>> 	* Removed kthread which was earlier used to perform the scanning, isolation & reporting of free pages.
>>>> 	* Pages, captured in the per cpu array are sorted based on the zone numbers. This is to avoid redundancy of acquiring zone locks.
>>>>         * Dynamically allocated space is used to hold the isolated guest free pages.
>>>>         * All the pages are reported asynchronously to the host via virtio driver.
>>>>         * Pages are returned back to the guest buddy free list only when the host response is received.
>>>>
>>>> Pending items:
>>>>         * Make sure that the guest free page hinting's current implementation doesn't break hugepages or device assigned guests.
>>>> 	* Follow up on VIRTIO_BALLOON_F_PAGE_POISON's device side support. (It is currently missing)
>>>>         * Compare reporting free pages via vring with vhost.
>>>>         * Decide between MADV_DONTNEED and MADV_FREE.
>>>> 	* Analyze overall performance impact due to guest free page hinting.
>>>> 	* Come up with proper/traceable error-message/logs.
>>>>
>>>> Tests:
>>>> 1. Use-case - Number of guests we can launch
>>>>
>>>> 	NUMA Nodes = 1 with 15 GB memory
>>>> 	Guest Memory = 5 GB
>>>> 	Number of cores in guest = 1
>>>> 	Workload = test allocation program allocates 4GB memory, touches it via memset and exits.
>>>> 	Procedure =
>>>> 	The first guest is launched and once its console is up, the test allocation program is executed with 4 GB memory request (Due to this the guest occupies almost 4-5 GB of memory in the host in a system without page hinting). Once this program exits at that time another guest is launched in the host and the same process is followed. We continue launching the guests until a guest gets killed due to low memory condition in the host.
>>>>
>>>> 	Results:
>>>> 	Without hinting = 3
>>>> 	With hinting = 5
>>>>
>>>> 2. Hackbench
>>>> 	Guest Memory = 5 GB 
>>>> 	Number of cores = 4
>>>> 	Number of tasks		Time with Hinting	Time without Hinting
>>>> 	4000			19.540			17.818
>>>>
>>> How about memhog btw?
>>> Alex reported:
>>>
>>> 	My testing up till now has consisted of setting up 4 8GB VMs on a system
>>> 	with 32GB of memory and 4GB of swap. To stress the memory on the system I
>>> 	would run "memhog 8G" sequentially on each of the guests and observe how
>>> 	long it took to complete the run. The observed behavior is that on the
>>> 	systems with these patches applied in both the guest and on the host I was
>>> 	able to complete the test with a time of 5 to 7 seconds per guest. On a
>>> 	system without these patches the time ranged from 7 to 49 seconds per
>>> 	guest. I am assuming the variability is due to time being spent writing
>>> 	pages out to disk in order to free up space for the guest.
>>>
>> Here are the results:
>>
>> Procedure: 3 Guests of size 5GB is launched on a single NUMA node with
>> total memory of 15GB and no swap. In each of the guest, memhog is run
>> with 5GB. Post-execution of memhog, Host memory usage is monitored by
>> using Free command.
>>
>> Without Hinting:
>>                  Time of execution    Host used memory
>> Guest 1:        45 seconds            5.4 GB
>> Guest 2:        45 seconds            10 GB
>> Guest 3:        1  minute               15 GB
>>
>> With Hinting:
>>                 Time of execution     Host used memory
>> Guest 1:        49 seconds            2.4 GB
>> Guest 2:        40 seconds            4.3 GB
>> Guest 3:        50 seconds            6.3 GB
> OK so no improvement. OTOH Alex's patches cut time down to 5-7 seconds
> which seems better. Want to try testing Alex's patches for comparison?
>
I realized that the last time I reported the memhog numbers, I didn't
enable the swap due to which the actual benefits of the series were not
shown.
I have re-run the test by including some of the changes suggested by
Alexander and David:
    * Reduced the size of the per-cpu array to 32 and minimum hinting
threshold to 16.
    * Reported length of isolated pages along with start pfn, instead of
the order from the guest.
    * Used the reported length to madvise the entire length of address
instead of a single 4K page.
    * Replaced MADV_DONTNEED with MADV_FREE.

Setup for the test:
NUMA node:1
Memory: 15GB
Swap: 4GB
Guest memory: 6GB
Number of core: 1

Process: A guest is launched and memhog is run with 6GB. As its
execution is over next guest is launched. Everytime memhog execution
time is monitored.   
Results:
    Without Hinting:
                 Time of execution
    Guest1:    22s
    Guest2:    24s
    Guest3: 1m29s

    With Hinting:
                Time of execution
    Guest1:    24s
    Guest2:    25s
    Guest3:    28s

When hinting is enabled swap space is not used until memhog with 6GB is
ran in 6th guest.


-- 
Regards
Nitesh


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [RFC][Patch v9 0/6] KVM: Guest Free Page Hinting

[Alexander Duyck]

On Thu, Mar 14, 2019 at 9:43 AM Nitesh Narayan Lal <nitesh@redhat.com> wrote:
>
>
> On 3/6/19 1:12 PM, Michael S. Tsirkin wrote:
> > On Wed, Mar 06, 2019 at 01:07:50PM -0500, Nitesh Narayan Lal wrote:
> >> On 3/6/19 11:09 AM, Michael S. Tsirkin wrote:
> >>> On Wed, Mar 06, 2019 at 10:50:42AM -0500, Nitesh Narayan Lal wrote:
> >>>> The following patch-set proposes an efficient mechanism for handing freed memory between the guest and the host. It enables the guests with no page cache to rapidly free and reclaims memory to and from the host respectively.
> >>>>
> >>>> Benefit:
> >>>> With this patch-series, in our test-case, executed on a single system and single NUMA node with 15GB memory, we were able to successfully launch 5 guests(each with 5 GB memory) when page hinting was enabled and 3 without it. (Detailed explanation of the test procedure is provided at the bottom under Test - 1).
> >>>>
> >>>> Changelog in v9:
> >>>>    * Guest free page hinting hook is now invoked after a page has been merged in the buddy.
> >>>>         * Free pages only with order FREE_PAGE_HINTING_MIN_ORDER(currently defined as MAX_ORDER - 1) are captured.
> >>>>    * Removed kthread which was earlier used to perform the scanning, isolation & reporting of free pages.
> >>>>    * Pages, captured in the per cpu array are sorted based on the zone numbers. This is to avoid redundancy of acquiring zone locks.
> >>>>         * Dynamically allocated space is used to hold the isolated guest free pages.
> >>>>         * All the pages are reported asynchronously to the host via virtio driver.
> >>>>         * Pages are returned back to the guest buddy free list only when the host response is received.
> >>>>
> >>>> Pending items:
> >>>>         * Make sure that the guest free page hinting's current implementation doesn't break hugepages or device assigned guests.
> >>>>    * Follow up on VIRTIO_BALLOON_F_PAGE_POISON's device side support. (It is currently missing)
> >>>>         * Compare reporting free pages via vring with vhost.
> >>>>         * Decide between MADV_DONTNEED and MADV_FREE.
> >>>>    * Analyze overall performance impact due to guest free page hinting.
> >>>>    * Come up with proper/traceable error-message/logs.
> >>>>
> >>>> Tests:
> >>>> 1. Use-case - Number of guests we can launch
> >>>>
> >>>>    NUMA Nodes = 1 with 15 GB memory
> >>>>    Guest Memory = 5 GB
> >>>>    Number of cores in guest = 1
> >>>>    Workload = test allocation program allocates 4GB memory, touches it via memset and exits.
> >>>>    Procedure =
> >>>>    The first guest is launched and once its console is up, the test allocation program is executed with 4 GB memory request (Due to this the guest occupies almost 4-5 GB of memory in the host in a system without page hinting). Once this program exits at that time another guest is launched in the host and the same process is followed. We continue launching the guests until a guest gets killed due to low memory condition in the host.
> >>>>
> >>>>    Results:
> >>>>    Without hinting = 3
> >>>>    With hinting = 5
> >>>>
> >>>> 2. Hackbench
> >>>>    Guest Memory = 5 GB
> >>>>    Number of cores = 4
> >>>>    Number of tasks         Time with Hinting       Time without Hinting
> >>>>    4000                    19.540                  17.818
> >>>>
> >>> How about memhog btw?
> >>> Alex reported:
> >>>
> >>>     My testing up till now has consisted of setting up 4 8GB VMs on a system
> >>>     with 32GB of memory and 4GB of swap. To stress the memory on the system I
> >>>     would run "memhog 8G" sequentially on each of the guests and observe how
> >>>     long it took to complete the run. The observed behavior is that on the
> >>>     systems with these patches applied in both the guest and on the host I was
> >>>     able to complete the test with a time of 5 to 7 seconds per guest. On a
> >>>     system without these patches the time ranged from 7 to 49 seconds per
> >>>     guest. I am assuming the variability is due to time being spent writing
> >>>     pages out to disk in order to free up space for the guest.
> >>>
> >> Here are the results:
> >>
> >> Procedure: 3 Guests of size 5GB is launched on a single NUMA node with
> >> total memory of 15GB and no swap. In each of the guest, memhog is run
> >> with 5GB. Post-execution of memhog, Host memory usage is monitored by
> >> using Free command.
> >>
> >> Without Hinting:
> >>                  Time of execution    Host used memory
> >> Guest 1:        45 seconds            5.4 GB
> >> Guest 2:        45 seconds            10 GB
> >> Guest 3:        1  minute               15 GB
> >>
> >> With Hinting:
> >>                 Time of execution     Host used memory
> >> Guest 1:        49 seconds            2.4 GB
> >> Guest 2:        40 seconds            4.3 GB
> >> Guest 3:        50 seconds            6.3 GB
> > OK so no improvement. OTOH Alex's patches cut time down to 5-7 seconds
> > which seems better. Want to try testing Alex's patches for comparison?
> >
> I realized that the last time I reported the memhog numbers, I didn't
> enable the swap due to which the actual benefits of the series were not
> shown.
> I have re-run the test by including some of the changes suggested by
> Alexander and David:
>     * Reduced the size of the per-cpu array to 32 and minimum hinting
> threshold to 16.
>     * Reported length of isolated pages along with start pfn, instead of
> the order from the guest.
>     * Used the reported length to madvise the entire length of address
> instead of a single 4K page.
>     * Replaced MADV_DONTNEED with MADV_FREE.
>
> Setup for the test:
> NUMA node:1
> Memory: 15GB
> Swap: 4GB
> Guest memory: 6GB
> Number of core: 1
>
> Process: A guest is launched and memhog is run with 6GB. As its
> execution is over next guest is launched. Everytime memhog execution
> time is monitored.
> Results:
>     Without Hinting:
>                  Time of execution
>     Guest1:    22s
>     Guest2:    24s
>     Guest3: 1m29s
>
>     With Hinting:
>                 Time of execution
>     Guest1:    24s
>     Guest2:    25s
>     Guest3:    28s
>
> When hinting is enabled swap space is not used until memhog with 6GB is
> ran in 6th guest.

So one change you may want to make to your test setup would be to
launch the tests sequentially after all the guests all up, instead of
combining the test and guest bring-up. In addition you could run
through the guests more than once to determine a more-or-less steady
state in terms of the performance as you move between the guests after
they have hit the point of having to either swap or pull MADV_FREE
pages.

Re: [RFC][Patch v9 0/6] KVM: Guest Free Page Hinting

[Nitesh Narayan Lal]

[-- Attachment #1.1: Type: text/plain, Size: 8268 bytes --]

On 3/14/19 12:58 PM, Alexander Duyck wrote:
> On Thu, Mar 14, 2019 at 9:43 AM Nitesh Narayan Lal <nitesh@redhat.com> wrote:
>>
>> On 3/6/19 1:12 PM, Michael S. Tsirkin wrote:
>>> On Wed, Mar 06, 2019 at 01:07:50PM -0500, Nitesh Narayan Lal wrote:
>>>> On 3/6/19 11:09 AM, Michael S. Tsirkin wrote:
>>>>> On Wed, Mar 06, 2019 at 10:50:42AM -0500, Nitesh Narayan Lal wrote:
>>>>>> The following patch-set proposes an efficient mechanism for handing freed memory between the guest and the host. It enables the guests with no page cache to rapidly free and reclaims memory to and from the host respectively.
>>>>>>
>>>>>> Benefit:
>>>>>> With this patch-series, in our test-case, executed on a single system and single NUMA node with 15GB memory, we were able to successfully launch 5 guests(each with 5 GB memory) when page hinting was enabled and 3 without it. (Detailed explanation of the test procedure is provided at the bottom under Test - 1).
>>>>>>
>>>>>> Changelog in v9:
>>>>>>    * Guest free page hinting hook is now invoked after a page has been merged in the buddy.
>>>>>>         * Free pages only with order FREE_PAGE_HINTING_MIN_ORDER(currently defined as MAX_ORDER - 1) are captured.
>>>>>>    * Removed kthread which was earlier used to perform the scanning, isolation & reporting of free pages.
>>>>>>    * Pages, captured in the per cpu array are sorted based on the zone numbers. This is to avoid redundancy of acquiring zone locks.
>>>>>>         * Dynamically allocated space is used to hold the isolated guest free pages.
>>>>>>         * All the pages are reported asynchronously to the host via virtio driver.
>>>>>>         * Pages are returned back to the guest buddy free list only when the host response is received.
>>>>>>
>>>>>> Pending items:
>>>>>>         * Make sure that the guest free page hinting's current implementation doesn't break hugepages or device assigned guests.
>>>>>>    * Follow up on VIRTIO_BALLOON_F_PAGE_POISON's device side support. (It is currently missing)
>>>>>>         * Compare reporting free pages via vring with vhost.
>>>>>>         * Decide between MADV_DONTNEED and MADV_FREE.
>>>>>>    * Analyze overall performance impact due to guest free page hinting.
>>>>>>    * Come up with proper/traceable error-message/logs.
>>>>>>
>>>>>> Tests:
>>>>>> 1. Use-case - Number of guests we can launch
>>>>>>
>>>>>>    NUMA Nodes = 1 with 15 GB memory
>>>>>>    Guest Memory = 5 GB
>>>>>>    Number of cores in guest = 1
>>>>>>    Workload = test allocation program allocates 4GB memory, touches it via memset and exits.
>>>>>>    Procedure =
>>>>>>    The first guest is launched and once its console is up, the test allocation program is executed with 4 GB memory request (Due to this the guest occupies almost 4-5 GB of memory in the host in a system without page hinting). Once this program exits at that time another guest is launched in the host and the same process is followed. We continue launching the guests until a guest gets killed due to low memory condition in the host.
>>>>>>
>>>>>>    Results:
>>>>>>    Without hinting = 3
>>>>>>    With hinting = 5
>>>>>>
>>>>>> 2. Hackbench
>>>>>>    Guest Memory = 5 GB
>>>>>>    Number of cores = 4
>>>>>>    Number of tasks         Time with Hinting       Time without Hinting
>>>>>>    4000                    19.540                  17.818
>>>>>>
>>>>> How about memhog btw?
>>>>> Alex reported:
>>>>>
>>>>>     My testing up till now has consisted of setting up 4 8GB VMs on a system
>>>>>     with 32GB of memory and 4GB of swap. To stress the memory on the system I
>>>>>     would run "memhog 8G" sequentially on each of the guests and observe how
>>>>>     long it took to complete the run. The observed behavior is that on the
>>>>>     systems with these patches applied in both the guest and on the host I was
>>>>>     able to complete the test with a time of 5 to 7 seconds per guest. On a
>>>>>     system without these patches the time ranged from 7 to 49 seconds per
>>>>>     guest. I am assuming the variability is due to time being spent writing
>>>>>     pages out to disk in order to free up space for the guest.
>>>>>
>>>> Here are the results:
>>>>
>>>> Procedure: 3 Guests of size 5GB is launched on a single NUMA node with
>>>> total memory of 15GB and no swap. In each of the guest, memhog is run
>>>> with 5GB. Post-execution of memhog, Host memory usage is monitored by
>>>> using Free command.
>>>>
>>>> Without Hinting:
>>>>                  Time of execution    Host used memory
>>>> Guest 1:        45 seconds            5.4 GB
>>>> Guest 2:        45 seconds            10 GB
>>>> Guest 3:        1  minute               15 GB
>>>>
>>>> With Hinting:
>>>>                 Time of execution     Host used memory
>>>> Guest 1:        49 seconds            2.4 GB
>>>> Guest 2:        40 seconds            4.3 GB
>>>> Guest 3:        50 seconds            6.3 GB
>>> OK so no improvement. OTOH Alex's patches cut time down to 5-7 seconds
>>> which seems better. Want to try testing Alex's patches for comparison?
>>>
>> I realized that the last time I reported the memhog numbers, I didn't
>> enable the swap due to which the actual benefits of the series were not
>> shown.
>> I have re-run the test by including some of the changes suggested by
>> Alexander and David:
>>     * Reduced the size of the per-cpu array to 32 and minimum hinting
>> threshold to 16.
>>     * Reported length of isolated pages along with start pfn, instead of
>> the order from the guest.
>>     * Used the reported length to madvise the entire length of address
>> instead of a single 4K page.
>>     * Replaced MADV_DONTNEED with MADV_FREE.
>>
>> Setup for the test:
>> NUMA node:1
>> Memory: 15GB
>> Swap: 4GB
>> Guest memory: 6GB
>> Number of core: 1
>>
>> Process: A guest is launched and memhog is run with 6GB. As its
>> execution is over next guest is launched. Everytime memhog execution
>> time is monitored.
>> Results:
>>     Without Hinting:
>>                  Time of execution
>>     Guest1:    22s
>>     Guest2:    24s
>>     Guest3: 1m29s
>>
>>     With Hinting:
>>                 Time of execution
>>     Guest1:    24s
>>     Guest2:    25s
>>     Guest3:    28s
>>
>> When hinting is enabled swap space is not used until memhog with 6GB is
>> ran in 6th guest.
> So one change you may want to make to your test setup would be to
> launch the tests sequentially after all the guests all up, instead of
> combining the test and guest bring-up. In addition you could run
> through the guests more than once to determine a more-or-less steady
> state in terms of the performance as you move between the guests after
> they have hit the point of having to either swap or pull MADV_FREE
> pages.
I tried running memhog as you suggested, here are the results:
Setup for the test:
NUMA node:1
Memory: 15GB
Swap: 4GB
Guest memory: 6GB
Number of core: 1

Process: 3 guests are launched and memhog is run with 6GB. Results are
monitored after 1st-time execution of memhog. Memhog is launched
sequentially in each of the guests and time is observed after the
execution of all 3 memhog is over.

Results:
Without Hinting
    Time of Execution   
1.    6m48s                   
2.    6m9s               

With Hinting
Array size:16 Minimum Threshold:8
1.    2m57s           
2.    2m20s           

The memhog execution time in the case of hinting is still not that low
as we would have expected. This is due to the usage of swap space.
Although wrt to non-hinting when swap used space is around 3.5G, with
hinting it remains to around 1.1-1.5G.
I did try using a zone free page barrier which prevented hinting when
free pages of order HINTING_ORDER goes below 256. This further brings
down the swap usage to 100-150 MB. The tricky part of this approach is
to configure this barrier condition for different guests.

Array size:16 Minimum Threshold:8
1.    1m16s       
2.    1m41s

Note: Memhog time does seem to vary a little bit on every boot with or
without hinting.

-- 
Regards
Nitesh


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [RFC][Patch v9 0/6] KVM: Guest Free Page Hinting

[David Hildenbrand]

On 18.03.19 16:57, Nitesh Narayan Lal wrote:
> On 3/14/19 12:58 PM, Alexander Duyck wrote:
>> On Thu, Mar 14, 2019 at 9:43 AM Nitesh Narayan Lal <nitesh@redhat.com> wrote:
>>>
>>> On 3/6/19 1:12 PM, Michael S. Tsirkin wrote:
>>>> On Wed, Mar 06, 2019 at 01:07:50PM -0500, Nitesh Narayan Lal wrote:
>>>>> On 3/6/19 11:09 AM, Michael S. Tsirkin wrote:
>>>>>> On Wed, Mar 06, 2019 at 10:50:42AM -0500, Nitesh Narayan Lal wrote:
>>>>>>> The following patch-set proposes an efficient mechanism for handing freed memory between the guest and the host. It enables the guests with no page cache to rapidly free and reclaims memory to and from the host respectively.
>>>>>>>
>>>>>>> Benefit:
>>>>>>> With this patch-series, in our test-case, executed on a single system and single NUMA node with 15GB memory, we were able to successfully launch 5 guests(each with 5 GB memory) when page hinting was enabled and 3 without it. (Detailed explanation of the test procedure is provided at the bottom under Test - 1).
>>>>>>>
>>>>>>> Changelog in v9:
>>>>>>>    * Guest free page hinting hook is now invoked after a page has been merged in the buddy.
>>>>>>>         * Free pages only with order FREE_PAGE_HINTING_MIN_ORDER(currently defined as MAX_ORDER - 1) are captured.
>>>>>>>    * Removed kthread which was earlier used to perform the scanning, isolation & reporting of free pages.
>>>>>>>    * Pages, captured in the per cpu array are sorted based on the zone numbers. This is to avoid redundancy of acquiring zone locks.
>>>>>>>         * Dynamically allocated space is used to hold the isolated guest free pages.
>>>>>>>         * All the pages are reported asynchronously to the host via virtio driver.
>>>>>>>         * Pages are returned back to the guest buddy free list only when the host response is received.
>>>>>>>
>>>>>>> Pending items:
>>>>>>>         * Make sure that the guest free page hinting's current implementation doesn't break hugepages or device assigned guests.
>>>>>>>    * Follow up on VIRTIO_BALLOON_F_PAGE_POISON's device side support. (It is currently missing)
>>>>>>>         * Compare reporting free pages via vring with vhost.
>>>>>>>         * Decide between MADV_DONTNEED and MADV_FREE.
>>>>>>>    * Analyze overall performance impact due to guest free page hinting.
>>>>>>>    * Come up with proper/traceable error-message/logs.
>>>>>>>
>>>>>>> Tests:
>>>>>>> 1. Use-case - Number of guests we can launch
>>>>>>>
>>>>>>>    NUMA Nodes = 1 with 15 GB memory
>>>>>>>    Guest Memory = 5 GB
>>>>>>>    Number of cores in guest = 1
>>>>>>>    Workload = test allocation program allocates 4GB memory, touches it via memset and exits.
>>>>>>>    Procedure =
>>>>>>>    The first guest is launched and once its console is up, the test allocation program is executed with 4 GB memory request (Due to this the guest occupies almost 4-5 GB of memory in the host in a system without page hinting). Once this program exits at that time another guest is launched in the host and the same process is followed. We continue launching the guests until a guest gets killed due to low memory condition in the host.
>>>>>>>
>>>>>>>    Results:
>>>>>>>    Without hinting = 3
>>>>>>>    With hinting = 5
>>>>>>>
>>>>>>> 2. Hackbench
>>>>>>>    Guest Memory = 5 GB
>>>>>>>    Number of cores = 4
>>>>>>>    Number of tasks         Time with Hinting       Time without Hinting
>>>>>>>    4000                    19.540                  17.818
>>>>>>>
>>>>>> How about memhog btw?
>>>>>> Alex reported:
>>>>>>
>>>>>>     My testing up till now has consisted of setting up 4 8GB VMs on a system
>>>>>>     with 32GB of memory and 4GB of swap. To stress the memory on the system I
>>>>>>     would run "memhog 8G" sequentially on each of the guests and observe how
>>>>>>     long it took to complete the run. The observed behavior is that on the
>>>>>>     systems with these patches applied in both the guest and on the host I was
>>>>>>     able to complete the test with a time of 5 to 7 seconds per guest. On a
>>>>>>     system without these patches the time ranged from 7 to 49 seconds per
>>>>>>     guest. I am assuming the variability is due to time being spent writing
>>>>>>     pages out to disk in order to free up space for the guest.
>>>>>>
>>>>> Here are the results:
>>>>>
>>>>> Procedure: 3 Guests of size 5GB is launched on a single NUMA node with
>>>>> total memory of 15GB and no swap. In each of the guest, memhog is run
>>>>> with 5GB. Post-execution of memhog, Host memory usage is monitored by
>>>>> using Free command.
>>>>>
>>>>> Without Hinting:
>>>>>                  Time of execution    Host used memory
>>>>> Guest 1:        45 seconds            5.4 GB
>>>>> Guest 2:        45 seconds            10 GB
>>>>> Guest 3:        1  minute               15 GB
>>>>>
>>>>> With Hinting:
>>>>>                 Time of execution     Host used memory
>>>>> Guest 1:        49 seconds            2.4 GB
>>>>> Guest 2:        40 seconds            4.3 GB
>>>>> Guest 3:        50 seconds            6.3 GB
>>>> OK so no improvement. OTOH Alex's patches cut time down to 5-7 seconds
>>>> which seems better. Want to try testing Alex's patches for comparison?
>>>>
>>> I realized that the last time I reported the memhog numbers, I didn't
>>> enable the swap due to which the actual benefits of the series were not
>>> shown.
>>> I have re-run the test by including some of the changes suggested by
>>> Alexander and David:
>>>     * Reduced the size of the per-cpu array to 32 and minimum hinting
>>> threshold to 16.
>>>     * Reported length of isolated pages along with start pfn, instead of
>>> the order from the guest.
>>>     * Used the reported length to madvise the entire length of address
>>> instead of a single 4K page.
>>>     * Replaced MADV_DONTNEED with MADV_FREE.
>>>
>>> Setup for the test:
>>> NUMA node:1
>>> Memory: 15GB
>>> Swap: 4GB
>>> Guest memory: 6GB
>>> Number of core: 1
>>>
>>> Process: A guest is launched and memhog is run with 6GB. As its
>>> execution is over next guest is launched. Everytime memhog execution
>>> time is monitored.
>>> Results:
>>>     Without Hinting:
>>>                  Time of execution
>>>     Guest1:    22s
>>>     Guest2:    24s
>>>     Guest3: 1m29s
>>>
>>>     With Hinting:
>>>                 Time of execution
>>>     Guest1:    24s
>>>     Guest2:    25s
>>>     Guest3:    28s
>>>
>>> When hinting is enabled swap space is not used until memhog with 6GB is
>>> ran in 6th guest.
>> So one change you may want to make to your test setup would be to
>> launch the tests sequentially after all the guests all up, instead of
>> combining the test and guest bring-up. In addition you could run
>> through the guests more than once to determine a more-or-less steady
>> state in terms of the performance as you move between the guests after
>> they have hit the point of having to either swap or pull MADV_FREE
>> pages.
> I tried running memhog as you suggested, here are the results:
> Setup for the test:
> NUMA node:1
> Memory: 15GB
> Swap: 4GB
> Guest memory: 6GB
> Number of core: 1
> 
> Process: 3 guests are launched and memhog is run with 6GB. Results are
> monitored after 1st-time execution of memhog. Memhog is launched
> sequentially in each of the guests and time is observed after the
> execution of all 3 memhog is over.
> 
> Results:
> Without Hinting
>     Time of Execution   
> 1.    6m48s                   
> 2.    6m9s               
> 
> With Hinting
> Array size:16 Minimum Threshold:8
> 1.    2m57s           
> 2.    2m20s           
> 
> The memhog execution time in the case of hinting is still not that low
> as we would have expected. This is due to the usage of swap space.
> Although wrt to non-hinting when swap used space is around 3.5G, with
> hinting it remains to around 1.1-1.5G.
> I did try using a zone free page barrier which prevented hinting when
> free pages of order HINTING_ORDER goes below 256. This further brings
> down the swap usage to 100-150 MB. The tricky part of this approach is
> to configure this barrier condition for different guests.
> 
> Array size:16 Minimum Threshold:8
> 1.    1m16s       
> 2.    1m41s
> 
> Note: Memhog time does seem to vary a little bit on every boot with or
> without hinting.
> 

I don't quite understand yet why "hinting more pages" (no free page
barrier) should result in a higher swap usage in the hypervisor
(1.1-1.5GB vs. 100-150 MB). If we are "hinting more pages" I would have
guessed that runtime could get slower, but not that we need more swap.

One theory:

If you hint all MAX_ORDER - 1 pages, at one point it could be that all
"remaining" free pages are currently isolated to be hinted. As MM needs
more pages for a process, it will fallback to using "MAX_ORDER - 2"
pages and so on. These pages, when they are freed, you won't hint
anymore unless they get merged. But after all they won't get merged
because they can't be merged (otherwise they wouldn't be "MAX_ORDER - 2"
after all right from the beginning).

Try hinting a smaller granularity to see if this could actually be the case.

-- 

Thanks,

David / dhildenb

Re: [RFC][Patch v9 0/6] KVM: Guest Free Page Hinting

[Nitesh Narayan Lal]

[-- Attachment #1.1: Type: text/plain, Size: 10745 bytes --]

On 3/19/19 9:33 AM, David Hildenbrand wrote:
> On 18.03.19 16:57, Nitesh Narayan Lal wrote:
>> On 3/14/19 12:58 PM, Alexander Duyck wrote:
>>> On Thu, Mar 14, 2019 at 9:43 AM Nitesh Narayan Lal <nitesh@redhat.com> wrote:
>>>> On 3/6/19 1:12 PM, Michael S. Tsirkin wrote:
>>>>> On Wed, Mar 06, 2019 at 01:07:50PM -0500, Nitesh Narayan Lal wrote:
>>>>>> On 3/6/19 11:09 AM, Michael S. Tsirkin wrote:
>>>>>>> On Wed, Mar 06, 2019 at 10:50:42AM -0500, Nitesh Narayan Lal wrote:
>>>>>>>> The following patch-set proposes an efficient mechanism for handing freed memory between the guest and the host. It enables the guests with no page cache to rapidly free and reclaims memory to and from the host respectively.
>>>>>>>>
>>>>>>>> Benefit:
>>>>>>>> With this patch-series, in our test-case, executed on a single system and single NUMA node with 15GB memory, we were able to successfully launch 5 guests(each with 5 GB memory) when page hinting was enabled and 3 without it. (Detailed explanation of the test procedure is provided at the bottom under Test - 1).
>>>>>>>>
>>>>>>>> Changelog in v9:
>>>>>>>>    * Guest free page hinting hook is now invoked after a page has been merged in the buddy.
>>>>>>>>         * Free pages only with order FREE_PAGE_HINTING_MIN_ORDER(currently defined as MAX_ORDER - 1) are captured.
>>>>>>>>    * Removed kthread which was earlier used to perform the scanning, isolation & reporting of free pages.
>>>>>>>>    * Pages, captured in the per cpu array are sorted based on the zone numbers. This is to avoid redundancy of acquiring zone locks.
>>>>>>>>         * Dynamically allocated space is used to hold the isolated guest free pages.
>>>>>>>>         * All the pages are reported asynchronously to the host via virtio driver.
>>>>>>>>         * Pages are returned back to the guest buddy free list only when the host response is received.
>>>>>>>>
>>>>>>>> Pending items:
>>>>>>>>         * Make sure that the guest free page hinting's current implementation doesn't break hugepages or device assigned guests.
>>>>>>>>    * Follow up on VIRTIO_BALLOON_F_PAGE_POISON's device side support. (It is currently missing)
>>>>>>>>         * Compare reporting free pages via vring with vhost.
>>>>>>>>         * Decide between MADV_DONTNEED and MADV_FREE.
>>>>>>>>    * Analyze overall performance impact due to guest free page hinting.
>>>>>>>>    * Come up with proper/traceable error-message/logs.
>>>>>>>>
>>>>>>>> Tests:
>>>>>>>> 1. Use-case - Number of guests we can launch
>>>>>>>>
>>>>>>>>    NUMA Nodes = 1 with 15 GB memory
>>>>>>>>    Guest Memory = 5 GB
>>>>>>>>    Number of cores in guest = 1
>>>>>>>>    Workload = test allocation program allocates 4GB memory, touches it via memset and exits.
>>>>>>>>    Procedure =
>>>>>>>>    The first guest is launched and once its console is up, the test allocation program is executed with 4 GB memory request (Due to this the guest occupies almost 4-5 GB of memory in the host in a system without page hinting). Once this program exits at that time another guest is launched in the host and the same process is followed. We continue launching the guests until a guest gets killed due to low memory condition in the host.
>>>>>>>>
>>>>>>>>    Results:
>>>>>>>>    Without hinting = 3
>>>>>>>>    With hinting = 5
>>>>>>>>
>>>>>>>> 2. Hackbench
>>>>>>>>    Guest Memory = 5 GB
>>>>>>>>    Number of cores = 4
>>>>>>>>    Number of tasks         Time with Hinting       Time without Hinting
>>>>>>>>    4000                    19.540                  17.818
>>>>>>>>
>>>>>>> How about memhog btw?
>>>>>>> Alex reported:
>>>>>>>
>>>>>>>     My testing up till now has consisted of setting up 4 8GB VMs on a system
>>>>>>>     with 32GB of memory and 4GB of swap. To stress the memory on the system I
>>>>>>>     would run "memhog 8G" sequentially on each of the guests and observe how
>>>>>>>     long it took to complete the run. The observed behavior is that on the
>>>>>>>     systems with these patches applied in both the guest and on the host I was
>>>>>>>     able to complete the test with a time of 5 to 7 seconds per guest. On a
>>>>>>>     system without these patches the time ranged from 7 to 49 seconds per
>>>>>>>     guest. I am assuming the variability is due to time being spent writing
>>>>>>>     pages out to disk in order to free up space for the guest.
>>>>>>>
>>>>>> Here are the results:
>>>>>>
>>>>>> Procedure: 3 Guests of size 5GB is launched on a single NUMA node with
>>>>>> total memory of 15GB and no swap. In each of the guest, memhog is run
>>>>>> with 5GB. Post-execution of memhog, Host memory usage is monitored by
>>>>>> using Free command.
>>>>>>
>>>>>> Without Hinting:
>>>>>>                  Time of execution    Host used memory
>>>>>> Guest 1:        45 seconds            5.4 GB
>>>>>> Guest 2:        45 seconds            10 GB
>>>>>> Guest 3:        1  minute               15 GB
>>>>>>
>>>>>> With Hinting:
>>>>>>                 Time of execution     Host used memory
>>>>>> Guest 1:        49 seconds            2.4 GB
>>>>>> Guest 2:        40 seconds            4.3 GB
>>>>>> Guest 3:        50 seconds            6.3 GB
>>>>> OK so no improvement. OTOH Alex's patches cut time down to 5-7 seconds
>>>>> which seems better. Want to try testing Alex's patches for comparison?
>>>>>
>>>> I realized that the last time I reported the memhog numbers, I didn't
>>>> enable the swap due to which the actual benefits of the series were not
>>>> shown.
>>>> I have re-run the test by including some of the changes suggested by
>>>> Alexander and David:
>>>>     * Reduced the size of the per-cpu array to 32 and minimum hinting
>>>> threshold to 16.
>>>>     * Reported length of isolated pages along with start pfn, instead of
>>>> the order from the guest.
>>>>     * Used the reported length to madvise the entire length of address
>>>> instead of a single 4K page.
>>>>     * Replaced MADV_DONTNEED with MADV_FREE.
>>>>
>>>> Setup for the test:
>>>> NUMA node:1
>>>> Memory: 15GB
>>>> Swap: 4GB
>>>> Guest memory: 6GB
>>>> Number of core: 1
>>>>
>>>> Process: A guest is launched and memhog is run with 6GB. As its
>>>> execution is over next guest is launched. Everytime memhog execution
>>>> time is monitored.
>>>> Results:
>>>>     Without Hinting:
>>>>                  Time of execution
>>>>     Guest1:    22s
>>>>     Guest2:    24s
>>>>     Guest3: 1m29s
>>>>
>>>>     With Hinting:
>>>>                 Time of execution
>>>>     Guest1:    24s
>>>>     Guest2:    25s
>>>>     Guest3:    28s
>>>>
>>>> When hinting is enabled swap space is not used until memhog with 6GB is
>>>> ran in 6th guest.
>>> So one change you may want to make to your test setup would be to
>>> launch the tests sequentially after all the guests all up, instead of
>>> combining the test and guest bring-up. In addition you could run
>>> through the guests more than once to determine a more-or-less steady
>>> state in terms of the performance as you move between the guests after
>>> they have hit the point of having to either swap or pull MADV_FREE
>>> pages.
>> I tried running memhog as you suggested, here are the results:
>> Setup for the test:
>> NUMA node:1
>> Memory: 15GB
>> Swap: 4GB
>> Guest memory: 6GB
>> Number of core: 1
>>
>> Process: 3 guests are launched and memhog is run with 6GB. Results are
>> monitored after 1st-time execution of memhog. Memhog is launched
>> sequentially in each of the guests and time is observed after the
>> execution of all 3 memhog is over.
>>
>> Results:
>> Without Hinting
>>     Time of Execution   
>> 1.    6m48s                   
>> 2.    6m9s               
>>
>> With Hinting
>> Array size:16 Minimum Threshold:8
>> 1.    2m57s           
>> 2.    2m20s           
>>
>> The memhog execution time in the case of hinting is still not that low
>> as we would have expected. This is due to the usage of swap space.
>> Although wrt to non-hinting when swap used space is around 3.5G, with
>> hinting it remains to around 1.1-1.5G.
>> I did try using a zone free page barrier which prevented hinting when
>> free pages of order HINTING_ORDER goes below 256. This further brings
>> down the swap usage to 100-150 MB. The tricky part of this approach is
>> to configure this barrier condition for different guests.
>>
>> Array size:16 Minimum Threshold:8
>> 1.    1m16s       
>> 2.    1m41s
>>
>> Note: Memhog time does seem to vary a little bit on every boot with or
>> without hinting.
>>
> I don't quite understand yet why "hinting more pages" (no free page
> barrier) should result in a higher swap usage in the hypervisor
> (1.1-1.5GB vs. 100-150 MB). If we are "hinting more pages" I would have
> guessed that runtime could get slower, but not that we need more swap.
>
> One theory:
>
> If you hint all MAX_ORDER - 1 pages, at one point it could be that all
> "remaining" free pages are currently isolated to be hinted. As MM needs
> more pages for a process, it will fallback to using "MAX_ORDER - 2"
> pages and so on. These pages, when they are freed, you won't hint
> anymore unless they get merged. But after all they won't get merged
> because they can't be merged (otherwise they wouldn't be "MAX_ORDER - 2"
> after all right from the beginning).
>
> Try hinting a smaller granularity to see if this could actually be the case.
So I have two questions in my mind after looking at the results now:
1. Why swap is coming into the picture when hinting is enabled?
2. Same to what you have raised.
For the 1st question, I think the answer is: (correct me if I am wrong.)
Memhog while writing the memory does free memory but the pages it frees
are of a lower order which doesn't merge until the memhog write
completes. After which we do get the MAX_ORDER - 1 page from the buddy
resulting in hinting.
As all 3 memhog are running parallelly we don't get free memory until
one of them completes.
This does explain that when 3 guests each of 6GB on a 15GB host tries to
run memhog with 6GB parallelly, swap comes into the picture even if
hinting is enabled.

This doesn't explain why putting a barrier or avoid hinting reduced the
swap usage. It seems I possibly had a wrong impression of the delaying
hinting idea which we discussed.
As I was observing the value of the swap at the end of the memhog
execution which is logically incorrect. I will re-run the test and
observe the highest swap usage during the entire execution of memhog for
hinting vs non-hinting.

-- 
Regards
Nitesh


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [RFC][Patch v9 0/6] KVM: Guest Free Page Hinting

[Alexander Duyck]

On Tue, Mar 19, 2019 at 9:04 AM Nitesh Narayan Lal <nitesh@redhat.com> wrote:
>
> On 3/19/19 9:33 AM, David Hildenbrand wrote:
> > On 18.03.19 16:57, Nitesh Narayan Lal wrote:
> >> On 3/14/19 12:58 PM, Alexander Duyck wrote:
> >>> On Thu, Mar 14, 2019 at 9:43 AM Nitesh Narayan Lal <nitesh@redhat.com> wrote:
> >>>> On 3/6/19 1:12 PM, Michael S. Tsirkin wrote:
> >>>>> On Wed, Mar 06, 2019 at 01:07:50PM -0500, Nitesh Narayan Lal wrote:
> >>>>>> On 3/6/19 11:09 AM, Michael S. Tsirkin wrote:
> >>>>>>> On Wed, Mar 06, 2019 at 10:50:42AM -0500, Nitesh Narayan Lal wrote:
> >>>>>>>> The following patch-set proposes an efficient mechanism for handing freed memory between the guest and the host. It enables the guests with no page cache to rapidly free and reclaims memory to and from the host respectively.
> >>>>>>>>
> >>>>>>>> Benefit:
> >>>>>>>> With this patch-series, in our test-case, executed on a single system and single NUMA node with 15GB memory, we were able to successfully launch 5 guests(each with 5 GB memory) when page hinting was enabled and 3 without it. (Detailed explanation of the test procedure is provided at the bottom under Test - 1).
> >>>>>>>>
> >>>>>>>> Changelog in v9:
> >>>>>>>>    * Guest free page hinting hook is now invoked after a page has been merged in the buddy.
> >>>>>>>>         * Free pages only with order FREE_PAGE_HINTING_MIN_ORDER(currently defined as MAX_ORDER - 1) are captured.
> >>>>>>>>    * Removed kthread which was earlier used to perform the scanning, isolation & reporting of free pages.
> >>>>>>>>    * Pages, captured in the per cpu array are sorted based on the zone numbers. This is to avoid redundancy of acquiring zone locks.
> >>>>>>>>         * Dynamically allocated space is used to hold the isolated guest free pages.
> >>>>>>>>         * All the pages are reported asynchronously to the host via virtio driver.
> >>>>>>>>         * Pages are returned back to the guest buddy free list only when the host response is received.
> >>>>>>>>
> >>>>>>>> Pending items:
> >>>>>>>>         * Make sure that the guest free page hinting's current implementation doesn't break hugepages or device assigned guests.
> >>>>>>>>    * Follow up on VIRTIO_BALLOON_F_PAGE_POISON's device side support. (It is currently missing)
> >>>>>>>>         * Compare reporting free pages via vring with vhost.
> >>>>>>>>         * Decide between MADV_DONTNEED and MADV_FREE.
> >>>>>>>>    * Analyze overall performance impact due to guest free page hinting.
> >>>>>>>>    * Come up with proper/traceable error-message/logs.
> >>>>>>>>
> >>>>>>>> Tests:
> >>>>>>>> 1. Use-case - Number of guests we can launch
> >>>>>>>>
> >>>>>>>>    NUMA Nodes = 1 with 15 GB memory
> >>>>>>>>    Guest Memory = 5 GB
> >>>>>>>>    Number of cores in guest = 1
> >>>>>>>>    Workload = test allocation program allocates 4GB memory, touches it via memset and exits.
> >>>>>>>>    Procedure =
> >>>>>>>>    The first guest is launched and once its console is up, the test allocation program is executed with 4 GB memory request (Due to this the guest occupies almost 4-5 GB of memory in the host in a system without page hinting). Once this program exits at that time another guest is launched in the host and the same process is followed. We continue launching the guests until a guest gets killed due to low memory condition in the host.
> >>>>>>>>
> >>>>>>>>    Results:
> >>>>>>>>    Without hinting = 3
> >>>>>>>>    With hinting = 5
> >>>>>>>>
> >>>>>>>> 2. Hackbench
> >>>>>>>>    Guest Memory = 5 GB
> >>>>>>>>    Number of cores = 4
> >>>>>>>>    Number of tasks         Time with Hinting       Time without Hinting
> >>>>>>>>    4000                    19.540                  17.818
> >>>>>>>>
> >>>>>>> How about memhog btw?
> >>>>>>> Alex reported:
> >>>>>>>
> >>>>>>>     My testing up till now has consisted of setting up 4 8GB VMs on a system
> >>>>>>>     with 32GB of memory and 4GB of swap. To stress the memory on the system I
> >>>>>>>     would run "memhog 8G" sequentially on each of the guests and observe how
> >>>>>>>     long it took to complete the run. The observed behavior is that on the
> >>>>>>>     systems with these patches applied in both the guest and on the host I was
> >>>>>>>     able to complete the test with a time of 5 to 7 seconds per guest. On a
> >>>>>>>     system without these patches the time ranged from 7 to 49 seconds per
> >>>>>>>     guest. I am assuming the variability is due to time being spent writing
> >>>>>>>     pages out to disk in order to free up space for the guest.
> >>>>>>>
> >>>>>> Here are the results:
> >>>>>>
> >>>>>> Procedure: 3 Guests of size 5GB is launched on a single NUMA node with
> >>>>>> total memory of 15GB and no swap. In each of the guest, memhog is run
> >>>>>> with 5GB. Post-execution of memhog, Host memory usage is monitored by
> >>>>>> using Free command.
> >>>>>>
> >>>>>> Without Hinting:
> >>>>>>                  Time of execution    Host used memory
> >>>>>> Guest 1:        45 seconds            5.4 GB
> >>>>>> Guest 2:        45 seconds            10 GB
> >>>>>> Guest 3:        1  minute               15 GB
> >>>>>>
> >>>>>> With Hinting:
> >>>>>>                 Time of execution     Host used memory
> >>>>>> Guest 1:        49 seconds            2.4 GB
> >>>>>> Guest 2:        40 seconds            4.3 GB
> >>>>>> Guest 3:        50 seconds            6.3 GB
> >>>>> OK so no improvement. OTOH Alex's patches cut time down to 5-7 seconds
> >>>>> which seems better. Want to try testing Alex's patches for comparison?
> >>>>>
> >>>> I realized that the last time I reported the memhog numbers, I didn't
> >>>> enable the swap due to which the actual benefits of the series were not
> >>>> shown.
> >>>> I have re-run the test by including some of the changes suggested by
> >>>> Alexander and David:
> >>>>     * Reduced the size of the per-cpu array to 32 and minimum hinting
> >>>> threshold to 16.
> >>>>     * Reported length of isolated pages along with start pfn, instead of
> >>>> the order from the guest.
> >>>>     * Used the reported length to madvise the entire length of address
> >>>> instead of a single 4K page.
> >>>>     * Replaced MADV_DONTNEED with MADV_FREE.
> >>>>
> >>>> Setup for the test:
> >>>> NUMA node:1
> >>>> Memory: 15GB
> >>>> Swap: 4GB
> >>>> Guest memory: 6GB
> >>>> Number of core: 1
> >>>>
> >>>> Process: A guest is launched and memhog is run with 6GB. As its
> >>>> execution is over next guest is launched. Everytime memhog execution
> >>>> time is monitored.
> >>>> Results:
> >>>>     Without Hinting:
> >>>>                  Time of execution
> >>>>     Guest1:    22s
> >>>>     Guest2:    24s
> >>>>     Guest3: 1m29s
> >>>>
> >>>>     With Hinting:
> >>>>                 Time of execution
> >>>>     Guest1:    24s
> >>>>     Guest2:    25s
> >>>>     Guest3:    28s
> >>>>
> >>>> When hinting is enabled swap space is not used until memhog with 6GB is
> >>>> ran in 6th guest.
> >>> So one change you may want to make to your test setup would be to
> >>> launch the tests sequentially after all the guests all up, instead of
> >>> combining the test and guest bring-up. In addition you could run
> >>> through the guests more than once to determine a more-or-less steady
> >>> state in terms of the performance as you move between the guests after
> >>> they have hit the point of having to either swap or pull MADV_FREE
> >>> pages.
> >> I tried running memhog as you suggested, here are the results:
> >> Setup for the test:
> >> NUMA node:1
> >> Memory: 15GB
> >> Swap: 4GB
> >> Guest memory: 6GB
> >> Number of core: 1
> >>
> >> Process: 3 guests are launched and memhog is run with 6GB. Results are
> >> monitored after 1st-time execution of memhog. Memhog is launched
> >> sequentially in each of the guests and time is observed after the
> >> execution of all 3 memhog is over.
> >>
> >> Results:
> >> Without Hinting
> >>     Time of Execution
> >> 1.    6m48s
> >> 2.    6m9s
> >>
> >> With Hinting
> >> Array size:16 Minimum Threshold:8
> >> 1.    2m57s
> >> 2.    2m20s
> >>
> >> The memhog execution time in the case of hinting is still not that low
> >> as we would have expected. This is due to the usage of swap space.
> >> Although wrt to non-hinting when swap used space is around 3.5G, with
> >> hinting it remains to around 1.1-1.5G.
> >> I did try using a zone free page barrier which prevented hinting when
> >> free pages of order HINTING_ORDER goes below 256. This further brings
> >> down the swap usage to 100-150 MB. The tricky part of this approach is
> >> to configure this barrier condition for different guests.
> >>
> >> Array size:16 Minimum Threshold:8
> >> 1.    1m16s
> >> 2.    1m41s
> >>
> >> Note: Memhog time does seem to vary a little bit on every boot with or
> >> without hinting.
> >>
> > I don't quite understand yet why "hinting more pages" (no free page
> > barrier) should result in a higher swap usage in the hypervisor
> > (1.1-1.5GB vs. 100-150 MB). If we are "hinting more pages" I would have
> > guessed that runtime could get slower, but not that we need more swap.
> >
> > One theory:
> >
> > If you hint all MAX_ORDER - 1 pages, at one point it could be that all
> > "remaining" free pages are currently isolated to be hinted. As MM needs
> > more pages for a process, it will fallback to using "MAX_ORDER - 2"
> > pages and so on. These pages, when they are freed, you won't hint
> > anymore unless they get merged. But after all they won't get merged
> > because they can't be merged (otherwise they wouldn't be "MAX_ORDER - 2"
> > after all right from the beginning).
> >
> > Try hinting a smaller granularity to see if this could actually be the case.
> So I have two questions in my mind after looking at the results now:
> 1. Why swap is coming into the picture when hinting is enabled?
> 2. Same to what you have raised.
> For the 1st question, I think the answer is: (correct me if I am wrong.)
> Memhog while writing the memory does free memory but the pages it frees
> are of a lower order which doesn't merge until the memhog write
> completes. After which we do get the MAX_ORDER - 1 page from the buddy
> resulting in hinting.
> As all 3 memhog are running parallelly we don't get free memory until
> one of them completes.
> This does explain that when 3 guests each of 6GB on a 15GB host tries to
> run memhog with 6GB parallelly, swap comes into the picture even if
> hinting is enabled.

Are you running them in parallel or sequentially? I had suggested
running them serially so that the previous one could complete and free
the memory before the next one allocated memory. In that setup you
should see the guests still swapping without hints, but with hints the
guest should free the memory up before the next one starts using it.
If you are running them in parallel then you are going to see things
going to swap because memhog does like what the name implies and it
will use all of the memory you give it. It isn't until it completes
that the memory is freed.

> This doesn't explain why putting a barrier or avoid hinting reduced the
> swap usage. It seems I possibly had a wrong impression of the delaying
> hinting idea which we discussed.
> As I was observing the value of the swap at the end of the memhog
> execution which is logically incorrect. I will re-run the test and
> observe the highest swap usage during the entire execution of memhog for
> hinting vs non-hinting.

So one option you may look at if you are wanting to run the tests in
parallel would be to limit the number of tests you have running at the
same time. If you have 15G of memory and 6G per guest you should be
able to run 2 sessions at a time without going to swap, however if you
run all 3 then you are likely going to be going to swap even with
hinting.

- Alex

Re: [RFC][Patch v9 0/6] KVM: Guest Free Page Hinting

[Nitesh Narayan Lal]

[-- Attachment #1.1: Type: text/plain, Size: 12337 bytes --]

On 3/19/19 1:38 PM, Alexander Duyck wrote:
> On Tue, Mar 19, 2019 at 9:04 AM Nitesh Narayan Lal <nitesh@redhat.com> wrote:
>> On 3/19/19 9:33 AM, David Hildenbrand wrote:
>>> On 18.03.19 16:57, Nitesh Narayan Lal wrote:
>>>> On 3/14/19 12:58 PM, Alexander Duyck wrote:
>>>>> On Thu, Mar 14, 2019 at 9:43 AM Nitesh Narayan Lal <nitesh@redhat.com> wrote:
>>>>>> On 3/6/19 1:12 PM, Michael S. Tsirkin wrote:
>>>>>>> On Wed, Mar 06, 2019 at 01:07:50PM -0500, Nitesh Narayan Lal wrote:
>>>>>>>> On 3/6/19 11:09 AM, Michael S. Tsirkin wrote:
>>>>>>>>> On Wed, Mar 06, 2019 at 10:50:42AM -0500, Nitesh Narayan Lal wrote:
>>>>>>>>>> The following patch-set proposes an efficient mechanism for handing freed memory between the guest and the host. It enables the guests with no page cache to rapidly free and reclaims memory to and from the host respectively.
>>>>>>>>>>
>>>>>>>>>> Benefit:
>>>>>>>>>> With this patch-series, in our test-case, executed on a single system and single NUMA node with 15GB memory, we were able to successfully launch 5 guests(each with 5 GB memory) when page hinting was enabled and 3 without it. (Detailed explanation of the test procedure is provided at the bottom under Test - 1).
>>>>>>>>>>
>>>>>>>>>> Changelog in v9:
>>>>>>>>>>    * Guest free page hinting hook is now invoked after a page has been merged in the buddy.
>>>>>>>>>>         * Free pages only with order FREE_PAGE_HINTING_MIN_ORDER(currently defined as MAX_ORDER - 1) are captured.
>>>>>>>>>>    * Removed kthread which was earlier used to perform the scanning, isolation & reporting of free pages.
>>>>>>>>>>    * Pages, captured in the per cpu array are sorted based on the zone numbers. This is to avoid redundancy of acquiring zone locks.
>>>>>>>>>>         * Dynamically allocated space is used to hold the isolated guest free pages.
>>>>>>>>>>         * All the pages are reported asynchronously to the host via virtio driver.
>>>>>>>>>>         * Pages are returned back to the guest buddy free list only when the host response is received.
>>>>>>>>>>
>>>>>>>>>> Pending items:
>>>>>>>>>>         * Make sure that the guest free page hinting's current implementation doesn't break hugepages or device assigned guests.
>>>>>>>>>>    * Follow up on VIRTIO_BALLOON_F_PAGE_POISON's device side support. (It is currently missing)
>>>>>>>>>>         * Compare reporting free pages via vring with vhost.
>>>>>>>>>>         * Decide between MADV_DONTNEED and MADV_FREE.
>>>>>>>>>>    * Analyze overall performance impact due to guest free page hinting.
>>>>>>>>>>    * Come up with proper/traceable error-message/logs.
>>>>>>>>>>
>>>>>>>>>> Tests:
>>>>>>>>>> 1. Use-case - Number of guests we can launch
>>>>>>>>>>
>>>>>>>>>>    NUMA Nodes = 1 with 15 GB memory
>>>>>>>>>>    Guest Memory = 5 GB
>>>>>>>>>>    Number of cores in guest = 1
>>>>>>>>>>    Workload = test allocation program allocates 4GB memory, touches it via memset and exits.
>>>>>>>>>>    Procedure =
>>>>>>>>>>    The first guest is launched and once its console is up, the test allocation program is executed with 4 GB memory request (Due to this the guest occupies almost 4-5 GB of memory in the host in a system without page hinting). Once this program exits at that time another guest is launched in the host and the same process is followed. We continue launching the guests until a guest gets killed due to low memory condition in the host.
>>>>>>>>>>
>>>>>>>>>>    Results:
>>>>>>>>>>    Without hinting = 3
>>>>>>>>>>    With hinting = 5
>>>>>>>>>>
>>>>>>>>>> 2. Hackbench
>>>>>>>>>>    Guest Memory = 5 GB
>>>>>>>>>>    Number of cores = 4
>>>>>>>>>>    Number of tasks         Time with Hinting       Time without Hinting
>>>>>>>>>>    4000                    19.540                  17.818
>>>>>>>>>>
>>>>>>>>> How about memhog btw?
>>>>>>>>> Alex reported:
>>>>>>>>>
>>>>>>>>>     My testing up till now has consisted of setting up 4 8GB VMs on a system
>>>>>>>>>     with 32GB of memory and 4GB of swap. To stress the memory on the system I
>>>>>>>>>     would run "memhog 8G" sequentially on each of the guests and observe how
>>>>>>>>>     long it took to complete the run. The observed behavior is that on the
>>>>>>>>>     systems with these patches applied in both the guest and on the host I was
>>>>>>>>>     able to complete the test with a time of 5 to 7 seconds per guest. On a
>>>>>>>>>     system without these patches the time ranged from 7 to 49 seconds per
>>>>>>>>>     guest. I am assuming the variability is due to time being spent writing
>>>>>>>>>     pages out to disk in order to free up space for the guest.
>>>>>>>>>
>>>>>>>> Here are the results:
>>>>>>>>
>>>>>>>> Procedure: 3 Guests of size 5GB is launched on a single NUMA node with
>>>>>>>> total memory of 15GB and no swap. In each of the guest, memhog is run
>>>>>>>> with 5GB. Post-execution of memhog, Host memory usage is monitored by
>>>>>>>> using Free command.
>>>>>>>>
>>>>>>>> Without Hinting:
>>>>>>>>                  Time of execution    Host used memory
>>>>>>>> Guest 1:        45 seconds            5.4 GB
>>>>>>>> Guest 2:        45 seconds            10 GB
>>>>>>>> Guest 3:        1  minute               15 GB
>>>>>>>>
>>>>>>>> With Hinting:
>>>>>>>>                 Time of execution     Host used memory
>>>>>>>> Guest 1:        49 seconds            2.4 GB
>>>>>>>> Guest 2:        40 seconds            4.3 GB
>>>>>>>> Guest 3:        50 seconds            6.3 GB
>>>>>>> OK so no improvement. OTOH Alex's patches cut time down to 5-7 seconds
>>>>>>> which seems better. Want to try testing Alex's patches for comparison?
>>>>>>>
>>>>>> I realized that the last time I reported the memhog numbers, I didn't
>>>>>> enable the swap due to which the actual benefits of the series were not
>>>>>> shown.
>>>>>> I have re-run the test by including some of the changes suggested by
>>>>>> Alexander and David:
>>>>>>     * Reduced the size of the per-cpu array to 32 and minimum hinting
>>>>>> threshold to 16.
>>>>>>     * Reported length of isolated pages along with start pfn, instead of
>>>>>> the order from the guest.
>>>>>>     * Used the reported length to madvise the entire length of address
>>>>>> instead of a single 4K page.
>>>>>>     * Replaced MADV_DONTNEED with MADV_FREE.
>>>>>>
>>>>>> Setup for the test:
>>>>>> NUMA node:1
>>>>>> Memory: 15GB
>>>>>> Swap: 4GB
>>>>>> Guest memory: 6GB
>>>>>> Number of core: 1
>>>>>>
>>>>>> Process: A guest is launched and memhog is run with 6GB. As its
>>>>>> execution is over next guest is launched. Everytime memhog execution
>>>>>> time is monitored.
>>>>>> Results:
>>>>>>     Without Hinting:
>>>>>>                  Time of execution
>>>>>>     Guest1:    22s
>>>>>>     Guest2:    24s
>>>>>>     Guest3: 1m29s
>>>>>>
>>>>>>     With Hinting:
>>>>>>                 Time of execution
>>>>>>     Guest1:    24s
>>>>>>     Guest2:    25s
>>>>>>     Guest3:    28s
>>>>>>
>>>>>> When hinting is enabled swap space is not used until memhog with 6GB is
>>>>>> ran in 6th guest.
>>>>> So one change you may want to make to your test setup would be to
>>>>> launch the tests sequentially after all the guests all up, instead of
>>>>> combining the test and guest bring-up. In addition you could run
>>>>> through the guests more than once to determine a more-or-less steady
>>>>> state in terms of the performance as you move between the guests after
>>>>> they have hit the point of having to either swap or pull MADV_FREE
>>>>> pages.
>>>> I tried running memhog as you suggested, here are the results:
>>>> Setup for the test:
>>>> NUMA node:1
>>>> Memory: 15GB
>>>> Swap: 4GB
>>>> Guest memory: 6GB
>>>> Number of core: 1
>>>>
>>>> Process: 3 guests are launched and memhog is run with 6GB. Results are
>>>> monitored after 1st-time execution of memhog. Memhog is launched
>>>> sequentially in each of the guests and time is observed after the
>>>> execution of all 3 memhog is over.
>>>>
>>>> Results:
>>>> Without Hinting
>>>>     Time of Execution
>>>> 1.    6m48s
>>>> 2.    6m9s
>>>>
>>>> With Hinting
>>>> Array size:16 Minimum Threshold:8
>>>> 1.    2m57s
>>>> 2.    2m20s
>>>>
>>>> The memhog execution time in the case of hinting is still not that low
>>>> as we would have expected. This is due to the usage of swap space.
>>>> Although wrt to non-hinting when swap used space is around 3.5G, with
>>>> hinting it remains to around 1.1-1.5G.
>>>> I did try using a zone free page barrier which prevented hinting when
>>>> free pages of order HINTING_ORDER goes below 256. This further brings
>>>> down the swap usage to 100-150 MB. The tricky part of this approach is
>>>> to configure this barrier condition for different guests.
>>>>
>>>> Array size:16 Minimum Threshold:8
>>>> 1.    1m16s
>>>> 2.    1m41s
>>>>
>>>> Note: Memhog time does seem to vary a little bit on every boot with or
>>>> without hinting.
>>>>
>>> I don't quite understand yet why "hinting more pages" (no free page
>>> barrier) should result in a higher swap usage in the hypervisor
>>> (1.1-1.5GB vs. 100-150 MB). If we are "hinting more pages" I would have
>>> guessed that runtime could get slower, but not that we need more swap.
>>>
>>> One theory:
>>>
>>> If you hint all MAX_ORDER - 1 pages, at one point it could be that all
>>> "remaining" free pages are currently isolated to be hinted. As MM needs
>>> more pages for a process, it will fallback to using "MAX_ORDER - 2"
>>> pages and so on. These pages, when they are freed, you won't hint
>>> anymore unless they get merged. But after all they won't get merged
>>> because they can't be merged (otherwise they wouldn't be "MAX_ORDER - 2"
>>> after all right from the beginning).
>>>
>>> Try hinting a smaller granularity to see if this could actually be the case.
>> So I have two questions in my mind after looking at the results now:
>> 1. Why swap is coming into the picture when hinting is enabled?
>> 2. Same to what you have raised.
>> For the 1st question, I think the answer is: (correct me if I am wrong.)
>> Memhog while writing the memory does free memory but the pages it frees
>> are of a lower order which doesn't merge until the memhog write
>> completes. After which we do get the MAX_ORDER - 1 page from the buddy
>> resulting in hinting.
>> As all 3 memhog are running parallelly we don't get free memory until
>> one of them completes.
>> This does explain that when 3 guests each of 6GB on a 15GB host tries to
>> run memhog with 6GB parallelly, swap comes into the picture even if
>> hinting is enabled.
> Are you running them in parallel or sequentially? 
I was running them parallelly but then I realized to see any benefits,
in that case, I should have run less number of guests.
> I had suggested
> running them serially so that the previous one could complete and free
> the memory before the next one allocated memory. In that setup you
> should see the guests still swapping without hints, but with hints the
> guest should free the memory up before the next one starts using it.
Yeah, I just realized this. Thanks for the clarification.
> If you are running them in parallel then you are going to see things
> going to swap because memhog does like what the name implies and it
> will use all of the memory you give it. It isn't until it completes
> that the memory is freed.
>
>> This doesn't explain why putting a barrier or avoid hinting reduced the
>> swap usage. It seems I possibly had a wrong impression of the delaying
>> hinting idea which we discussed.
>> As I was observing the value of the swap at the end of the memhog
>> execution which is logically incorrect. I will re-run the test and
>> observe the highest swap usage during the entire execution of memhog for
>> hinting vs non-hinting.
> So one option you may look at if you are wanting to run the tests in
> parallel would be to limit the number of tests you have running at the
> same time. If you have 15G of memory and 6G per guest you should be
> able to run 2 sessions at a time without going to swap, however if you
> run all 3 then you are likely going to be going to swap even with
> hinting.
>
> - Alex
-- 
Regards
Nitesh


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [RFC][Patch v9 0/6] KVM: Guest Free Page Hinting

[Nitesh Narayan Lal]

[-- Attachment #1.1: Type: text/plain, Size: 13363 bytes --]

On 3/19/19 1:59 PM, Nitesh Narayan Lal wrote:
> On 3/19/19 1:38 PM, Alexander Duyck wrote:
>> On Tue, Mar 19, 2019 at 9:04 AM Nitesh Narayan Lal <nitesh@redhat.com> wrote:
>>> On 3/19/19 9:33 AM, David Hildenbrand wrote:
>>>> On 18.03.19 16:57, Nitesh Narayan Lal wrote:
>>>>> On 3/14/19 12:58 PM, Alexander Duyck wrote:
>>>>>> On Thu, Mar 14, 2019 at 9:43 AM Nitesh Narayan Lal <nitesh@redhat.com> wrote:
>>>>>>> On 3/6/19 1:12 PM, Michael S. Tsirkin wrote:
>>>>>>>> On Wed, Mar 06, 2019 at 01:07:50PM -0500, Nitesh Narayan Lal wrote:
>>>>>>>>> On 3/6/19 11:09 AM, Michael S. Tsirkin wrote:
>>>>>>>>>> On Wed, Mar 06, 2019 at 10:50:42AM -0500, Nitesh Narayan Lal wrote:
>>>>>>>>>>> The following patch-set proposes an efficient mechanism for handing freed memory between the guest and the host. It enables the guests with no page cache to rapidly free and reclaims memory to and from the host respectively.
>>>>>>>>>>>
>>>>>>>>>>> Benefit:
>>>>>>>>>>> With this patch-series, in our test-case, executed on a single system and single NUMA node with 15GB memory, we were able to successfully launch 5 guests(each with 5 GB memory) when page hinting was enabled and 3 without it. (Detailed explanation of the test procedure is provided at the bottom under Test - 1).
>>>>>>>>>>>
>>>>>>>>>>> Changelog in v9:
>>>>>>>>>>>    * Guest free page hinting hook is now invoked after a page has been merged in the buddy.
>>>>>>>>>>>         * Free pages only with order FREE_PAGE_HINTING_MIN_ORDER(currently defined as MAX_ORDER - 1) are captured.
>>>>>>>>>>>    * Removed kthread which was earlier used to perform the scanning, isolation & reporting of free pages.
>>>>>>>>>>>    * Pages, captured in the per cpu array are sorted based on the zone numbers. This is to avoid redundancy of acquiring zone locks.
>>>>>>>>>>>         * Dynamically allocated space is used to hold the isolated guest free pages.
>>>>>>>>>>>         * All the pages are reported asynchronously to the host via virtio driver.
>>>>>>>>>>>         * Pages are returned back to the guest buddy free list only when the host response is received.
>>>>>>>>>>>
>>>>>>>>>>> Pending items:
>>>>>>>>>>>         * Make sure that the guest free page hinting's current implementation doesn't break hugepages or device assigned guests.
>>>>>>>>>>>    * Follow up on VIRTIO_BALLOON_F_PAGE_POISON's device side support. (It is currently missing)
>>>>>>>>>>>         * Compare reporting free pages via vring with vhost.
>>>>>>>>>>>         * Decide between MADV_DONTNEED and MADV_FREE.
>>>>>>>>>>>    * Analyze overall performance impact due to guest free page hinting.
>>>>>>>>>>>    * Come up with proper/traceable error-message/logs.
>>>>>>>>>>>
>>>>>>>>>>> Tests:
>>>>>>>>>>> 1. Use-case - Number of guests we can launch
>>>>>>>>>>>
>>>>>>>>>>>    NUMA Nodes = 1 with 15 GB memory
>>>>>>>>>>>    Guest Memory = 5 GB
>>>>>>>>>>>    Number of cores in guest = 1
>>>>>>>>>>>    Workload = test allocation program allocates 4GB memory, touches it via memset and exits.
>>>>>>>>>>>    Procedure =
>>>>>>>>>>>    The first guest is launched and once its console is up, the test allocation program is executed with 4 GB memory request (Due to this the guest occupies almost 4-5 GB of memory in the host in a system without page hinting). Once this program exits at that time another guest is launched in the host and the same process is followed. We continue launching the guests until a guest gets killed due to low memory condition in the host.
>>>>>>>>>>>
>>>>>>>>>>>    Results:
>>>>>>>>>>>    Without hinting = 3
>>>>>>>>>>>    With hinting = 5
>>>>>>>>>>>
>>>>>>>>>>> 2. Hackbench
>>>>>>>>>>>    Guest Memory = 5 GB
>>>>>>>>>>>    Number of cores = 4
>>>>>>>>>>>    Number of tasks         Time with Hinting       Time without Hinting
>>>>>>>>>>>    4000                    19.540                  17.818
>>>>>>>>>>>
>>>>>>>>>> How about memhog btw?
>>>>>>>>>> Alex reported:
>>>>>>>>>>
>>>>>>>>>>     My testing up till now has consisted of setting up 4 8GB VMs on a system
>>>>>>>>>>     with 32GB of memory and 4GB of swap. To stress the memory on the system I
>>>>>>>>>>     would run "memhog 8G" sequentially on each of the guests and observe how
>>>>>>>>>>     long it took to complete the run. The observed behavior is that on the
>>>>>>>>>>     systems with these patches applied in both the guest and on the host I was
>>>>>>>>>>     able to complete the test with a time of 5 to 7 seconds per guest. On a
>>>>>>>>>>     system without these patches the time ranged from 7 to 49 seconds per
>>>>>>>>>>     guest. I am assuming the variability is due to time being spent writing
>>>>>>>>>>     pages out to disk in order to free up space for the guest.
>>>>>>>>>>
>>>>>>>>> Here are the results:
>>>>>>>>>
>>>>>>>>> Procedure: 3 Guests of size 5GB is launched on a single NUMA node with
>>>>>>>>> total memory of 15GB and no swap. In each of the guest, memhog is run
>>>>>>>>> with 5GB. Post-execution of memhog, Host memory usage is monitored by
>>>>>>>>> using Free command.
>>>>>>>>>
>>>>>>>>> Without Hinting:
>>>>>>>>>                  Time of execution    Host used memory
>>>>>>>>> Guest 1:        45 seconds            5.4 GB
>>>>>>>>> Guest 2:        45 seconds            10 GB
>>>>>>>>> Guest 3:        1  minute               15 GB
>>>>>>>>>
>>>>>>>>> With Hinting:
>>>>>>>>>                 Time of execution     Host used memory
>>>>>>>>> Guest 1:        49 seconds            2.4 GB
>>>>>>>>> Guest 2:        40 seconds            4.3 GB
>>>>>>>>> Guest 3:        50 seconds            6.3 GB
>>>>>>>> OK so no improvement. OTOH Alex's patches cut time down to 5-7 seconds
>>>>>>>> which seems better. Want to try testing Alex's patches for comparison?
>>>>>>>>
>>>>>>> I realized that the last time I reported the memhog numbers, I didn't
>>>>>>> enable the swap due to which the actual benefits of the series were not
>>>>>>> shown.
>>>>>>> I have re-run the test by including some of the changes suggested by
>>>>>>> Alexander and David:
>>>>>>>     * Reduced the size of the per-cpu array to 32 and minimum hinting
>>>>>>> threshold to 16.
>>>>>>>     * Reported length of isolated pages along with start pfn, instead of
>>>>>>> the order from the guest.
>>>>>>>     * Used the reported length to madvise the entire length of address
>>>>>>> instead of a single 4K page.
>>>>>>>     * Replaced MADV_DONTNEED with MADV_FREE.
>>>>>>>
>>>>>>> Setup for the test:
>>>>>>> NUMA node:1
>>>>>>> Memory: 15GB
>>>>>>> Swap: 4GB
>>>>>>> Guest memory: 6GB
>>>>>>> Number of core: 1
>>>>>>>
>>>>>>> Process: A guest is launched and memhog is run with 6GB. As its
>>>>>>> execution is over next guest is launched. Everytime memhog execution
>>>>>>> time is monitored.
>>>>>>> Results:
>>>>>>>     Without Hinting:
>>>>>>>                  Time of execution
>>>>>>>     Guest1:    22s
>>>>>>>     Guest2:    24s
>>>>>>>     Guest3: 1m29s
>>>>>>>
>>>>>>>     With Hinting:
>>>>>>>                 Time of execution
>>>>>>>     Guest1:    24s
>>>>>>>     Guest2:    25s
>>>>>>>     Guest3:    28s
>>>>>>>
>>>>>>> When hinting is enabled swap space is not used until memhog with 6GB is
>>>>>>> ran in 6th guest.
>>>>>> So one change you may want to make to your test setup would be to
>>>>>> launch the tests sequentially after all the guests all up, instead of
>>>>>> combining the test and guest bring-up. In addition you could run
>>>>>> through the guests more than once to determine a more-or-less steady
>>>>>> state in terms of the performance as you move between the guests after
>>>>>> they have hit the point of having to either swap or pull MADV_FREE
>>>>>> pages.
>>>>> I tried running memhog as you suggested, here are the results:
>>>>> Setup for the test:
>>>>> NUMA node:1
>>>>> Memory: 15GB
>>>>> Swap: 4GB
>>>>> Guest memory: 6GB
>>>>> Number of core: 1
>>>>>
>>>>> Process: 3 guests are launched and memhog is run with 6GB. Results are
>>>>> monitored after 1st-time execution of memhog. Memhog is launched
>>>>> sequentially in each of the guests and time is observed after the
>>>>> execution of all 3 memhog is over.
>>>>>
>>>>> Results:
>>>>> Without Hinting
>>>>>     Time of Execution
>>>>> 1.    6m48s
>>>>> 2.    6m9s
>>>>>
>>>>> With Hinting
>>>>> Array size:16 Minimum Threshold:8
>>>>> 1.    2m57s
>>>>> 2.    2m20s
>>>>>
>>>>> The memhog execution time in the case of hinting is still not that low
>>>>> as we would have expected. This is due to the usage of swap space.
>>>>> Although wrt to non-hinting when swap used space is around 3.5G, with
>>>>> hinting it remains to around 1.1-1.5G.
>>>>> I did try using a zone free page barrier which prevented hinting when
>>>>> free pages of order HINTING_ORDER goes below 256. This further brings
>>>>> down the swap usage to 100-150 MB. The tricky part of this approach is
>>>>> to configure this barrier condition for different guests.
>>>>>
>>>>> Array size:16 Minimum Threshold:8
>>>>> 1.    1m16s
>>>>> 2.    1m41s
>>>>>
>>>>> Note: Memhog time does seem to vary a little bit on every boot with or
>>>>> without hinting.
>>>>>
>>>> I don't quite understand yet why "hinting more pages" (no free page
>>>> barrier) should result in a higher swap usage in the hypervisor
>>>> (1.1-1.5GB vs. 100-150 MB). If we are "hinting more pages" I would have
>>>> guessed that runtime could get slower, but not that we need more swap.
>>>>
>>>> One theory:
>>>>
>>>> If you hint all MAX_ORDER - 1 pages, at one point it could be that all
>>>> "remaining" free pages are currently isolated to be hinted. As MM needs
>>>> more pages for a process, it will fallback to using "MAX_ORDER - 2"
>>>> pages and so on. These pages, when they are freed, you won't hint
>>>> anymore unless they get merged. But after all they won't get merged
>>>> because they can't be merged (otherwise they wouldn't be "MAX_ORDER - 2"
>>>> after all right from the beginning).
>>>>
>>>> Try hinting a smaller granularity to see if this could actually be the case.
>>> So I have two questions in my mind after looking at the results now:
>>> 1. Why swap is coming into the picture when hinting is enabled?
>>> 2. Same to what you have raised.
>>> For the 1st question, I think the answer is: (correct me if I am wrong.)
>>> Memhog while writing the memory does free memory but the pages it frees
>>> are of a lower order which doesn't merge until the memhog write
>>> completes. After which we do get the MAX_ORDER - 1 page from the buddy
>>> resulting in hinting.
>>> As all 3 memhog are running parallelly we don't get free memory until
>>> one of them completes.
>>> This does explain that when 3 guests each of 6GB on a 15GB host tries to
>>> run memhog with 6GB parallelly, swap comes into the picture even if
>>> hinting is enabled.
>> Are you running them in parallel or sequentially? 
> I was running them parallelly but then I realized to see any benefits,
> in that case, I should have run less number of guests.
>> I had suggested
>> running them serially so that the previous one could complete and free
>> the memory before the next one allocated memory. In that setup you
>> should see the guests still swapping without hints, but with hints the
>> guest should free the memory up before the next one starts using it.
> Yeah, I just realized this. Thanks for the clarification.
>> If you are running them in parallel then you are going to see things
>> going to swap because memhog does like what the name implies and it
>> will use all of the memory you give it. It isn't until it completes
>> that the memory is freed.
>>
>>> This doesn't explain why putting a barrier or avoid hinting reduced the
>>> swap usage. It seems I possibly had a wrong impression of the delaying
>>> hinting idea which we discussed.
>>> As I was observing the value of the swap at the end of the memhog
>>> execution which is logically incorrect. I will re-run the test and
>>> observe the highest swap usage during the entire execution of memhog for
>>> hinting vs non-hinting.
>> So one option you may look at if you are wanting to run the tests in
>> parallel would be to limit the number of tests you have running at the
>> same time. If you have 15G of memory and 6G per guest you should be
>> able to run 2 sessions at a time without going to swap, however if you
>> run all 3 then you are likely going to be going to swap even with
>> hinting.
>>
>> - Alex
Here are the updated numbers excluding the guest bring-up cost:
Setup for the test-
NUMA node:1
Memory: 15GB
Swap: 4GB
Guest memory: 6GB
Number of core: 1
Process: 3 guests are launched and memhog is run serially with 6GB.
Results:
Without Hinting
                    Time of Execution   
Guest1:                56s                        
Guest2:                45s           
Guest3:                3m41s           

With Hinting
Guest1:                46s                        
Guest2:                45s           
Guest3:                49s           




-- 
Regards
Nitesh


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [RFC][Patch v9 0/6] KVM: Guest Free Page Hinting

[Nitesh Narayan Lal]

[-- Attachment #1.1: Type: text/plain, Size: 14358 bytes --]

On 3/20/19 9:18 AM, Nitesh Narayan Lal wrote:
> On 3/19/19 1:59 PM, Nitesh Narayan Lal wrote:
>> On 3/19/19 1:38 PM, Alexander Duyck wrote:
>>> On Tue, Mar 19, 2019 at 9:04 AM Nitesh Narayan Lal <nitesh@redhat.com> wrote:
>>>> On 3/19/19 9:33 AM, David Hildenbrand wrote:
>>>>> On 18.03.19 16:57, Nitesh Narayan Lal wrote:
>>>>>> On 3/14/19 12:58 PM, Alexander Duyck wrote:
>>>>>>> On Thu, Mar 14, 2019 at 9:43 AM Nitesh Narayan Lal <nitesh@redhat.com> wrote:
>>>>>>>> On 3/6/19 1:12 PM, Michael S. Tsirkin wrote:
>>>>>>>>> On Wed, Mar 06, 2019 at 01:07:50PM -0500, Nitesh Narayan Lal wrote:
>>>>>>>>>> On 3/6/19 11:09 AM, Michael S. Tsirkin wrote:
>>>>>>>>>>> On Wed, Mar 06, 2019 at 10:50:42AM -0500, Nitesh Narayan Lal wrote:
>>>>>>>>>>>> The following patch-set proposes an efficient mechanism for handing freed memory between the guest and the host. It enables the guests with no page cache to rapidly free and reclaims memory to and from the host respectively.
>>>>>>>>>>>>
>>>>>>>>>>>> Benefit:
>>>>>>>>>>>> With this patch-series, in our test-case, executed on a single system and single NUMA node with 15GB memory, we were able to successfully launch 5 guests(each with 5 GB memory) when page hinting was enabled and 3 without it. (Detailed explanation of the test procedure is provided at the bottom under Test - 1).
>>>>>>>>>>>>
>>>>>>>>>>>> Changelog in v9:
>>>>>>>>>>>>    * Guest free page hinting hook is now invoked after a page has been merged in the buddy.
>>>>>>>>>>>>         * Free pages only with order FREE_PAGE_HINTING_MIN_ORDER(currently defined as MAX_ORDER - 1) are captured.
>>>>>>>>>>>>    * Removed kthread which was earlier used to perform the scanning, isolation & reporting of free pages.
>>>>>>>>>>>>    * Pages, captured in the per cpu array are sorted based on the zone numbers. This is to avoid redundancy of acquiring zone locks.
>>>>>>>>>>>>         * Dynamically allocated space is used to hold the isolated guest free pages.
>>>>>>>>>>>>         * All the pages are reported asynchronously to the host via virtio driver.
>>>>>>>>>>>>         * Pages are returned back to the guest buddy free list only when the host response is received.
>>>>>>>>>>>>
>>>>>>>>>>>> Pending items:
>>>>>>>>>>>>         * Make sure that the guest free page hinting's current implementation doesn't break hugepages or device assigned guests.
>>>>>>>>>>>>    * Follow up on VIRTIO_BALLOON_F_PAGE_POISON's device side support. (It is currently missing)
>>>>>>>>>>>>         * Compare reporting free pages via vring with vhost.
>>>>>>>>>>>>         * Decide between MADV_DONTNEED and MADV_FREE.
>>>>>>>>>>>>    * Analyze overall performance impact due to guest free page hinting.
>>>>>>>>>>>>    * Come up with proper/traceable error-message/logs.
>>>>>>>>>>>>
>>>>>>>>>>>> Tests:
>>>>>>>>>>>> 1. Use-case - Number of guests we can launch
>>>>>>>>>>>>
>>>>>>>>>>>>    NUMA Nodes = 1 with 15 GB memory
>>>>>>>>>>>>    Guest Memory = 5 GB
>>>>>>>>>>>>    Number of cores in guest = 1
>>>>>>>>>>>>    Workload = test allocation program allocates 4GB memory, touches it via memset and exits.
>>>>>>>>>>>>    Procedure =
>>>>>>>>>>>>    The first guest is launched and once its console is up, the test allocation program is executed with 4 GB memory request (Due to this the guest occupies almost 4-5 GB of memory in the host in a system without page hinting). Once this program exits at that time another guest is launched in the host and the same process is followed. We continue launching the guests until a guest gets killed due to low memory condition in the host.
>>>>>>>>>>>>
>>>>>>>>>>>>    Results:
>>>>>>>>>>>>    Without hinting = 3
>>>>>>>>>>>>    With hinting = 5
>>>>>>>>>>>>
>>>>>>>>>>>> 2. Hackbench
>>>>>>>>>>>>    Guest Memory = 5 GB
>>>>>>>>>>>>    Number of cores = 4
>>>>>>>>>>>>    Number of tasks         Time with Hinting       Time without Hinting
>>>>>>>>>>>>    4000                    19.540                  17.818
>>>>>>>>>>>>
>>>>>>>>>>> How about memhog btw?
>>>>>>>>>>> Alex reported:
>>>>>>>>>>>
>>>>>>>>>>>     My testing up till now has consisted of setting up 4 8GB VMs on a system
>>>>>>>>>>>     with 32GB of memory and 4GB of swap. To stress the memory on the system I
>>>>>>>>>>>     would run "memhog 8G" sequentially on each of the guests and observe how
>>>>>>>>>>>     long it took to complete the run. The observed behavior is that on the
>>>>>>>>>>>     systems with these patches applied in both the guest and on the host I was
>>>>>>>>>>>     able to complete the test with a time of 5 to 7 seconds per guest. On a
>>>>>>>>>>>     system without these patches the time ranged from 7 to 49 seconds per
>>>>>>>>>>>     guest. I am assuming the variability is due to time being spent writing
>>>>>>>>>>>     pages out to disk in order to free up space for the guest.
>>>>>>>>>>>
>>>>>>>>>> Here are the results:
>>>>>>>>>>
>>>>>>>>>> Procedure: 3 Guests of size 5GB is launched on a single NUMA node with
>>>>>>>>>> total memory of 15GB and no swap. In each of the guest, memhog is run
>>>>>>>>>> with 5GB. Post-execution of memhog, Host memory usage is monitored by
>>>>>>>>>> using Free command.
>>>>>>>>>>
>>>>>>>>>> Without Hinting:
>>>>>>>>>>                  Time of execution    Host used memory
>>>>>>>>>> Guest 1:        45 seconds            5.4 GB
>>>>>>>>>> Guest 2:        45 seconds            10 GB
>>>>>>>>>> Guest 3:        1  minute               15 GB
>>>>>>>>>>
>>>>>>>>>> With Hinting:
>>>>>>>>>>                 Time of execution     Host used memory
>>>>>>>>>> Guest 1:        49 seconds            2.4 GB
>>>>>>>>>> Guest 2:        40 seconds            4.3 GB
>>>>>>>>>> Guest 3:        50 seconds            6.3 GB
>>>>>>>>> OK so no improvement. OTOH Alex's patches cut time down to 5-7 seconds
>>>>>>>>> which seems better. Want to try testing Alex's patches for comparison?
>>>>>>>>>
>>>>>>>> I realized that the last time I reported the memhog numbers, I didn't
>>>>>>>> enable the swap due to which the actual benefits of the series were not
>>>>>>>> shown.
>>>>>>>> I have re-run the test by including some of the changes suggested by
>>>>>>>> Alexander and David:
>>>>>>>>     * Reduced the size of the per-cpu array to 32 and minimum hinting
>>>>>>>> threshold to 16.
>>>>>>>>     * Reported length of isolated pages along with start pfn, instead of
>>>>>>>> the order from the guest.
>>>>>>>>     * Used the reported length to madvise the entire length of address
>>>>>>>> instead of a single 4K page.
>>>>>>>>     * Replaced MADV_DONTNEED with MADV_FREE.
>>>>>>>>
>>>>>>>> Setup for the test:
>>>>>>>> NUMA node:1
>>>>>>>> Memory: 15GB
>>>>>>>> Swap: 4GB
>>>>>>>> Guest memory: 6GB
>>>>>>>> Number of core: 1
>>>>>>>>
>>>>>>>> Process: A guest is launched and memhog is run with 6GB. As its
>>>>>>>> execution is over next guest is launched. Everytime memhog execution
>>>>>>>> time is monitored.
>>>>>>>> Results:
>>>>>>>>     Without Hinting:
>>>>>>>>                  Time of execution
>>>>>>>>     Guest1:    22s
>>>>>>>>     Guest2:    24s
>>>>>>>>     Guest3: 1m29s
>>>>>>>>
>>>>>>>>     With Hinting:
>>>>>>>>                 Time of execution
>>>>>>>>     Guest1:    24s
>>>>>>>>     Guest2:    25s
>>>>>>>>     Guest3:    28s
>>>>>>>>
>>>>>>>> When hinting is enabled swap space is not used until memhog with 6GB is
>>>>>>>> ran in 6th guest.
>>>>>>> So one change you may want to make to your test setup would be to
>>>>>>> launch the tests sequentially after all the guests all up, instead of
>>>>>>> combining the test and guest bring-up. In addition you could run
>>>>>>> through the guests more than once to determine a more-or-less steady
>>>>>>> state in terms of the performance as you move between the guests after
>>>>>>> they have hit the point of having to either swap or pull MADV_FREE
>>>>>>> pages.
>>>>>> I tried running memhog as you suggested, here are the results:
>>>>>> Setup for the test:
>>>>>> NUMA node:1
>>>>>> Memory: 15GB
>>>>>> Swap: 4GB
>>>>>> Guest memory: 6GB
>>>>>> Number of core: 1
>>>>>>
>>>>>> Process: 3 guests are launched and memhog is run with 6GB. Results are
>>>>>> monitored after 1st-time execution of memhog. Memhog is launched
>>>>>> sequentially in each of the guests and time is observed after the
>>>>>> execution of all 3 memhog is over.
>>>>>>
>>>>>> Results:
>>>>>> Without Hinting
>>>>>>     Time of Execution
>>>>>> 1.    6m48s
>>>>>> 2.    6m9s
>>>>>>
>>>>>> With Hinting
>>>>>> Array size:16 Minimum Threshold:8
>>>>>> 1.    2m57s
>>>>>> 2.    2m20s
>>>>>>
>>>>>> The memhog execution time in the case of hinting is still not that low
>>>>>> as we would have expected. This is due to the usage of swap space.
>>>>>> Although wrt to non-hinting when swap used space is around 3.5G, with
>>>>>> hinting it remains to around 1.1-1.5G.
>>>>>> I did try using a zone free page barrier which prevented hinting when
>>>>>> free pages of order HINTING_ORDER goes below 256. This further brings
>>>>>> down the swap usage to 100-150 MB. The tricky part of this approach is
>>>>>> to configure this barrier condition for different guests.
>>>>>>
>>>>>> Array size:16 Minimum Threshold:8
>>>>>> 1.    1m16s
>>>>>> 2.    1m41s
>>>>>>
>>>>>> Note: Memhog time does seem to vary a little bit on every boot with or
>>>>>> without hinting.
>>>>>>
>>>>> I don't quite understand yet why "hinting more pages" (no free page
>>>>> barrier) should result in a higher swap usage in the hypervisor
>>>>> (1.1-1.5GB vs. 100-150 MB). If we are "hinting more pages" I would have
>>>>> guessed that runtime could get slower, but not that we need more swap.
>>>>>
>>>>> One theory:
>>>>>
>>>>> If you hint all MAX_ORDER - 1 pages, at one point it could be that all
>>>>> "remaining" free pages are currently isolated to be hinted. As MM needs
>>>>> more pages for a process, it will fallback to using "MAX_ORDER - 2"
>>>>> pages and so on. These pages, when they are freed, you won't hint
>>>>> anymore unless they get merged. But after all they won't get merged
>>>>> because they can't be merged (otherwise they wouldn't be "MAX_ORDER - 2"
>>>>> after all right from the beginning).
>>>>>
>>>>> Try hinting a smaller granularity to see if this could actually be the case.
>>>> So I have two questions in my mind after looking at the results now:
>>>> 1. Why swap is coming into the picture when hinting is enabled?
>>>> 2. Same to what you have raised.
>>>> For the 1st question, I think the answer is: (correct me if I am wrong.)
>>>> Memhog while writing the memory does free memory but the pages it frees
>>>> are of a lower order which doesn't merge until the memhog write
>>>> completes. After which we do get the MAX_ORDER - 1 page from the buddy
>>>> resulting in hinting.
>>>> As all 3 memhog are running parallelly we don't get free memory until
>>>> one of them completes.
>>>> This does explain that when 3 guests each of 6GB on a 15GB host tries to
>>>> run memhog with 6GB parallelly, swap comes into the picture even if
>>>> hinting is enabled.
>>> Are you running them in parallel or sequentially? 
>> I was running them parallelly but then I realized to see any benefits,
>> in that case, I should have run less number of guests.
>>> I had suggested
>>> running them serially so that the previous one could complete and free
>>> the memory before the next one allocated memory. In that setup you
>>> should see the guests still swapping without hints, but with hints the
>>> guest should free the memory up before the next one starts using it.
>> Yeah, I just realized this. Thanks for the clarification.
>>> If you are running them in parallel then you are going to see things
>>> going to swap because memhog does like what the name implies and it
>>> will use all of the memory you give it. It isn't until it completes
>>> that the memory is freed.
>>>
>>>> This doesn't explain why putting a barrier or avoid hinting reduced the
>>>> swap usage. It seems I possibly had a wrong impression of the delaying
>>>> hinting idea which we discussed.
>>>> As I was observing the value of the swap at the end of the memhog
>>>> execution which is logically incorrect. I will re-run the test and
>>>> observe the highest swap usage during the entire execution of memhog for
>>>> hinting vs non-hinting.
>>> So one option you may look at if you are wanting to run the tests in
>>> parallel would be to limit the number of tests you have running at the
>>> same time. If you have 15G of memory and 6G per guest you should be
>>> able to run 2 sessions at a time without going to swap, however if you
>>> run all 3 then you are likely going to be going to swap even with
>>> hinting.
>>>
>>> - Alex
> Here are the updated numbers excluding the guest bring-up cost:
> Setup for the test-
> NUMA node:1
> Memory: 15GB
> Swap: 4GB
> Guest memory: 6GB
> Number of core: 1
> Process: 3 guests are launched and memhog is run serially with 6GB.
> Results:
> Without Hinting
>                     Time of Execution   
> Guest1:                56s                        
> Guest2:                45s           
> Guest3:                3m41s           
>
> With Hinting
> Guest1:                46s                        
> Guest2:                45s           
> Guest3:                49s           
>
>
>
>
I performed some experiments to see if the current implementation of
hinting breaks THP. I used AnonHugePages to track the THP pages
currently in use and memhog as the guest workload.
Setup:
Host Size: 30GB (No swap)
Guest Size: 15GB
THP Size: 2MB
Process: Guest is installed with different kernels to hint different
granularities(MAX_ORDER - 1, MAX_ORDER - 2 and MAX_ORDER - 3). Memhog 
15G is run multiple times in the same guest to see AnonHugePages usage
in the host.

Observation:
There is no THP split for order MAX_ORDER - 1 & MAX_ORDER - 2 whereas
for hinting granularity MAX_ORDER - 3 THP does split irrespective of
MADVISE_FREE or MADVISE_DONTNEED.
-- 
Regards
Nitesh


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [RFC][Patch v9 0/6] KVM: Guest Free Page Hinting

[Michael S. Tsirkin]

On Mon, Mar 25, 2019 at 10:27:46AM -0400, Nitesh Narayan Lal wrote:
> I performed some experiments to see if the current implementation of
> hinting breaks THP. I used AnonHugePages to track the THP pages
> currently in use and memhog as the guest workload.
> Setup:
> Host Size: 30GB (No swap)
> Guest Size: 15GB
> THP Size: 2MB
> Process: Guest is installed with different kernels to hint different
> granularities(MAX_ORDER - 1, MAX_ORDER - 2 and MAX_ORDER - 3). Memhog 
> 15G is run multiple times in the same guest to see AnonHugePages usage
> in the host.
> 
> Observation:
> There is no THP split for order MAX_ORDER - 1 & MAX_ORDER - 2 whereas
> for hinting granularity MAX_ORDER - 3 THP does split irrespective of
> MADVISE_FREE or MADVISE_DONTNEED.
> -- 
> Regards
> Nitesh
> 

This is on x86 right? So THP is 2M and MAX_ORDER is 8M.
MAX_ORDER - 3 ==> 1M.
Seems to work out.

-- 
MST

Re: [RFC][Patch v9 0/6] KVM: Guest Free Page Hinting

[Nitesh Narayan Lal]

[-- Attachment #1.1: Type: text/plain, Size: 1023 bytes --]

On 3/25/19 11:37 AM, Michael S. Tsirkin wrote:
> On Mon, Mar 25, 2019 at 10:27:46AM -0400, Nitesh Narayan Lal wrote:
>> I performed some experiments to see if the current implementation of
>> hinting breaks THP. I used AnonHugePages to track the THP pages
>> currently in use and memhog as the guest workload.
>> Setup:
>> Host Size: 30GB (No swap)
>> Guest Size: 15GB
>> THP Size: 2MB
>> Process: Guest is installed with different kernels to hint different
>> granularities(MAX_ORDER - 1, MAX_ORDER - 2 and MAX_ORDER - 3). Memhog 
>> 15G is run multiple times in the same guest to see AnonHugePages usage
>> in the host.
>>
>> Observation:
>> There is no THP split for order MAX_ORDER - 1 & MAX_ORDER - 2 whereas
>> for hinting granularity MAX_ORDER - 3 THP does split irrespective of
>> MADVISE_FREE or MADVISE_DONTNEED.
>> -- 
>> Regards
>> Nitesh
>>
> This is on x86 right?
Yes.
>  So THP is 2M and MAX_ORDER is 8M.
> MAX_ORDER - 3 ==> 1M.
> Seems to work out.
>
>
-- 
Regards
Nitesh


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]