kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH v9 0/8] stg mail -e --version=v9 \
@ 2019-09-07 17:25 Alexander Duyck
  2019-09-07 17:25 ` [PATCH v9 1/8] mm: Add per-cpu logic to page shuffling Alexander Duyck
                   ` (9 more replies)
  0 siblings, 10 replies; 82+ messages in thread
From: Alexander Duyck @ 2019-09-07 17:25 UTC (permalink / raw)
  To: virtio-dev, kvm, mst, catalin.marinas, david, dave.hansen,
	linux-kernel, willy, mhocko, linux-mm, akpm, will,
	linux-arm-kernel, osalvador
  Cc: yang.zhang.wz, pagupta, konrad.wilk, nitesh, riel, lcapitulino,
	wei.w.wang, aarcange, ying.huang, pbonzini, dan.j.williams,
	fengguang.wu, alexander.h.duyck, kirill.shutemov

--to=kvm@vger.kernel.org \
--to=linux-kernel@vger.kernel.org \
--to=linux-mm@kvack.org \
--to=virtio-dev@lists.oasis-open.org \
--to=linux-arm-kernel@lists.infradead.org \
--to=mst@redhat.com \
--to=david@redhat.com \
--to=dave.hansen@intel.com \
--to=akpm@linux-foundation.org \
--cc=nitesh@redhat.com \
--cc=dan.j.williams@intel.com \
--cc=pbonzini@redhat.com \
--cc=lcapitulino@redhat.com \
--cc=pagupta@redhat.com \
--cc=wei.w.wang@intel.com \
--cc=yang.zhang.wz@gmail.com \
--cc=riel@surriel.com \
--cc=konrad.wilk@oracle.com \
--cc=aarcange@redhat.com \
--to=willy@infradead.org \
--to=mhocko@kernel.org \
--to=osalvador@suse.de \
--to=catalin.marinas@arm.com \
--to=will@kernel.org \
--cc=kirill.shutemov@linux.intel.com  \
--cc=fengguang.wu@intel.com \
--cc=ying.huang@intel.com \
--cc=alexander.h.duyck@linux.intel.com \
01-mm-add-per-cpu-logic-to-page..08-virtio-balloon-add-support-for

mm / virtio: Provide support for unused page reporting

This series provides an asynchronous means of reporting to a hypervisor
that a guest page is no longer in use and can have the data associated
with it dropped. To do this I have implemented functionality that allows
for what I am referring to as unused page reporting

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

I am leaving a number of things hard-coded such as limiting the lowest
order processed to PAGEBLOCK_ORDER, and have left it up to the guest to
determine what the limit is on how many pages it wants to allocate to
process the hints. The upper limit for this is based on the size of the
queue used to store the scattergather list.

My primary testing has just been to verify the memory is being freed after
allocation by running memhog 40g on a 40g guest and watching the total
free memory via /proc/meminfo on the host. With this I have verified most
of the memory is freed after each iteration. As far as performance I have
been mainly focusing on the will-it-scale/page_fault1 test running with
16 vcpus. I have modified it to use Transparent Huge Pages. With this I
see almost no difference, -0.08%, with the patches applied and the feature
disabled. I see a regression of -0.86% with the feature enabled, but the
madvise disabled in the hypervisor due to a device being assigned. With
the feature fully enabled I see a regression of -3.27% versus the baseline
without these patches applied. In my testing I found that most of the
overhead was due to the page zeroing that comes as a result of the pages
having to be faulted back into the guest.

One side effect of these patches is that the guest becomes much more
resilient in terms of NUMA locality. With the pages being freed and then
reallocated when used it allows for the pages to be much closer to the
active thread, and as a result there can be situations where this patch
set will out-perform the stock kernel when the guest memory is not local
to the guest vCPUs. To avoid that in my testing I set the affinity of all
the vCPUs and QEMU instance to the same node.

I have not included the QEMU patches with this set as they haven't really
changed in the last several revisions. If needed they can be located with
the v8 patchset.

Changes from the RFC:
https://lore.kernel.org/lkml/20190530215223.13974.22445.stgit@localhost.localdomain/
Moved aeration requested flag out of aerator and into zone->flags.
Moved boundary out of free_area and into local variables for aeration.
Moved aeration cycle out of interrupt and into workqueue.
Left nr_free as total pages instead of splitting it between raw and aerated.
Combined size and physical address values in virtio ring into one 64b value.

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

Changes from v2:
https://lore.kernel.org/lkml/20190724165158.6685.87228.stgit@localhost.localdomain/
Dropped "page hinting" in favor of "page reporting"
Renamed files from "hinting" to "reporting"
Replaced "Hinted" page type with "Reported" page flag
Added support for page poisoning while hinting is active
Add QEMU patch that implements PAGE_POISON feature

Changes from v3:
https://lore.kernel.org/lkml/20190801222158.22190.96964.stgit@localhost.localdomain/
Added mutex lock around page reporting startup and shutdown
Fixed reference to "page aeration" in patch 2
Split page reporting function bit out into separate QEMU patch
Limited capacity of scatterlist to vq size - 1 instead of vq size
Added exception handling for case of virtio descriptor allocation failure

Changes from v4:
https://lore.kernel.org/lkml/20190807224037.6891.53512.stgit@localhost.localdomain/
Replaced spin_(un)lock with spin_(un)lock_irq in page_reporting_cycle()
Dropped if/continue for ternary operator in page_reporting_process()
Added checks for isolate and cma types to for_each_reporting_migratetype_order
Added virtio-dev, Michal Hocko, and Oscar Salvador to to:/cc:
Rebased on latest linux-next and QEMU git trees

Changes from v5:
https://lore.kernel.org/lkml/20190812213158.22097.30576.stgit@localhost.localdomain/
Replaced spin_(un)lock with spin_(un)lock_irq in page_reporting_startup()
Updated shuffle code to use "shuffle_pick_tail" and updated patch description
Dropped storage of order and migratettype while page is being reported
Used get_pfnblock_migratetype to determine migratetype of page
Renamed put_reported_page to free_reported_page, added order as argument
Dropped check for CMA type as I believe we should be reporting those
Added code to allow moving of reported pages into and out of isolation
Defined page reporting order as minimum of Huge Page size vs MAX_ORDER - 1
Cleaned up use of static branch usage for page_reporting_notify_enabled

Changes from v6:
https://lore.kernel.org/lkml/20190821145806.20926.22448.stgit@localhost.localdomain/
Rebased on linux-next for 20190903
Added jump label to __page_reporting_request so we release RCU read lock
Removed "- 1" from capacity limit based on virtio ring
Added code to verify capacity is non-zero or return error on startup

Changes from v7:
https://lore.kernel.org/lkml/20190904150920.13848.32271.stgit@localhost.localdomain/
Updated poison fixes to clear flag if "nosanity" is enabled in kernel config
Split shuffle per-cpu optimization into separate patch
Moved check for !phdev->capacity into reporting patch where it belongs
Added Reviewed-by tags received for v7

Changes from v8:
https://lore.kernel.org/lkml/20190906145213.32552.30160.stgit@localhost.localdomain/
Added patch that moves HPAGE_SIZE definition for ARM64 to match other archs
Switch back to using pageblock_order instead of HUGETLB_ORDER and MAX_ORDER - 1
Boundary allocation now dynamic to support HUGETLB_PAGE_SIZE_VARIABLE option
Made use of existing code/functions to reduce size of move_to_boundary function
Dropped unused zone pointer from add_to/del_from_boundary functions
Added additional possible mm and arm64 people as reviewers to Cc
Added Reviewed-by tags received for v8
Fixed missing parameter in kerneldoc

---

Alexander Duyck (8):
      mm: Add per-cpu logic to page shuffling
      mm: Adjust shuffle code to allow for future coalescing
      mm: Move set/get_pcppage_migratetype to mmzone.h
      mm: Use zone and order instead of free area in free_list manipulators
      arm64: Move hugetlb related definitions out of pgtable.h to page-defs.h
      mm: Introduce Reported pages
      virtio-balloon: Pull page poisoning config out of free page hinting
      virtio-balloon: Add support for providing unused page reports to host


 arch/arm64/include/asm/page-def.h   |    9 +
 arch/arm64/include/asm/pgtable.h    |    9 -
 drivers/virtio/Kconfig              |    1 
 drivers/virtio/virtio_balloon.c     |   87 ++++++++-
 include/linux/mmzone.h              |  124 ++++++++----
 include/linux/page-flags.h          |   11 +
 include/linux/page_reporting.h      |  178 +++++++++++++++++
 include/uapi/linux/virtio_balloon.h |    1 
 mm/Kconfig                          |    5 
 mm/Makefile                         |    1 
 mm/internal.h                       |   18 ++
 mm/memory_hotplug.c                 |    1 
 mm/page_alloc.c                     |  217 +++++++++++++++------
 mm/page_reporting.c                 |  358 +++++++++++++++++++++++++++++++++++
 mm/shuffle.c                        |   40 ++--
 mm/shuffle.h                        |   12 +
 16 files changed, 931 insertions(+), 141 deletions(-)
 create mode 100644 include/linux/page_reporting.h
 create mode 100644 mm/page_reporting.c

--

^ permalink raw reply	[flat|nested] 82+ messages in thread

* [PATCH v9 1/8] mm: Add per-cpu logic to page shuffling
  2019-09-07 17:25 [PATCH v9 0/8] stg mail -e --version=v9 \ Alexander Duyck
@ 2019-09-07 17:25 ` Alexander Duyck
  2019-09-09  8:14   ` David Hildenbrand
  2019-09-09  9:07   ` Kirill A. Shutemov
  2019-09-07 17:25 ` [PATCH v9 2/8] mm: Adjust shuffle code to allow for future coalescing Alexander Duyck
                   ` (8 subsequent siblings)
  9 siblings, 2 replies; 82+ messages in thread
From: Alexander Duyck @ 2019-09-07 17:25 UTC (permalink / raw)
  To: virtio-dev, kvm, mst, catalin.marinas, david, dave.hansen,
	linux-kernel, willy, mhocko, linux-mm, akpm, will,
	linux-arm-kernel, osalvador
  Cc: yang.zhang.wz, pagupta, konrad.wilk, nitesh, riel, lcapitulino,
	wei.w.wang, aarcange, ying.huang, pbonzini, dan.j.williams,
	fengguang.wu, alexander.h.duyck, kirill.shutemov

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

Change the logic used to generate randomness in the suffle path so that we
can avoid cache line bouncing. The previous logic was sharing the offset
and entropy word between all CPUs. As such this can result in cache line
bouncing and will ultimately hurt performance when enabled.

To resolve this I have moved to a per-cpu logic for maintaining a unsigned
long containing some amount of bits, and an offset value for which bit we
can use for entropy with each call.

Reviewed-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
---
 mm/shuffle.c |   33 +++++++++++++++++++++++----------
 1 file changed, 23 insertions(+), 10 deletions(-)

diff --git a/mm/shuffle.c b/mm/shuffle.c
index 3ce12481b1dc..9ba542ecf335 100644
--- a/mm/shuffle.c
+++ b/mm/shuffle.c
@@ -183,25 +183,38 @@ void __meminit __shuffle_free_memory(pg_data_t *pgdat)
 		shuffle_zone(z);
 }
 
+struct batched_bit_entropy {
+	unsigned long entropy_bool;
+	int position;
+};
+
+static DEFINE_PER_CPU(struct batched_bit_entropy, batched_entropy_bool);
+
 void add_to_free_area_random(struct page *page, struct free_area *area,
 		int migratetype)
 {
-	static u64 rand;
-	static u8 rand_bits;
+	struct batched_bit_entropy *batch;
+	unsigned long entropy;
+	int position;
 
 	/*
-	 * The lack of locking is deliberate. If 2 threads race to
-	 * update the rand state it just adds to the entropy.
+	 * We shouldn't need to disable IRQs as the only caller is
+	 * __free_one_page and it should only be called with the zone lock
+	 * held and either from IRQ context or with local IRQs disabled.
 	 */
-	if (rand_bits == 0) {
-		rand_bits = 64;
-		rand = get_random_u64();
+	batch = raw_cpu_ptr(&batched_entropy_bool);
+	position = batch->position;
+
+	if (--position < 0) {
+		batch->entropy_bool = get_random_long();
+		position = BITS_PER_LONG - 1;
 	}
 
-	if (rand & 1)
+	batch->position = position;
+	entropy = batch->entropy_bool;
+
+	if (1ul & (entropy >> position))
 		add_to_free_area(page, area, migratetype);
 	else
 		add_to_free_area_tail(page, area, migratetype);
-	rand_bits--;
-	rand >>= 1;
 }


^ permalink raw reply related	[flat|nested] 82+ messages in thread

* [PATCH v9 2/8] mm: Adjust shuffle code to allow for future coalescing
  2019-09-07 17:25 [PATCH v9 0/8] stg mail -e --version=v9 \ Alexander Duyck
  2019-09-07 17:25 ` [PATCH v9 1/8] mm: Add per-cpu logic to page shuffling Alexander Duyck
@ 2019-09-07 17:25 ` Alexander Duyck
  2019-09-09  8:19   ` David Hildenbrand
                     ` (2 more replies)
  2019-09-07 17:25 ` [PATCH v9 3/8] mm: Move set/get_pcppage_migratetype to mmzone.h Alexander Duyck
                   ` (7 subsequent siblings)
  9 siblings, 3 replies; 82+ messages in thread
From: Alexander Duyck @ 2019-09-07 17:25 UTC (permalink / raw)
  To: virtio-dev, kvm, mst, catalin.marinas, david, dave.hansen,
	linux-kernel, willy, mhocko, linux-mm, akpm, will,
	linux-arm-kernel, osalvador
  Cc: yang.zhang.wz, pagupta, konrad.wilk, nitesh, riel, lcapitulino,
	wei.w.wang, aarcange, ying.huang, pbonzini, dan.j.williams,
	fengguang.wu, alexander.h.duyck, kirill.shutemov

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

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

Reviewed-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
---
 include/linux/mmzone.h |   12 --------
 mm/page_alloc.c        |   70 +++++++++++++++++++++++++++---------------------
 mm/shuffle.c           |    9 +-----
 mm/shuffle.h           |   12 ++++++++
 4 files changed, 53 insertions(+), 50 deletions(-)

diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index bda20282746b..125f300981c6 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -116,18 +116,6 @@ static inline void add_to_free_area_tail(struct page *page, struct free_area *ar
 	area->nr_free++;
 }
 
-#ifdef CONFIG_SHUFFLE_PAGE_ALLOCATOR
-/* Used to preserve page allocation order entropy */
-void add_to_free_area_random(struct page *page, struct free_area *area,
-		int migratetype);
-#else
-static inline void add_to_free_area_random(struct page *page,
-		struct free_area *area, int migratetype)
-{
-	add_to_free_area(page, area, migratetype);
-}
-#endif
-
 /* Used for pages which are on another list */
 static inline void move_to_free_area(struct page *page, struct free_area *area,
 			     int migratetype)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index c5d62f1c2851..4e4356ba66c7 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -878,6 +878,36 @@ static inline struct capture_control *task_capc(struct zone *zone)
 #endif /* CONFIG_COMPACTION */
 
 /*
+ * If this is not the largest possible page, check if the buddy
+ * of the next-highest order is free. If it is, it's possible
+ * that pages are being freed that will coalesce soon. In case,
+ * that is happening, add the free page to the tail of the list
+ * so it's less likely to be used soon and more likely to be merged
+ * as a higher order page
+ */
+static inline bool
+buddy_merge_likely(unsigned long pfn, unsigned long buddy_pfn,
+		   struct page *page, unsigned int order)
+{
+	struct page *higher_page, *higher_buddy;
+	unsigned long combined_pfn;
+
+	if (order >= MAX_ORDER - 2)
+		return false;
+
+	if (!pfn_valid_within(buddy_pfn))
+		return false;
+
+	combined_pfn = buddy_pfn & pfn;
+	higher_page = page + (combined_pfn - pfn);
+	buddy_pfn = __find_buddy_pfn(combined_pfn, order + 1);
+	higher_buddy = higher_page + (buddy_pfn - combined_pfn);
+
+	return pfn_valid_within(buddy_pfn) &&
+	       page_is_buddy(higher_page, higher_buddy, order + 1);
+}
+
+/*
  * Freeing function for a buddy system allocator.
  *
  * The concept of a buddy system is to maintain direct-mapped table
@@ -906,11 +936,12 @@ static inline void __free_one_page(struct page *page,
 		struct zone *zone, unsigned int order,
 		int migratetype)
 {
-	unsigned long combined_pfn;
+	struct capture_control *capc = task_capc(zone);
 	unsigned long uninitialized_var(buddy_pfn);
-	struct page *buddy;
+	unsigned long combined_pfn;
+	struct free_area *area;
 	unsigned int max_order;
-	struct capture_control *capc = task_capc(zone);
+	struct page *buddy;
 
 	max_order = min_t(unsigned int, MAX_ORDER, pageblock_order + 1);
 
@@ -979,35 +1010,12 @@ static inline void __free_one_page(struct page *page,
 done_merging:
 	set_page_order(page, order);
 
-	/*
-	 * If this is not the largest possible page, check if the buddy
-	 * of the next-highest order is free. If it is, it's possible
-	 * that pages are being freed that will coalesce soon. In case,
-	 * that is happening, add the free page to the tail of the list
-	 * so it's less likely to be used soon and more likely to be merged
-	 * as a higher order page
-	 */
-	if ((order < MAX_ORDER-2) && pfn_valid_within(buddy_pfn)
-			&& !is_shuffle_order(order)) {
-		struct page *higher_page, *higher_buddy;
-		combined_pfn = buddy_pfn & pfn;
-		higher_page = page + (combined_pfn - pfn);
-		buddy_pfn = __find_buddy_pfn(combined_pfn, order + 1);
-		higher_buddy = higher_page + (buddy_pfn - combined_pfn);
-		if (pfn_valid_within(buddy_pfn) &&
-		    page_is_buddy(higher_page, higher_buddy, order + 1)) {
-			add_to_free_area_tail(page, &zone->free_area[order],
-					      migratetype);
-			return;
-		}
-	}
-
-	if (is_shuffle_order(order))
-		add_to_free_area_random(page, &zone->free_area[order],
-				migratetype);
+	area = &zone->free_area[order];
+	if (is_shuffle_order(order) ? shuffle_pick_tail() :
+	    buddy_merge_likely(pfn, buddy_pfn, page, order))
+		add_to_free_area_tail(page, area, migratetype);
 	else
-		add_to_free_area(page, &zone->free_area[order], migratetype);
-
+		add_to_free_area(page, area, migratetype);
 }
 
 /*
diff --git a/mm/shuffle.c b/mm/shuffle.c
index 9ba542ecf335..345cb4347455 100644
--- a/mm/shuffle.c
+++ b/mm/shuffle.c
@@ -4,7 +4,6 @@
 #include <linux/mm.h>
 #include <linux/init.h>
 #include <linux/mmzone.h>
-#include <linux/random.h>
 #include <linux/moduleparam.h>
 #include "internal.h"
 #include "shuffle.h"
@@ -190,8 +189,7 @@ struct batched_bit_entropy {
 
 static DEFINE_PER_CPU(struct batched_bit_entropy, batched_entropy_bool);
 
-void add_to_free_area_random(struct page *page, struct free_area *area,
-		int migratetype)
+bool __shuffle_pick_tail(void)
 {
 	struct batched_bit_entropy *batch;
 	unsigned long entropy;
@@ -213,8 +211,5 @@ void add_to_free_area_random(struct page *page, struct free_area *area,
 	batch->position = position;
 	entropy = batch->entropy_bool;
 
-	if (1ul & (entropy >> position))
-		add_to_free_area(page, area, migratetype);
-	else
-		add_to_free_area_tail(page, area, migratetype);
+	return 1ul & (entropy >> position);
 }
diff --git a/mm/shuffle.h b/mm/shuffle.h
index 777a257a0d2f..0723eb97f22f 100644
--- a/mm/shuffle.h
+++ b/mm/shuffle.h
@@ -3,6 +3,7 @@
 #ifndef _MM_SHUFFLE_H
 #define _MM_SHUFFLE_H
 #include <linux/jump_label.h>
+#include <linux/random.h>
 
 /*
  * SHUFFLE_ENABLE is called from the command line enabling path, or by
@@ -22,6 +23,7 @@ enum mm_shuffle_ctl {
 DECLARE_STATIC_KEY_FALSE(page_alloc_shuffle_key);
 extern void page_alloc_shuffle(enum mm_shuffle_ctl ctl);
 extern void __shuffle_free_memory(pg_data_t *pgdat);
+extern bool __shuffle_pick_tail(void);
 static inline void shuffle_free_memory(pg_data_t *pgdat)
 {
 	if (!static_branch_unlikely(&page_alloc_shuffle_key))
@@ -43,6 +45,11 @@ static inline bool is_shuffle_order(int order)
 		return false;
 	return order >= SHUFFLE_ORDER;
 }
+
+static inline bool shuffle_pick_tail(void)
+{
+	return __shuffle_pick_tail();
+}
 #else
 static inline void shuffle_free_memory(pg_data_t *pgdat)
 {
@@ -60,5 +67,10 @@ static inline bool is_shuffle_order(int order)
 {
 	return false;
 }
+
+static inline bool shuffle_pick_tail(void)
+{
+	return false;
+}
 #endif
 #endif /* _MM_SHUFFLE_H */


^ permalink raw reply related	[flat|nested] 82+ messages in thread

* [PATCH v9 3/8] mm: Move set/get_pcppage_migratetype to mmzone.h
  2019-09-07 17:25 [PATCH v9 0/8] stg mail -e --version=v9 \ Alexander Duyck
  2019-09-07 17:25 ` [PATCH v9 1/8] mm: Add per-cpu logic to page shuffling Alexander Duyck
  2019-09-07 17:25 ` [PATCH v9 2/8] mm: Adjust shuffle code to allow for future coalescing Alexander Duyck
@ 2019-09-07 17:25 ` Alexander Duyck
  2019-09-09  8:22   ` David Hildenbrand
                     ` (2 more replies)
  2019-09-07 17:25 ` [PATCH v9 4/8] mm: Use zone and order instead of free area in free_list manipulators Alexander Duyck
                   ` (6 subsequent siblings)
  9 siblings, 3 replies; 82+ messages in thread
From: Alexander Duyck @ 2019-09-07 17:25 UTC (permalink / raw)
  To: virtio-dev, kvm, mst, catalin.marinas, david, dave.hansen,
	linux-kernel, willy, mhocko, linux-mm, akpm, will,
	linux-arm-kernel, osalvador
  Cc: yang.zhang.wz, pagupta, konrad.wilk, nitesh, riel, lcapitulino,
	wei.w.wang, aarcange, ying.huang, pbonzini, dan.j.williams,
	fengguang.wu, alexander.h.duyck, kirill.shutemov

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

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

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

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


^ permalink raw reply related	[flat|nested] 82+ messages in thread

* [PATCH v9 4/8] mm: Use zone and order instead of free area in free_list manipulators
  2019-09-07 17:25 [PATCH v9 0/8] stg mail -e --version=v9 \ Alexander Duyck
                   ` (2 preceding siblings ...)
  2019-09-07 17:25 ` [PATCH v9 3/8] mm: Move set/get_pcppage_migratetype to mmzone.h Alexander Duyck
@ 2019-09-07 17:25 ` Alexander Duyck
  2019-09-10 12:27   ` Michal Hocko
  2019-09-07 17:25 ` [PATCH v9 5/8] arm64: Move hugetlb related definitions out of pgtable.h to page-defs.h Alexander Duyck
                   ` (5 subsequent siblings)
  9 siblings, 1 reply; 82+ messages in thread
From: Alexander Duyck @ 2019-09-07 17:25 UTC (permalink / raw)
  To: virtio-dev, kvm, mst, catalin.marinas, david, dave.hansen,
	linux-kernel, willy, mhocko, linux-mm, akpm, will,
	linux-arm-kernel, osalvador
  Cc: yang.zhang.wz, pagupta, konrad.wilk, nitesh, riel, lcapitulino,
	wei.w.wang, aarcange, ying.huang, pbonzini, dan.j.williams,
	fengguang.wu, alexander.h.duyck, kirill.shutemov

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

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

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

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

diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index 125f300981c6..2ddf1f1971c0 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -100,29 +100,6 @@ struct free_area {
 	unsigned long		nr_free;
 };
 
-/* Used for pages not on another list */
-static inline void add_to_free_area(struct page *page, struct free_area *area,
-			     int migratetype)
-{
-	list_add(&page->lru, &area->free_list[migratetype]);
-	area->nr_free++;
-}
-
-/* Used for pages not on another list */
-static inline void add_to_free_area_tail(struct page *page, struct free_area *area,
-				  int migratetype)
-{
-	list_add_tail(&page->lru, &area->free_list[migratetype]);
-	area->nr_free++;
-}
-
-/* Used for pages which are on another list */
-static inline void move_to_free_area(struct page *page, struct free_area *area,
-			     int migratetype)
-{
-	list_move(&page->lru, &area->free_list[migratetype]);
-}
-
 static inline struct page *get_page_from_free_area(struct free_area *area,
 					    int migratetype)
 {
@@ -130,15 +107,6 @@ static inline struct page *get_page_from_free_area(struct free_area *area,
 					struct page, lru);
 }
 
-static inline void del_page_from_free_area(struct page *page,
-		struct free_area *area)
-{
-	list_del(&page->lru);
-	__ClearPageBuddy(page);
-	set_page_private(page, 0);
-	area->nr_free--;
-}
-
 static inline bool free_area_empty(struct free_area *area, int migratetype)
 {
 	return list_empty(&area->free_list[migratetype]);
@@ -796,6 +764,44 @@ static inline bool pgdat_is_empty(pg_data_t *pgdat)
 	return !pgdat->node_start_pfn && !pgdat->node_spanned_pages;
 }
 
+/* Used for pages not on another list */
+static inline void add_to_free_list(struct page *page, struct zone *zone,
+				    unsigned int order, int migratetype)
+{
+	struct free_area *area = &zone->free_area[order];
+
+	list_add(&page->lru, &area->free_list[migratetype]);
+	area->nr_free++;
+}
+
+/* Used for pages not on another list */
+static inline void add_to_free_list_tail(struct page *page, struct zone *zone,
+					 unsigned int order, int migratetype)
+{
+	struct free_area *area = &zone->free_area[order];
+
+	list_add_tail(&page->lru, &area->free_list[migratetype]);
+	area->nr_free++;
+}
+
+/* Used for pages which are on another list */
+static inline void move_to_free_list(struct page *page, struct zone *zone,
+				     unsigned int order, int migratetype)
+{
+	struct free_area *area = &zone->free_area[order];
+
+	list_move(&page->lru, &area->free_list[migratetype]);
+}
+
+static inline void del_page_from_free_list(struct page *page, struct zone *zone,
+					   unsigned int order)
+{
+	list_del(&page->lru);
+	__ClearPageBuddy(page);
+	set_page_private(page, 0);
+	zone->free_area[order].nr_free--;
+}
+
 #include <linux/memory_hotplug.h>
 
 void build_all_zonelists(pg_data_t *pgdat);
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index a791f2baeeeb..f85dc1561b85 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -921,7 +921,6 @@ static inline void __free_one_page(struct page *page,
 	struct capture_control *capc = task_capc(zone);
 	unsigned long uninitialized_var(buddy_pfn);
 	unsigned long combined_pfn;
-	struct free_area *area;
 	unsigned int max_order;
 	struct page *buddy;
 
@@ -958,7 +957,7 @@ static inline void __free_one_page(struct page *page,
 		if (page_is_guard(buddy))
 			clear_page_guard(zone, buddy, order, migratetype);
 		else
-			del_page_from_free_area(buddy, &zone->free_area[order]);
+			del_page_from_free_list(buddy, zone, order);
 		combined_pfn = buddy_pfn & pfn;
 		page = page + (combined_pfn - pfn);
 		pfn = combined_pfn;
@@ -992,12 +991,11 @@ static inline void __free_one_page(struct page *page,
 done_merging:
 	set_page_order(page, order);
 
-	area = &zone->free_area[order];
 	if (is_shuffle_order(order) ? shuffle_pick_tail() :
 	    buddy_merge_likely(pfn, buddy_pfn, page, order))
-		add_to_free_area_tail(page, area, migratetype);
+		add_to_free_list_tail(page, zone, order, migratetype);
 	else
-		add_to_free_area(page, area, migratetype);
+		add_to_free_list(page, zone, order, migratetype);
 }
 
 /*
@@ -2001,13 +1999,11 @@ void __init init_cma_reserved_pageblock(struct page *page)
  * -- nyc
  */
 static inline void expand(struct zone *zone, struct page *page,
-	int low, int high, struct free_area *area,
-	int migratetype)
+	int low, int high, int migratetype)
 {
 	unsigned long size = 1 << high;
 
 	while (high > low) {
-		area--;
 		high--;
 		size >>= 1;
 		VM_BUG_ON_PAGE(bad_range(zone, &page[size]), &page[size]);
@@ -2021,7 +2017,7 @@ static inline void expand(struct zone *zone, struct page *page,
 		if (set_page_guard(zone, &page[size], high, migratetype))
 			continue;
 
-		add_to_free_area(&page[size], area, migratetype);
+		add_to_free_list(&page[size], zone, high, migratetype);
 		set_page_order(&page[size], high);
 	}
 }
@@ -2179,8 +2175,8 @@ struct page *__rmqueue_smallest(struct zone *zone, unsigned int order,
 		page = get_page_from_free_area(area, migratetype);
 		if (!page)
 			continue;
-		del_page_from_free_area(page, area);
-		expand(zone, page, order, current_order, area, migratetype);
+		del_page_from_free_list(page, zone, current_order);
+		expand(zone, page, order, current_order, migratetype);
 		set_pcppage_migratetype(page, migratetype);
 		return page;
 	}
@@ -2188,7 +2184,6 @@ struct page *__rmqueue_smallest(struct zone *zone, unsigned int order,
 	return NULL;
 }
 
-
 /*
  * This array describes the order lists are fallen back to when
  * the free lists for the desirable migrate type are depleted
@@ -2254,7 +2249,7 @@ static int move_freepages(struct zone *zone,
 		VM_BUG_ON_PAGE(page_zone(page) != zone, page);
 
 		order = page_order(page);
-		move_to_free_area(page, &zone->free_area[order], migratetype);
+		move_to_free_list(page, zone, order, migratetype);
 		page += 1 << order;
 		pages_moved += 1 << order;
 	}
@@ -2370,7 +2365,6 @@ static void steal_suitable_fallback(struct zone *zone, struct page *page,
 		unsigned int alloc_flags, int start_type, bool whole_block)
 {
 	unsigned int current_order = page_order(page);
-	struct free_area *area;
 	int free_pages, movable_pages, alike_pages;
 	int old_block_type;
 
@@ -2441,8 +2435,7 @@ static void steal_suitable_fallback(struct zone *zone, struct page *page,
 	return;
 
 single_page:
-	area = &zone->free_area[current_order];
-	move_to_free_area(page, area, start_type);
+	move_to_free_list(page, zone, current_order, start_type);
 }
 
 /*
@@ -3113,7 +3106,6 @@ void split_page(struct page *page, unsigned int order)
 
 int __isolate_free_page(struct page *page, unsigned int order)
 {
-	struct free_area *area = &page_zone(page)->free_area[order];
 	unsigned long watermark;
 	struct zone *zone;
 	int mt;
@@ -3139,7 +3131,7 @@ int __isolate_free_page(struct page *page, unsigned int order)
 
 	/* Remove page from free list */
 
-	del_page_from_free_area(page, area);
+	del_page_from_free_list(page, zone, order);
 
 	/*
 	 * Set the pageblock if the isolated page is at least half of a
@@ -8560,7 +8552,7 @@ void zone_pcp_reset(struct zone *zone)
 		pr_info("remove from free list %lx %d %lx\n",
 			pfn, 1 << order, end_pfn);
 #endif
-		del_page_from_free_area(page, &zone->free_area[order]);
+		del_page_from_free_list(page, zone, order);
 		for (i = 0; i < (1 << order); i++)
 			SetPageReserved((page+i));
 		pfn += (1 << order);


^ permalink raw reply related	[flat|nested] 82+ messages in thread

* [PATCH v9 5/8] arm64: Move hugetlb related definitions out of pgtable.h to page-defs.h
  2019-09-07 17:25 [PATCH v9 0/8] stg mail -e --version=v9 \ Alexander Duyck
                   ` (3 preceding siblings ...)
  2019-09-07 17:25 ` [PATCH v9 4/8] mm: Use zone and order instead of free area in free_list manipulators Alexander Duyck
@ 2019-09-07 17:25 ` Alexander Duyck
  2019-09-09  8:52   ` David Hildenbrand
  2019-09-17 17:48   ` Will Deacon
  2019-09-07 17:25 ` [PATCH v9 6/8] mm: Introduce Reported pages Alexander Duyck
                   ` (4 subsequent siblings)
  9 siblings, 2 replies; 82+ messages in thread
From: Alexander Duyck @ 2019-09-07 17:25 UTC (permalink / raw)
  To: virtio-dev, kvm, mst, catalin.marinas, david, dave.hansen,
	linux-kernel, willy, mhocko, linux-mm, akpm, will,
	linux-arm-kernel, osalvador
  Cc: yang.zhang.wz, pagupta, konrad.wilk, nitesh, riel, lcapitulino,
	wei.w.wang, aarcange, ying.huang, pbonzini, dan.j.williams,
	fengguang.wu, alexander.h.duyck, kirill.shutemov

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

Move the static definition for things such as HUGETLB_PAGE_ORDER out of
asm/pgtable.h and place it in page-defs.h. By doing this the includes
become much easier to deal with as currently arm64 is the only architecture
that didn't include this definition in the asm/page.h file or a file
included by it.

It also makes logical sense as PAGE_SHIFT was already defined in
page-defs.h so now we also have HPAGE_SHIFT defined there as well.

Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
---
 arch/arm64/include/asm/page-def.h |    9 +++++++++
 arch/arm64/include/asm/pgtable.h  |    9 ---------
 2 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/arch/arm64/include/asm/page-def.h b/arch/arm64/include/asm/page-def.h
index f99d48ecbeef..1c5b079e2482 100644
--- a/arch/arm64/include/asm/page-def.h
+++ b/arch/arm64/include/asm/page-def.h
@@ -20,4 +20,13 @@
 #define CONT_SIZE		(_AC(1, UL) << (CONT_SHIFT + PAGE_SHIFT))
 #define CONT_MASK		(~(CONT_SIZE-1))
 
+/*
+ * Hugetlb definitions.
+ */
+#define HUGE_MAX_HSTATE		4
+#define HPAGE_SHIFT		PMD_SHIFT
+#define HPAGE_SIZE		(_AC(1, UL) << HPAGE_SHIFT)
+#define HPAGE_MASK		(~(HPAGE_SIZE - 1))
+#define HUGETLB_PAGE_ORDER	(HPAGE_SHIFT - PAGE_SHIFT)
+
 #endif /* __ASM_PAGE_DEF_H */
diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index 7576df00eb50..06a376de9bd6 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -305,15 +305,6 @@ static inline int pte_same(pte_t pte_a, pte_t pte_b)
  */
 #define pte_mkhuge(pte)		(__pte(pte_val(pte) & ~PTE_TABLE_BIT))
 
-/*
- * Hugetlb definitions.
- */
-#define HUGE_MAX_HSTATE		4
-#define HPAGE_SHIFT		PMD_SHIFT
-#define HPAGE_SIZE		(_AC(1, UL) << HPAGE_SHIFT)
-#define HPAGE_MASK		(~(HPAGE_SIZE - 1))
-#define HUGETLB_PAGE_ORDER	(HPAGE_SHIFT - PAGE_SHIFT)
-
 static inline pte_t pgd_pte(pgd_t pgd)
 {
 	return __pte(pgd_val(pgd));


^ permalink raw reply related	[flat|nested] 82+ messages in thread

* [PATCH v9 6/8] mm: Introduce Reported pages
  2019-09-07 17:25 [PATCH v9 0/8] stg mail -e --version=v9 \ Alexander Duyck
                   ` (4 preceding siblings ...)
  2019-09-07 17:25 ` [PATCH v9 5/8] arm64: Move hugetlb related definitions out of pgtable.h to page-defs.h Alexander Duyck
@ 2019-09-07 17:25 ` Alexander Duyck
  2019-09-09 14:42   ` Kirill A. Shutemov
  2019-09-07 17:26 ` [PATCH v9 7/8] virtio-balloon: Pull page poisoning config out of free page hinting Alexander Duyck
                   ` (3 subsequent siblings)
  9 siblings, 1 reply; 82+ messages in thread
From: Alexander Duyck @ 2019-09-07 17:25 UTC (permalink / raw)
  To: virtio-dev, kvm, mst, catalin.marinas, david, dave.hansen,
	linux-kernel, willy, mhocko, linux-mm, akpm, will,
	linux-arm-kernel, osalvador
  Cc: yang.zhang.wz, pagupta, konrad.wilk, nitesh, riel, lcapitulino,
	wei.w.wang, aarcange, ying.huang, pbonzini, dan.j.williams,
	fengguang.wu, alexander.h.duyck, kirill.shutemov

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

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

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

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

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

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

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

Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
---
 include/linux/mmzone.h         |   52 +++++-
 include/linux/page-flags.h     |   11 +
 include/linux/page_reporting.h |  178 ++++++++++++++++++++
 mm/Kconfig                     |    5 +
 mm/Makefile                    |    1 
 mm/memory_hotplug.c            |    1 
 mm/page_alloc.c                |  115 ++++++++++++-
 mm/page_reporting.c            |  358 ++++++++++++++++++++++++++++++++++++++++
 8 files changed, 711 insertions(+), 10 deletions(-)
 create mode 100644 include/linux/page_reporting.h
 create mode 100644 mm/page_reporting.c

diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index 2ddf1f1971c0..4b2c44d7e266 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -463,6 +463,14 @@ struct zone {
 	seqlock_t		span_seqlock;
 #endif
 
+#ifdef CONFIG_PAGE_REPORTING
+	/*
+	 * Pointer to reported page tracking statistics array. The size of
+	 * the array is MAX_ORDER - PAGE_REPORTING_MIN_ORDER. NULL when
+	 * unused page reporting is not present.
+	 */
+	unsigned long		*reported_pages;
+#endif
 	int initialized;
 
 	/* Write-intensive fields used from the page allocator */
@@ -538,6 +546,14 @@ enum zone_flags {
 	ZONE_BOOSTED_WATERMARK,		/* zone recently boosted watermarks.
 					 * Cleared when kswapd is woken.
 					 */
+	ZONE_PAGE_REPORTING_REQUESTED,	/* zone enabled page reporting and has
+					 * requested flushing the data out of
+					 * higher order pages.
+					 */
+	ZONE_PAGE_REPORTING_ACTIVE,	/* zone enabled page reporting and is
+					 * activly flushing the data out of
+					 * higher order pages.
+					 */
 };
 
 static inline unsigned long zone_managed_pages(struct zone *zone)
@@ -764,6 +780,8 @@ static inline bool pgdat_is_empty(pg_data_t *pgdat)
 	return !pgdat->node_start_pfn && !pgdat->node_spanned_pages;
 }
 
+#include <linux/page_reporting.h>
+
 /* Used for pages not on another list */
 static inline void add_to_free_list(struct page *page, struct zone *zone,
 				    unsigned int order, int migratetype)
@@ -778,24 +796,48 @@ static inline void add_to_free_list(struct page *page, struct zone *zone,
 static inline void add_to_free_list_tail(struct page *page, struct zone *zone,
 					 unsigned int order, int migratetype)
 {
-	struct free_area *area = &zone->free_area[order];
+	struct list_head *tail = get_unreported_tail(zone, order, migratetype);
 
-	list_add_tail(&page->lru, &area->free_list[migratetype]);
-	area->nr_free++;
+	/*
+	 * To prevent the unreported pages from being interleaved with the
+	 * reported ones while we are actively processing pages we will use
+	 * the head of the reported pages to determine the tail of the free
+	 * list.
+	 */
+	list_add_tail(&page->lru, tail);
+	zone->free_area[order].nr_free++;
 }
 
 /* Used for pages which are on another list */
 static inline void move_to_free_list(struct page *page, struct zone *zone,
 				     unsigned int order, int migratetype)
 {
-	struct free_area *area = &zone->free_area[order];
+	struct list_head *tail = get_unreported_tail(zone, order, migratetype);
+
+	/*
+	 * We must get the tail for our target list before moving the page on
+	 * the reported list as we will possibly be replacing the tail page of
+	 * the list with our current page if it is reported.
+	 */
+	if (unlikely(PageReported(page)))
+		move_page_to_reported_list(page, zone, migratetype);
 
-	list_move(&page->lru, &area->free_list[migratetype]);
+	/*
+	 * To prevent unreported pages from being mixed with the reported
+	 * ones we add pages to the tail of the list. By doing this the function
+	 * above can either label them as included in the reported list or not
+	 * and the result will be consistent.
+	 */
+	list_move_tail(&page->lru, tail);
 }
 
 static inline void del_page_from_free_list(struct page *page, struct zone *zone,
 					   unsigned int order)
 {
+	/* remove page from reported list, and clear reported state */
+	if (unlikely(PageReported(page)))
+		del_page_from_reported_list(page, zone);
+
 	list_del(&page->lru);
 	__ClearPageBuddy(page);
 	set_page_private(page, 0);
diff --git a/include/linux/page-flags.h b/include/linux/page-flags.h
index f91cb8898ff0..759a3b3956f2 100644
--- a/include/linux/page-flags.h
+++ b/include/linux/page-flags.h
@@ -163,6 +163,9 @@ enum pageflags {
 
 	/* non-lru isolated movable page */
 	PG_isolated = PG_reclaim,
+
+	/* Buddy pages. Used to track which pages have been reported */
+	PG_reported = PG_uptodate,
 };
 
 #ifndef __GENERATING_BOUNDS_H
@@ -432,6 +435,14 @@ static inline bool set_hwpoison_free_buddy_page(struct page *page)
 #endif
 
 /*
+ * PageReported() is used to track reported free pages within the Buddy
+ * allocator. We can use the non-atomic version of the test and set
+ * operations as both should be shielded with the zone lock to prevent
+ * any possible races on the setting or clearing of the bit.
+ */
+__PAGEFLAG(Reported, reported, PF_NO_COMPOUND)
+
+/*
  * On an anonymous page mapped into a user virtual memory area,
  * page->mapping points to its anon_vma, not to a struct address_space;
  * with the PAGE_MAPPING_ANON bit set to distinguish it.  See rmap.h.
diff --git a/include/linux/page_reporting.h b/include/linux/page_reporting.h
new file mode 100644
index 000000000000..836033ca237b
--- /dev/null
+++ b/include/linux/page_reporting.h
@@ -0,0 +1,178 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _LINUX_PAGE_REPORTING_H
+#define _LINUX_PAGE_REPORTING_H
+
+#include <linux/mmzone.h>
+#include <linux/jump_label.h>
+#include <linux/pageblock-flags.h>
+
+#define PAGE_REPORTING_MIN_ORDER	pageblock_order
+#define PAGE_REPORTING_HWM		32
+
+#ifdef CONFIG_PAGE_REPORTING
+struct page_reporting_dev_info {
+	/* function that alters pages to make them "reported" */
+	void (*report)(struct page_reporting_dev_info *phdev,
+		       unsigned int nents);
+
+	/* scatterlist containing pages to be processed */
+	struct scatterlist *sg;
+
+	/*
+	 * Upper limit on the number of pages that the react function
+	 * expects to be placed into the batch list to be processed.
+	 */
+	unsigned long capacity;
+
+	/* work struct for processing reports */
+	struct delayed_work work;
+
+	/*
+	 * The number of zones requesting reporting, plus one additional if
+	 * processing thread is active.
+	 */
+	atomic_t refcnt;
+};
+
+/* Boundary functions */
+struct list_head *__page_reporting_get_boundary(unsigned int order,
+						int migratetype);
+void page_reporting_del_from_boundary(struct page *page);
+void page_reporting_add_to_boundary(struct page *page, int migratetype);
+void page_reporting_move_to_boundary(struct page *page, struct zone *zone,
+				     int migratetype);
+
+/* Reported page accessors, defined in page_alloc.c */
+struct page *get_unreported_page(struct zone *zone, unsigned int order,
+				 int migratetype);
+void free_reported_page(struct page *page, unsigned int order);
+
+/* Tear-down and bring-up for page reporting devices */
+void page_reporting_shutdown(struct page_reporting_dev_info *phdev);
+int page_reporting_startup(struct page_reporting_dev_info *phdev);
+
+void __page_reporting_free_stats(struct zone *zone);
+void __page_reporting_request(struct zone *zone);
+
+static inline void __del_page_from_reported_list(struct page *page,
+						 struct zone *zone)
+{
+	/* page_private will contain the page order, so just use it directly */
+	zone->reported_pages[page_private(page) - PAGE_REPORTING_MIN_ORDER]--;
+
+	/* clear the flag so we can report on it when it returns */
+	__ClearPageReported(page);
+}
+#endif /* CONFIG_PAGE_REPORTING */
+
+/*
+ * Method for obtaining the tail of the free list. Using this allows for
+ * tail insertions of unreported pages into the region that is currently
+ * being scanned so as to avoid interleaving reported and unreported pages.
+ */
+static inline struct list_head *
+get_unreported_tail(struct zone *zone, unsigned int order, int migratetype)
+{
+#ifdef CONFIG_PAGE_REPORTING
+	if (order >= PAGE_REPORTING_MIN_ORDER &&
+	    test_bit(ZONE_PAGE_REPORTING_ACTIVE, &zone->flags))
+		return __page_reporting_get_boundary(order, migratetype);
+#endif
+	return &zone->free_area[order].free_list[migratetype];
+}
+
+/*
+ * Functions for adding/removing pages from reported end of list.
+ * All of them expect the zone lock to be held to maintain
+ * consistency of the reported list as a subset of the free list.
+ */
+static inline void add_page_to_reported_list(struct page *page,
+					     struct zone *zone,
+					     int order,
+					     int migratetype)
+{
+#ifdef CONFIG_PAGE_REPORTING
+	/* flag page as reported */
+	__SetPageReported(page);
+
+	/* update areated page accounting */
+	zone->reported_pages[order - PAGE_REPORTING_MIN_ORDER]++;
+
+	/* update boundary of new migratetype and record it */
+	page_reporting_add_to_boundary(page, migratetype);
+#endif
+}
+
+static inline void del_page_from_reported_list(struct page *page,
+					       struct zone *zone)
+{
+#ifdef CONFIG_PAGE_REPORTING
+	/* push boundary back if we removed the upper boundary */
+	if (test_bit(ZONE_PAGE_REPORTING_ACTIVE, &zone->flags))
+		page_reporting_del_from_boundary(page);
+
+	__del_page_from_reported_list(page, zone);
+#endif
+}
+
+static inline void move_page_to_reported_list(struct page *page,
+					      struct zone *zone,
+					      int migratetype)
+{
+#ifdef CONFIG_PAGE_REPORTING
+	page_reporting_move_to_boundary(page, zone, migratetype);
+#endif
+}
+
+/* Free reported_pages and reset reported page tracking count to 0 */
+static inline void page_reporting_reset(struct zone *zone)
+{
+#ifdef CONFIG_PAGE_REPORTING
+	if (zone->reported_pages)
+		__page_reporting_free_stats(zone);
+#endif
+}
+
+DECLARE_STATIC_KEY_FALSE(page_reporting_notify_enabled);
+
+/**
+ * page_reporting_notify_free - Free page notification to start page processing
+ * @zone: Pointer to current zone of last page processed
+ * @order: Order of last page added to zone
+ *
+ * This function is meant to act as a screener for __page_reporting_request
+ * which will determine if a give zone has crossed over the high-water mark
+ * that will justify us beginning page treatment. If we have crossed that
+ * threshold then it will start the process of pulling some pages and
+ * placing them in the batch list for treatment.
+ */
+static inline void page_reporting_notify_free(struct zone *zone, int order)
+{
+#ifdef CONFIG_PAGE_REPORTING
+	unsigned long nr_reported;
+
+	/* Called from hot path in __free_one_page() */
+	if (!static_branch_unlikely(&page_reporting_notify_enabled))
+		return;
+
+	/* Limit notifications only to higher order pages */
+	if (order < PAGE_REPORTING_MIN_ORDER)
+		return;
+
+	/* Do not bother with tests if we have already requested reporting */
+	if (test_bit(ZONE_PAGE_REPORTING_REQUESTED, &zone->flags))
+		return;
+
+	/* If reported_pages is not populated, assume 0 */
+	nr_reported = zone->reported_pages ?
+		    zone->reported_pages[order - PAGE_REPORTING_MIN_ORDER] : 0;
+
+	/* Only request it if we have enough to begin the page reporting */
+	if (zone->free_area[order].nr_free < nr_reported + PAGE_REPORTING_HWM)
+		return;
+
+	/* This is slow, but should be called very rarely */
+	__page_reporting_request(zone);
+#endif
+}
+#endif /*_LINUX_PAGE_REPORTING_H */
diff --git a/mm/Kconfig b/mm/Kconfig
index a5dae9a7eb51..be1a5db50df5 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -237,6 +237,11 @@ config COMPACTION
           linux-mm@kvack.org.
 
 #
+# support for unused page reporting
+config PAGE_REPORTING
+	bool
+
+#
 # support for page migration
 #
 config MIGRATION
diff --git a/mm/Makefile b/mm/Makefile
index d996846697ef..fc4fa17b6c83 100644
--- a/mm/Makefile
+++ b/mm/Makefile
@@ -107,3 +107,4 @@ obj-$(CONFIG_PERCPU_STATS) += percpu-stats.o
 obj-$(CONFIG_ZONE_DEVICE) += memremap.o
 obj-$(CONFIG_HMM_MIRROR) += hmm.o
 obj-$(CONFIG_MEMFD_CREATE) += memfd.o
+obj-$(CONFIG_PAGE_REPORTING) += page_reporting.o
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index 49f7bf91c25a..cb71a7190682 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -1613,6 +1613,7 @@ static int __ref __offline_pages(unsigned long start_pfn,
 	if (!populated_zone(zone)) {
 		zone_pcp_reset(zone);
 		build_all_zonelists(NULL);
+		page_reporting_reset(zone);
 	} else
 		zone_pcp_update(zone);
 
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index f85dc1561b85..615aea24c082 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -68,6 +68,7 @@
 #include <linux/lockdep.h>
 #include <linux/nmi.h>
 #include <linux/psi.h>
+#include <linux/page_reporting.h>
 
 #include <asm/sections.h>
 #include <asm/tlbflush.h>
@@ -916,7 +917,7 @@ static inline struct capture_control *task_capc(struct zone *zone)
 static inline void __free_one_page(struct page *page,
 		unsigned long pfn,
 		struct zone *zone, unsigned int order,
-		int migratetype)
+		int migratetype, bool reported)
 {
 	struct capture_control *capc = task_capc(zone);
 	unsigned long uninitialized_var(buddy_pfn);
@@ -991,11 +992,20 @@ static inline void __free_one_page(struct page *page,
 done_merging:
 	set_page_order(page, order);
 
-	if (is_shuffle_order(order) ? shuffle_pick_tail() :
-	    buddy_merge_likely(pfn, buddy_pfn, page, order))
+	if (reported ||
+	    (is_shuffle_order(order) ? shuffle_pick_tail() :
+	     buddy_merge_likely(pfn, buddy_pfn, page, order)))
 		add_to_free_list_tail(page, zone, order, migratetype);
 	else
 		add_to_free_list(page, zone, order, migratetype);
+
+	/*
+	 * No need to notify on a reported page as the total count of
+	 * unreported pages will not have increased since we have essentially
+	 * merged the reported page with one or more unreported pages.
+	 */
+	if (!reported)
+		page_reporting_notify_free(zone, order);
 }
 
 /*
@@ -1306,7 +1316,7 @@ static void free_pcppages_bulk(struct zone *zone, int count,
 		if (unlikely(isolated_pageblocks))
 			mt = get_pageblock_migratetype(page);
 
-		__free_one_page(page, page_to_pfn(page), zone, 0, mt);
+		__free_one_page(page, page_to_pfn(page), zone, 0, mt, false);
 		trace_mm_page_pcpu_drain(page, 0, mt);
 	}
 	spin_unlock(&zone->lock);
@@ -1322,7 +1332,7 @@ static void free_one_page(struct zone *zone,
 		is_migrate_isolate(migratetype))) {
 		migratetype = get_pfnblock_migratetype(page, pfn);
 	}
-	__free_one_page(page, pfn, zone, order, migratetype);
+	__free_one_page(page, pfn, zone, order, migratetype, false);
 	spin_unlock(&zone->lock);
 }
 
@@ -2184,6 +2194,101 @@ struct page *__rmqueue_smallest(struct zone *zone, unsigned int order,
 	return NULL;
 }
 
+#ifdef CONFIG_PAGE_REPORTING
+/**
+ * free_reported_page - Return a now-reported page back where we got it
+ * @page: Page that was reported
+ * @order: Order of the reported page
+ *
+ * This function will pull the migratetype and order information out
+ * of the page and attempt to return it where it found it. If the page
+ * is added to the free list without changes we will mark it as being
+ * reported.
+ */
+void free_reported_page(struct page *page, unsigned int order)
+{
+	struct zone *zone = page_zone(page);
+	unsigned long pfn;
+	unsigned int mt;
+
+	/* zone lock should be held when this function is called */
+	lockdep_assert_held(&zone->lock);
+
+	pfn = page_to_pfn(page);
+	mt = get_pfnblock_migratetype(page, pfn);
+	__free_one_page(page, pfn, zone, order, mt, true);
+
+	/*
+	 * If page was not comingled with another page we can consider
+	 * the result to be "reported" since part of the page hasn't been
+	 * modified, otherwise we would need to report on the new larger
+	 * page.
+	 */
+	if (PageBuddy(page) && page_order(page) == order)
+		add_page_to_reported_list(page, zone, order, mt);
+}
+
+/**
+ * get_unreported_page - Pull an unreported page from the free_list
+ * @zone: Zone to draw pages from
+ * @order: Order to draw pages from
+ * @mt: Migratetype to draw pages from
+ *
+ * This function will obtain a page from the free list. It will start by
+ * attempting to pull from the tail of the free list and if that is already
+ * reported on it will instead pull the head if that is unreported.
+ *
+ * The page will have the migrate type and order stored in the page
+ * metadata. While being processed the page will not be avaialble for
+ * allocation.
+ *
+ * Return: page pointer if raw page found, otherwise NULL
+ */
+struct page *get_unreported_page(struct zone *zone, unsigned int order, int mt)
+{
+	struct list_head *tail = get_unreported_tail(zone, order, mt);
+	struct free_area *area = &(zone->free_area[order]);
+	struct list_head *list = &area->free_list[mt];
+	struct page *page;
+
+	/* zone lock should be held when this function is called */
+	lockdep_assert_held(&zone->lock);
+
+	/* Find a page of the appropriate size in the preferred list */
+	page = list_last_entry(tail, struct page, lru);
+	list_for_each_entry_from_reverse(page, list, lru) {
+		/* If we entered this loop then the "raw" list isn't empty */
+
+		/* If the page is reported try the head of the list */
+		if (PageReported(page)) {
+			page = list_first_entry(list, struct page, lru);
+
+			/*
+			 * If both the head and tail are reported then reset
+			 * the boundary so that we read as an empty list
+			 * next time and bail out.
+			 */
+			if (PageReported(page)) {
+				page_reporting_add_to_boundary(page, mt);
+				break;
+			}
+		}
+
+		del_page_from_free_list(page, zone, order);
+
+		/*
+		 * Page will not be available for allocation while we are
+		 * processing it so update the freepage state.
+		 */
+		__mod_zone_freepage_state(zone, -(1 << order), mt);
+
+		return page;
+	}
+
+	return NULL;
+}
+#endif /* CONFIG_PAGE_REPORTING */
+
 /*
  * This array describes the order lists are fallen back to when
  * the free lists for the desirable migrate type are depleted
diff --git a/mm/page_reporting.c b/mm/page_reporting.c
new file mode 100644
index 000000000000..a59ef53eb0b8
--- /dev/null
+++ b/mm/page_reporting.c
@@ -0,0 +1,358 @@
+// SPDX-License-Identifier: GPL-2.0
+#include <linux/mm.h>
+#include <linux/mmzone.h>
+#include <linux/page-isolation.h>
+#include <linux/gfp.h>
+#include <linux/export.h>
+#include <linux/delay.h>
+#include <linux/slab.h>
+#include <linux/scatterlist.h>
+#include "internal.h"
+
+static struct page_reporting_dev_info __rcu *ph_dev_info __read_mostly;
+struct list_head **boundary __read_mostly;
+
+static inline struct list_head **get_boundary_ptr(unsigned int order,
+						  unsigned int migratetype)
+{
+	return boundary +
+	       (order - PAGE_REPORTING_MIN_ORDER) * MIGRATE_TYPES + migratetype;
+}
+
+static void page_reporting_reset_boundary(struct zone *zone, unsigned int order,
+					  unsigned int migratetype)
+{
+	struct list_head **tail = get_boundary_ptr(order, migratetype);
+
+	*tail = &zone->free_area[order].free_list[migratetype];
+}
+
+#define for_each_reporting_migratetype_order(_order, _type) \
+	for (_order = MAX_ORDER; _order-- != PAGE_REPORTING_MIN_ORDER;) \
+		for (_type = MIGRATE_TYPES; _type--;) \
+			if (!is_migrate_isolate(_type))
+
+static int page_reporting_populate_metadata(struct zone *zone)
+{
+	unsigned int order, mt;
+
+	/*
+	 * We need to make sure we have somewhere to store the tracking
+	 * data for how many reported pages are in the zone. To do that
+	 * we need to make certain zone->reported_pages is populated.
+	 */
+	if (!zone->reported_pages) {
+		zone->reported_pages =
+			kcalloc(MAX_ORDER - PAGE_REPORTING_MIN_ORDER,
+				sizeof(unsigned long),
+				GFP_KERNEL);
+		if (!zone->reported_pages)
+			return -ENOMEM;
+	}
+
+	/* Update boundary data to reflect the zone we are currently working */
+	for_each_reporting_migratetype_order(order, mt)
+		page_reporting_reset_boundary(zone, order, mt);
+
+	return 0;
+}
+
+struct list_head *__page_reporting_get_boundary(unsigned int order,
+						int migratetype)
+{
+	return *get_boundary_ptr(order, migratetype);
+}
+
+void page_reporting_del_from_boundary(struct page *page)
+{
+	unsigned int order = page_private(page);
+	int mt = get_pcppage_migratetype(page);
+	struct list_head **tail = get_boundary_ptr(order, mt);
+
+	if (*tail == &page->lru)
+		*tail = page->lru.next;
+}
+
+void page_reporting_add_to_boundary(struct page *page, int migratetype)
+{
+	unsigned int order = page_private(page);
+	struct list_head **tail = get_boundary_ptr(order, migratetype);
+
+	*tail = &page->lru;
+	set_pcppage_migratetype(page, migratetype);
+}
+
+void page_reporting_move_to_boundary(struct page *page, struct zone *zone,
+				     int dest_mt)
+{
+	/*
+	 * We essentially have two options available to us. The first is to
+	 * move the page from the boundary list on one migratetype to the
+	 * list for the new migratetype assuming reporting is still active.
+	 *
+	 * The other option is to clear the reported state of the page as
+	 * we will not be adding it to the group of pages that were already
+	 * reported. It is cheaper to just rereport such pages then go
+	 * through and do a special search to skip over them. If the page
+	 * is being moved into isolation we can defer this until the page
+	 * comes out of isolation since we do not scan the isolated
+	 * migratetype.
+	 */
+	if (test_bit(ZONE_PAGE_REPORTING_ACTIVE, &zone->flags)) {
+		page_reporting_del_from_boundary(page);
+		page_reporting_add_to_boundary(page, dest_mt);
+	} else if (!is_migrate_isolate(dest_mt)) {
+		__del_page_from_reported_list(page, zone);
+	}
+}
+
+static unsigned int page_reporting_fill(struct zone *zone,
+					struct page_reporting_dev_info *phdev)
+{
+	struct scatterlist *sg = phdev->sg;
+	unsigned int order, mt, count = 0;
+
+	sg_init_table(phdev->sg, phdev->capacity);
+
+	for_each_reporting_migratetype_order(order, mt) {
+		struct page *page;
+
+		/*
+		 * Pull pages from free list until we have drained
+		 * it or we have reached capacity.
+		 */
+		while ((page = get_unreported_page(zone, order, mt))) {
+			sg_set_page(&sg[count], page, PAGE_SIZE << order, 0);
+
+			if (++count == phdev->capacity)
+				return count;
+		}
+	}
+
+	/* mark end of scatterlist due to underflow */
+	if (count)
+		sg_mark_end(&sg[count - 1]);
+
+	/*
+	 * If there are no longer enough free pages to fully populate
+	 * the scatterlist, then we can just shut it down for this zone.
+	 */
+	__clear_bit(ZONE_PAGE_REPORTING_REQUESTED, &zone->flags);
+	atomic_dec(&phdev->refcnt);
+
+	return count;
+}
+
+static void page_reporting_drain(struct page_reporting_dev_info *phdev)
+{
+	struct scatterlist *sg = phdev->sg;
+
+	/*
+	 * Drain the now reported pages back into their respective
+	 * free lists/areas. We assume at least one page is populated.
+	 */
+	do {
+		free_reported_page(sg_page(sg), get_order(sg->length));
+	} while (!sg_is_last(sg++));
+}
+
+/*
+ * The page reporting cycle consists of 4 stages, fill, report, drain, and idle.
+ * We will cycle through the first 3 stages until we fail to obtain any
+ * pages, in that case we will switch to idle.
+ */
+static void page_reporting_cycle(struct zone *zone,
+				 struct page_reporting_dev_info *phdev)
+{
+	/*
+	 * Guarantee boundaries and stats are populated before we
+	 * start placing reported pages in the zone.
+	 */
+	if (page_reporting_populate_metadata(zone))
+		return;
+
+	spin_lock_irq(&zone->lock);
+
+	/* set bit indicating boundaries are present */
+	__set_bit(ZONE_PAGE_REPORTING_ACTIVE, &zone->flags);
+
+	do {
+		/* Pull pages out of allocator into a scaterlist */
+		unsigned int nents = page_reporting_fill(zone, phdev);
+
+		/* no pages were acquired, give up */
+		if (!nents)
+			break;
+
+		spin_unlock_irq(&zone->lock);
+
+		/* begin processing pages in local list */
+		phdev->report(phdev, nents);
+
+		spin_lock_irq(&zone->lock);
+
+		/*
+		 * We should have a scatterlist of pages that have been
+		 * processed. Return them to their original free lists.
+		 */
+		page_reporting_drain(phdev);
+
+		/* keep pulling pages till there are none to pull */
+	} while (test_bit(ZONE_PAGE_REPORTING_REQUESTED, &zone->flags));
+
+	/* processing of the zone is complete, we can disable boundaries */
+	__clear_bit(ZONE_PAGE_REPORTING_ACTIVE, &zone->flags);
+
+	spin_unlock_irq(&zone->lock);
+}
+
+static void page_reporting_process(struct work_struct *work)
+{
+	struct delayed_work *d_work = to_delayed_work(work);
+	struct page_reporting_dev_info *phdev =
+		container_of(d_work, struct page_reporting_dev_info, work);
+	struct zone *zone = first_online_pgdat()->node_zones;
+
+	do {
+		if (test_bit(ZONE_PAGE_REPORTING_REQUESTED, &zone->flags))
+			page_reporting_cycle(zone, phdev);
+
+		/* Move to next zone, if at end of list start over */
+		zone = next_zone(zone) ? : first_online_pgdat()->node_zones;
+
+		/*
+		 * As long as refcnt has not reached zero there are still
+		 * zones to be processed.
+		 */
+	} while (atomic_read(&phdev->refcnt));
+}
+
+/* request page reporting on this zone */
+void __page_reporting_request(struct zone *zone)
+{
+	struct page_reporting_dev_info *phdev;
+
+	rcu_read_lock();
+
+	/*
+	 * We use RCU to protect the ph_dev_info pointer. In almost all
+	 * cases this should be present, however in the unlikely case of
+	 * a shutdown this will be NULL and we should exit.
+	 */
+	phdev = rcu_dereference(ph_dev_info);
+	if (unlikely(!phdev))
+		goto out;
+
+	/*
+	 * We can use separate test and set operations here as there
+	 * is nothing else that can set or clear this bit while we are
+	 * holding the zone lock. The advantage to doing it this way is
+	 * that we don't have to dirty the cacheline unless we are
+	 * changing the value.
+	 */
+	__set_bit(ZONE_PAGE_REPORTING_REQUESTED, &zone->flags);
+
+	/*
+	 * Delay the start of work to allow a sizable queue to
+	 * build. For now we are limiting this to running no more
+	 * than 10 times per second.
+	 */
+	if (!atomic_fetch_inc(&phdev->refcnt))
+		schedule_delayed_work(&phdev->work, HZ / 10);
+out:
+	rcu_read_unlock();
+}
+
+void __page_reporting_free_stats(struct zone *zone)
+{
+	/* free reported_page statisitics */
+	kfree(zone->reported_pages);
+	zone->reported_pages = NULL;
+}
+
+static DEFINE_MUTEX(page_reporting_mutex);
+DEFINE_STATIC_KEY_FALSE(page_reporting_notify_enabled);
+
+void page_reporting_shutdown(struct page_reporting_dev_info *phdev)
+{
+	mutex_lock(&page_reporting_mutex);
+
+	if (rcu_access_pointer(ph_dev_info) == phdev) {
+		/* Disable page reporting notification */
+		static_branch_disable(&page_reporting_notify_enabled);
+		RCU_INIT_POINTER(ph_dev_info, NULL);
+		synchronize_rcu();
+
+		/* Flush any existing work, and lock it out */
+		cancel_delayed_work_sync(&phdev->work);
+
+		/* Free scatterlist */
+		kfree(phdev->sg);
+		phdev->sg = NULL;
+
+		/* Free boundaries */
+		kfree(boundary);
+		boundary = NULL;
+	}
+
+	mutex_unlock(&page_reporting_mutex);
+}
+EXPORT_SYMBOL_GPL(page_reporting_shutdown);
+
+int page_reporting_startup(struct page_reporting_dev_info *phdev)
+{
+	struct zone *zone;
+	int err = 0;
+
+	/* No point in enabling this if it cannot handle any pages */
+	if (!phdev->capacity)
+		return -EINVAL;
+
+	mutex_lock(&page_reporting_mutex);
+
+	/* nothing to do if already in use */
+	if (rcu_access_pointer(ph_dev_info)) {
+		err = -EBUSY;
+		goto err_out;
+	}
+
+	boundary = kcalloc(MAX_ORDER - PAGE_REPORTING_MIN_ORDER,
+			   sizeof(struct list_head *) * MIGRATE_TYPES,
+			   GFP_KERNEL);
+	if (!boundary) {
+		err = -ENOMEM;
+		goto err_out;
+	}
+
+	/* allocate scatterlist to store pages being reported on */
+	phdev->sg = kcalloc(phdev->capacity, sizeof(*phdev->sg), GFP_KERNEL);
+	if (!phdev->sg) {
+		err = -ENOMEM;
+
+		kfree(boundary);
+		boundary = NULL;
+
+		goto err_out;
+	}
+
+
+	/* initialize refcnt and work structures */
+	atomic_set(&phdev->refcnt, 0);
+	INIT_DELAYED_WORK(&phdev->work, &page_reporting_process);
+
+	/* assign device, and begin initial flush of populated zones */
+	rcu_assign_pointer(ph_dev_info, phdev);
+	for_each_populated_zone(zone) {
+		spin_lock_irq(&zone->lock);
+		__page_reporting_request(zone);
+		spin_unlock_irq(&zone->lock);
+	}
+
+	/* enable page reporting notification */
+	static_branch_enable(&page_reporting_notify_enabled);
+err_out:
+	mutex_unlock(&page_reporting_mutex);
+
+	return err;
+}
+EXPORT_SYMBOL_GPL(page_reporting_startup);


^ permalink raw reply related	[flat|nested] 82+ messages in thread

* [PATCH v9 7/8] virtio-balloon: Pull page poisoning config out of free page hinting
  2019-09-07 17:25 [PATCH v9 0/8] stg mail -e --version=v9 \ Alexander Duyck
                   ` (5 preceding siblings ...)
  2019-09-07 17:25 ` [PATCH v9 6/8] mm: Introduce Reported pages Alexander Duyck
@ 2019-09-07 17:26 ` Alexander Duyck
  2019-09-09  8:59   ` David Hildenbrand
  2019-09-07 17:26 ` [PATCH v9 8/8] virtio-balloon: Add support for providing unused page reports to host Alexander Duyck
                   ` (2 subsequent siblings)
  9 siblings, 1 reply; 82+ messages in thread
From: Alexander Duyck @ 2019-09-07 17:26 UTC (permalink / raw)
  To: virtio-dev, kvm, mst, catalin.marinas, david, dave.hansen,
	linux-kernel, willy, mhocko, linux-mm, akpm, will,
	linux-arm-kernel, osalvador
  Cc: yang.zhang.wz, pagupta, konrad.wilk, nitesh, riel, lcapitulino,
	wei.w.wang, aarcange, ying.huang, pbonzini, dan.j.williams,
	fengguang.wu, alexander.h.duyck, kirill.shutemov

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

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

In addition we can actually wrap the code in a check for NO_SANITY. If we
don't care what is actually in the page we can just default to 0 and leave
it there.

Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
---
 drivers/virtio/virtio_balloon.c |   22 +++++++++++++++-------
 1 file changed, 15 insertions(+), 7 deletions(-)

diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
index 226fbb995fb0..d2547df7de93 100644
--- a/drivers/virtio/virtio_balloon.c
+++ b/drivers/virtio/virtio_balloon.c
@@ -842,7 +842,6 @@ static int virtio_balloon_register_shrinker(struct virtio_balloon *vb)
 static int virtballoon_probe(struct virtio_device *vdev)
 {
 	struct virtio_balloon *vb;
-	__u32 poison_val;
 	int err;
 
 	if (!vdev->config->get) {
@@ -909,11 +908,18 @@ static int virtballoon_probe(struct virtio_device *vdev)
 						  VIRTIO_BALLOON_CMD_ID_STOP);
 		spin_lock_init(&vb->free_page_list_lock);
 		INIT_LIST_HEAD(&vb->free_page_list);
-		if (virtio_has_feature(vdev, VIRTIO_BALLOON_F_PAGE_POISON)) {
-			memset(&poison_val, PAGE_POISON, sizeof(poison_val));
-			virtio_cwrite(vb->vdev, struct virtio_balloon_config,
-				      poison_val, &poison_val);
-		}
+	}
+	if (virtio_has_feature(vdev, VIRTIO_BALLOON_F_PAGE_POISON)) {
+		__u32 poison_val;
+
+		/*
+		 * Let hypervisor know that we are expecting a specific
+		 * value to be written back in unused pages.
+		 */
+		memset(&poison_val, PAGE_POISON, sizeof(poison_val));
+
+		virtio_cwrite(vb->vdev, struct virtio_balloon_config,
+			      poison_val, &poison_val);
 	}
 	/*
 	 * We continue to use VIRTIO_BALLOON_F_DEFLATE_ON_OOM to decide if a
@@ -1014,7 +1020,9 @@ static int virtballoon_restore(struct virtio_device *vdev)
 
 static int virtballoon_validate(struct virtio_device *vdev)
 {
-	if (!page_poisoning_enabled())
+	/* Notify host if we care about poison value */
+	if (IS_ENABLED(CONFIG_PAGE_POISONING_NO_SANITY) ||
+	    !page_poisoning_enabled())
 		__virtio_clear_bit(vdev, VIRTIO_BALLOON_F_PAGE_POISON);
 
 	__virtio_clear_bit(vdev, VIRTIO_F_IOMMU_PLATFORM);


^ permalink raw reply related	[flat|nested] 82+ messages in thread

* [PATCH v9 8/8] virtio-balloon: Add support for providing unused page reports to host
  2019-09-07 17:25 [PATCH v9 0/8] stg mail -e --version=v9 \ Alexander Duyck
                   ` (6 preceding siblings ...)
  2019-09-07 17:26 ` [PATCH v9 7/8] virtio-balloon: Pull page poisoning config out of free page hinting Alexander Duyck
@ 2019-09-07 17:26 ` Alexander Duyck
  2019-09-07 17:34 ` [PATCH v9 0/8] mm / virtio: Provide support for unused page reporting Alexander Duyck
  2019-09-10 12:42 ` [PATCH v9 0/8] stg mail -e --version=v9 \ Michal Hocko
  9 siblings, 0 replies; 82+ messages in thread
From: Alexander Duyck @ 2019-09-07 17:26 UTC (permalink / raw)
  To: virtio-dev, kvm, mst, catalin.marinas, david, dave.hansen,
	linux-kernel, willy, mhocko, linux-mm, akpm, will,
	linux-arm-kernel, osalvador
  Cc: yang.zhang.wz, pagupta, konrad.wilk, nitesh, riel, lcapitulino,
	wei.w.wang, aarcange, ying.huang, pbonzini, dan.j.williams,
	fengguang.wu, alexander.h.duyck, kirill.shutemov

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

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

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

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


^ permalink raw reply related	[flat|nested] 82+ messages in thread

* Re: [PATCH v9 0/8] mm / virtio: Provide support for unused page reporting
  2019-09-07 17:25 [PATCH v9 0/8] stg mail -e --version=v9 \ Alexander Duyck
                   ` (7 preceding siblings ...)
  2019-09-07 17:26 ` [PATCH v9 8/8] virtio-balloon: Add support for providing unused page reports to host Alexander Duyck
@ 2019-09-07 17:34 ` Alexander Duyck
  2019-09-10 12:42 ` [PATCH v9 0/8] stg mail -e --version=v9 \ Michal Hocko
  9 siblings, 0 replies; 82+ messages in thread
From: Alexander Duyck @ 2019-09-07 17:34 UTC (permalink / raw)
  To: virtio-dev, kvm list, Michael S. Tsirkin, Catalin Marinas,
	David Hildenbrand, Dave Hansen, LKML, Matthew Wilcox,
	Michal Hocko, linux-mm, Andrew Morton, will, linux-arm-kernel,
	Oscar Salvador
  Cc: Yang Zhang, Pankaj Gupta, Konrad Rzeszutek Wilk,
	Nitesh Narayan Lal, Rik van Riel, lcapitulino, Wang, Wei W,
	Andrea Arcangeli, ying.huang, Paolo Bonzini, Dan Williams,
	Fengguang Wu, Alexander Duyck, Kirill A. Shutemov

Sorry about that. Looks like I fat fingered things and copied the
command line into the cover page. I corrected the subject here, and
pulled the command line out of the message below.

- Alex

On Sat, Sep 7, 2019 at 10:25 AM Alexander Duyck
<alexander.duyck@gmail.com> wrote:
> This series provides an asynchronous means of reporting to a hypervisor
> that a guest page is no longer in use and can have the data associated
> with it dropped. To do this I have implemented functionality that allows
> for what I am referring to as unused page reporting
>
> The functionality for this is fairly simple. When enabled it will allocate
> statistics to track the number of reported pages in a given free area.
> When the number of free pages exceeds this value plus a high water value,
> currently 32, it will begin performing page reporting which consists of
> pulling pages off of free list and placing them into a scatter list. The
> scatterlist is then given to the page reporting device and it will perform
> the required action to make the pages "reported", in the case of
> virtio-balloon this results in the pages being madvised as MADV_DONTNEED
> and as such they are forced out of the guest. After this they are placed
> back on the free list, and an additional bit is added if they are not
> merged indicating that they are a reported buddy page instead of a
> standard buddy page. The cycle then repeats with additional non-reported
> pages being pulled until the free areas all consist of reported pages.
>
> I am leaving a number of things hard-coded such as limiting the lowest
> order processed to PAGEBLOCK_ORDER, and have left it up to the guest to
> determine what the limit is on how many pages it wants to allocate to
> process the hints. The upper limit for this is based on the size of the
> queue used to store the scattergather list.
>
> My primary testing has just been to verify the memory is being freed after
> allocation by running memhog 40g on a 40g guest and watching the total
> free memory via /proc/meminfo on the host. With this I have verified most
> of the memory is freed after each iteration. As far as performance I have
> been mainly focusing on the will-it-scale/page_fault1 test running with
> 16 vcpus. I have modified it to use Transparent Huge Pages. With this I
> see almost no difference, -0.08%, with the patches applied and the feature
> disabled. I see a regression of -0.86% with the feature enabled, but the
> madvise disabled in the hypervisor due to a device being assigned. With
> the feature fully enabled I see a regression of -3.27% versus the baseline
> without these patches applied. In my testing I found that most of the
> overhead was due to the page zeroing that comes as a result of the pages
> having to be faulted back into the guest.
>
> One side effect of these patches is that the guest becomes much more
> resilient in terms of NUMA locality. With the pages being freed and then
> reallocated when used it allows for the pages to be much closer to the
> active thread, and as a result there can be situations where this patch
> set will out-perform the stock kernel when the guest memory is not local
> to the guest vCPUs. To avoid that in my testing I set the affinity of all
> the vCPUs and QEMU instance to the same node.
>
> I have not included the QEMU patches with this set as they haven't really
> changed in the last several revisions. If needed they can be located with
> the v8 patchset.
>
> Changes from the RFC:
> https://lore.kernel.org/lkml/20190530215223.13974.22445.stgit@localhost.localdomain/
> Moved aeration requested flag out of aerator and into zone->flags.
> Moved boundary out of free_area and into local variables for aeration.
> Moved aeration cycle out of interrupt and into workqueue.
> Left nr_free as total pages instead of splitting it between raw and aerated.
> Combined size and physical address values in virtio ring into one 64b value.
>
> Changes from v1:
> https://lore.kernel.org/lkml/20190619222922.1231.27432.stgit@localhost.localdomain/
> Dropped "waste page treatment" in favor of "page hinting"
> Renamed files and functions from "aeration" to "page_hinting"
> Moved from page->lru list to scatterlist
> Replaced wait on refcnt in shutdown with RCU and cancel_delayed_work_sync
> Virtio now uses scatterlist directly instead of intermediate array
> Moved stats out of free_area, now in separate area and pointed to from zone
> Merged patch 5 into patch 4 to improve review-ability
> Updated various code comments throughout
>
> Changes from v2:
> https://lore.kernel.org/lkml/20190724165158.6685.87228.stgit@localhost.localdomain/
> Dropped "page hinting" in favor of "page reporting"
> Renamed files from "hinting" to "reporting"
> Replaced "Hinted" page type with "Reported" page flag
> Added support for page poisoning while hinting is active
> Add QEMU patch that implements PAGE_POISON feature
>
> Changes from v3:
> https://lore.kernel.org/lkml/20190801222158.22190.96964.stgit@localhost.localdomain/
> Added mutex lock around page reporting startup and shutdown
> Fixed reference to "page aeration" in patch 2
> Split page reporting function bit out into separate QEMU patch
> Limited capacity of scatterlist to vq size - 1 instead of vq size
> Added exception handling for case of virtio descriptor allocation failure
>
> Changes from v4:
> https://lore.kernel.org/lkml/20190807224037.6891.53512.stgit@localhost.localdomain/
> Replaced spin_(un)lock with spin_(un)lock_irq in page_reporting_cycle()
> Dropped if/continue for ternary operator in page_reporting_process()
> Added checks for isolate and cma types to for_each_reporting_migratetype_order
> Added virtio-dev, Michal Hocko, and Oscar Salvador to to:/cc:
> Rebased on latest linux-next and QEMU git trees
>
> Changes from v5:
> https://lore.kernel.org/lkml/20190812213158.22097.30576.stgit@localhost.localdomain/
> Replaced spin_(un)lock with spin_(un)lock_irq in page_reporting_startup()
> Updated shuffle code to use "shuffle_pick_tail" and updated patch description
> Dropped storage of order and migratettype while page is being reported
> Used get_pfnblock_migratetype to determine migratetype of page
> Renamed put_reported_page to free_reported_page, added order as argument
> Dropped check for CMA type as I believe we should be reporting those
> Added code to allow moving of reported pages into and out of isolation
> Defined page reporting order as minimum of Huge Page size vs MAX_ORDER - 1
> Cleaned up use of static branch usage for page_reporting_notify_enabled
>
> Changes from v6:
> https://lore.kernel.org/lkml/20190821145806.20926.22448.stgit@localhost.localdomain/
> Rebased on linux-next for 20190903
> Added jump label to __page_reporting_request so we release RCU read lock
> Removed "- 1" from capacity limit based on virtio ring
> Added code to verify capacity is non-zero or return error on startup
>
> Changes from v7:
> https://lore.kernel.org/lkml/20190904150920.13848.32271.stgit@localhost.localdomain/
> Updated poison fixes to clear flag if "nosanity" is enabled in kernel config
> Split shuffle per-cpu optimization into separate patch
> Moved check for !phdev->capacity into reporting patch where it belongs
> Added Reviewed-by tags received for v7
>
> Changes from v8:
> https://lore.kernel.org/lkml/20190906145213.32552.30160.stgit@localhost.localdomain/
> Added patch that moves HPAGE_SIZE definition for ARM64 to match other archs
> Switch back to using pageblock_order instead of HUGETLB_ORDER and MAX_ORDER - 1
> Boundary allocation now dynamic to support HUGETLB_PAGE_SIZE_VARIABLE option
> Made use of existing code/functions to reduce size of move_to_boundary function
> Dropped unused zone pointer from add_to/del_from_boundary functions
> Added additional possible mm and arm64 people as reviewers to Cc
> Added Reviewed-by tags received for v8
> Fixed missing parameter in kerneldoc
>
> ---
>
> Alexander Duyck (8):
>       mm: Add per-cpu logic to page shuffling
>       mm: Adjust shuffle code to allow for future coalescing
>       mm: Move set/get_pcppage_migratetype to mmzone.h
>       mm: Use zone and order instead of free area in free_list manipulators
>       arm64: Move hugetlb related definitions out of pgtable.h to page-defs.h
>       mm: Introduce Reported pages
>       virtio-balloon: Pull page poisoning config out of free page hinting
>       virtio-balloon: Add support for providing unused page reports to host
>
>
>  arch/arm64/include/asm/page-def.h   |    9 +
>  arch/arm64/include/asm/pgtable.h    |    9 -
>  drivers/virtio/Kconfig              |    1
>  drivers/virtio/virtio_balloon.c     |   87 ++++++++-
>  include/linux/mmzone.h              |  124 ++++++++----
>  include/linux/page-flags.h          |   11 +
>  include/linux/page_reporting.h      |  178 +++++++++++++++++
>  include/uapi/linux/virtio_balloon.h |    1
>  mm/Kconfig                          |    5
>  mm/Makefile                         |    1
>  mm/internal.h                       |   18 ++
>  mm/memory_hotplug.c                 |    1
>  mm/page_alloc.c                     |  217 +++++++++++++++------
>  mm/page_reporting.c                 |  358 +++++++++++++++++++++++++++++++++++
>  mm/shuffle.c                        |   40 ++--
>  mm/shuffle.h                        |   12 +
>  16 files changed, 931 insertions(+), 141 deletions(-)
>  create mode 100644 include/linux/page_reporting.h
>  create mode 100644 mm/page_reporting.c
>
> --

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: [PATCH v9 1/8] mm: Add per-cpu logic to page shuffling
  2019-09-07 17:25 ` [PATCH v9 1/8] mm: Add per-cpu logic to page shuffling Alexander Duyck
@ 2019-09-09  8:14   ` David Hildenbrand
  2019-09-09 15:11     ` Alexander Duyck
  2019-09-10 22:11     ` Alexander Duyck
  2019-09-09  9:07   ` Kirill A. Shutemov
  1 sibling, 2 replies; 82+ messages in thread
From: David Hildenbrand @ 2019-09-09  8:14 UTC (permalink / raw)
  To: Alexander Duyck, virtio-dev, kvm, mst, catalin.marinas,
	dave.hansen, linux-kernel, willy, mhocko, linux-mm, akpm, will,
	linux-arm-kernel, osalvador
  Cc: yang.zhang.wz, pagupta, konrad.wilk, nitesh, riel, lcapitulino,
	wei.w.wang, aarcange, ying.huang, pbonzini, dan.j.williams,
	fengguang.wu, alexander.h.duyck, kirill.shutemov

On 07.09.19 19:25, Alexander Duyck wrote:
> From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> 
> Change the logic used to generate randomness in the suffle path so that we
> can avoid cache line bouncing. The previous logic was sharing the offset
> and entropy word between all CPUs. As such this can result in cache line
> bouncing and will ultimately hurt performance when enabled.

So, usually we perform such changes if there is real evidence. Do you
have any such performance numbers to back your claims?

> 
> To resolve this I have moved to a per-cpu logic for maintaining a unsigned
> long containing some amount of bits, and an offset value for which bit we
> can use for entropy with each call.
> 
> Reviewed-by: Dan Williams <dan.j.williams@intel.com>
> Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> ---
>  mm/shuffle.c |   33 +++++++++++++++++++++++----------
>  1 file changed, 23 insertions(+), 10 deletions(-)
> 
> diff --git a/mm/shuffle.c b/mm/shuffle.c
> index 3ce12481b1dc..9ba542ecf335 100644
> --- a/mm/shuffle.c
> +++ b/mm/shuffle.c
> @@ -183,25 +183,38 @@ void __meminit __shuffle_free_memory(pg_data_t *pgdat)
>  		shuffle_zone(z);
>  }
>  
> +struct batched_bit_entropy {
> +	unsigned long entropy_bool;
> +	int position;
> +};
> +
> +static DEFINE_PER_CPU(struct batched_bit_entropy, batched_entropy_bool);
> +
>  void add_to_free_area_random(struct page *page, struct free_area *area,
>  		int migratetype)
>  {
> -	static u64 rand;
> -	static u8 rand_bits;
> +	struct batched_bit_entropy *batch;
> +	unsigned long entropy;
> +	int position;
>  
>  	/*
> -	 * The lack of locking is deliberate. If 2 threads race to
> -	 * update the rand state it just adds to the entropy.
> +	 * We shouldn't need to disable IRQs as the only caller is
> +	 * __free_one_page and it should only be called with the zone lock
> +	 * held and either from IRQ context or with local IRQs disabled.
>  	 */
> -	if (rand_bits == 0) {
> -		rand_bits = 64;
> -		rand = get_random_u64();
> +	batch = raw_cpu_ptr(&batched_entropy_bool);
> +	position = batch->position;
> +
> +	if (--position < 0) {
> +		batch->entropy_bool = get_random_long();
> +		position = BITS_PER_LONG - 1;
>  	}
>  
> -	if (rand & 1)
> +	batch->position = position;
> +	entropy = batch->entropy_bool;
> +
> +	if (1ul & (entropy >> position))
>  		add_to_free_area(page, area, migratetype);
>  	else
>  		add_to_free_area_tail(page, area, migratetype);
> -	rand_bits--;
> -	rand >>= 1;
>  }
> 
> 


-- 

Thanks,

David / dhildenb

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: [PATCH v9 2/8] mm: Adjust shuffle code to allow for future coalescing
  2019-09-07 17:25 ` [PATCH v9 2/8] mm: Adjust shuffle code to allow for future coalescing Alexander Duyck
@ 2019-09-09  8:19   ` David Hildenbrand
  2019-09-09  9:47   ` Kirill A. Shutemov
  2019-09-10 12:20   ` Michal Hocko
  2 siblings, 0 replies; 82+ messages in thread
From: David Hildenbrand @ 2019-09-09  8:19 UTC (permalink / raw)
  To: Alexander Duyck, virtio-dev, kvm, mst, catalin.marinas,
	dave.hansen, linux-kernel, willy, mhocko, linux-mm, akpm, will,
	linux-arm-kernel, osalvador
  Cc: yang.zhang.wz, pagupta, konrad.wilk, nitesh, riel, lcapitulino,
	wei.w.wang, aarcange, ying.huang, pbonzini, dan.j.williams,
	fengguang.wu, alexander.h.duyck, kirill.shutemov

On 07.09.19 19:25, Alexander Duyck wrote:
> From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> 
> Move the head/tail adding logic out of the shuffle code and into the
> __free_one_page function since ultimately that is where it is really
> needed anyway. By doing this we should be able to reduce the overhead
> and can consolidate all of the list addition bits in one spot.
> 
> Reviewed-by: Dan Williams <dan.j.williams@intel.com>
> Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> ---
>  include/linux/mmzone.h |   12 --------
>  mm/page_alloc.c        |   70 +++++++++++++++++++++++++++---------------------
>  mm/shuffle.c           |    9 +-----
>  mm/shuffle.h           |   12 ++++++++
>  4 files changed, 53 insertions(+), 50 deletions(-)
> 
> diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
> index bda20282746b..125f300981c6 100644
> --- a/include/linux/mmzone.h
> +++ b/include/linux/mmzone.h
> @@ -116,18 +116,6 @@ static inline void add_to_free_area_tail(struct page *page, struct free_area *ar
>  	area->nr_free++;
>  }
>  
> -#ifdef CONFIG_SHUFFLE_PAGE_ALLOCATOR
> -/* Used to preserve page allocation order entropy */
> -void add_to_free_area_random(struct page *page, struct free_area *area,
> -		int migratetype);
> -#else
> -static inline void add_to_free_area_random(struct page *page,
> -		struct free_area *area, int migratetype)
> -{
> -	add_to_free_area(page, area, migratetype);
> -}
> -#endif
> -
>  /* Used for pages which are on another list */
>  static inline void move_to_free_area(struct page *page, struct free_area *area,
>  			     int migratetype)
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index c5d62f1c2851..4e4356ba66c7 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -878,6 +878,36 @@ static inline struct capture_control *task_capc(struct zone *zone)
>  #endif /* CONFIG_COMPACTION */
>  
>  /*
> + * If this is not the largest possible page, check if the buddy
> + * of the next-highest order is free. If it is, it's possible
> + * that pages are being freed that will coalesce soon. In case,
> + * that is happening, add the free page to the tail of the list
> + * so it's less likely to be used soon and more likely to be merged
> + * as a higher order page
> + */
> +static inline bool
> +buddy_merge_likely(unsigned long pfn, unsigned long buddy_pfn,
> +		   struct page *page, unsigned int order)
> +{
> +	struct page *higher_page, *higher_buddy;
> +	unsigned long combined_pfn;
> +
> +	if (order >= MAX_ORDER - 2)
> +		return false;
> +
> +	if (!pfn_valid_within(buddy_pfn))
> +		return false;
> +
> +	combined_pfn = buddy_pfn & pfn;
> +	higher_page = page + (combined_pfn - pfn);
> +	buddy_pfn = __find_buddy_pfn(combined_pfn, order + 1);
> +	higher_buddy = higher_page + (buddy_pfn - combined_pfn);
> +
> +	return pfn_valid_within(buddy_pfn) &&
> +	       page_is_buddy(higher_page, higher_buddy, order + 1);
> +}
> +
> +/*
>   * Freeing function for a buddy system allocator.
>   *
>   * The concept of a buddy system is to maintain direct-mapped table
> @@ -906,11 +936,12 @@ static inline void __free_one_page(struct page *page,
>  		struct zone *zone, unsigned int order,
>  		int migratetype)
>  {
> -	unsigned long combined_pfn;
> +	struct capture_control *capc = task_capc(zone);
>  	unsigned long uninitialized_var(buddy_pfn);
> -	struct page *buddy;
> +	unsigned long combined_pfn;
> +	struct free_area *area;
>  	unsigned int max_order;
> -	struct capture_control *capc = task_capc(zone);
> +	struct page *buddy;
>  
>  	max_order = min_t(unsigned int, MAX_ORDER, pageblock_order + 1);
>  
> @@ -979,35 +1010,12 @@ static inline void __free_one_page(struct page *page,
>  done_merging:
>  	set_page_order(page, order);
>  
> -	/*
> -	 * If this is not the largest possible page, check if the buddy
> -	 * of the next-highest order is free. If it is, it's possible
> -	 * that pages are being freed that will coalesce soon. In case,
> -	 * that is happening, add the free page to the tail of the list
> -	 * so it's less likely to be used soon and more likely to be merged
> -	 * as a higher order page
> -	 */
> -	if ((order < MAX_ORDER-2) && pfn_valid_within(buddy_pfn)
> -			&& !is_shuffle_order(order)) {
> -		struct page *higher_page, *higher_buddy;
> -		combined_pfn = buddy_pfn & pfn;
> -		higher_page = page + (combined_pfn - pfn);
> -		buddy_pfn = __find_buddy_pfn(combined_pfn, order + 1);
> -		higher_buddy = higher_page + (buddy_pfn - combined_pfn);
> -		if (pfn_valid_within(buddy_pfn) &&
> -		    page_is_buddy(higher_page, higher_buddy, order + 1)) {
> -			add_to_free_area_tail(page, &zone->free_area[order],
> -					      migratetype);
> -			return;
> -		}
> -	}
> -
> -	if (is_shuffle_order(order))
> -		add_to_free_area_random(page, &zone->free_area[order],
> -				migratetype);
> +	area = &zone->free_area[order];
> +	if (is_shuffle_order(order) ? shuffle_pick_tail() :
> +	    buddy_merge_likely(pfn, buddy_pfn, page, order))
> +		add_to_free_area_tail(page, area, migratetype);
>  	else
> -		add_to_free_area(page, &zone->free_area[order], migratetype);
> -
> +		add_to_free_area(page, area, migratetype);
>  }
>  
>  /*
> diff --git a/mm/shuffle.c b/mm/shuffle.c
> index 9ba542ecf335..345cb4347455 100644
> --- a/mm/shuffle.c
> +++ b/mm/shuffle.c
> @@ -4,7 +4,6 @@
>  #include <linux/mm.h>
>  #include <linux/init.h>
>  #include <linux/mmzone.h>
> -#include <linux/random.h>
>  #include <linux/moduleparam.h>
>  #include "internal.h"
>  #include "shuffle.h"
> @@ -190,8 +189,7 @@ struct batched_bit_entropy {
>  
>  static DEFINE_PER_CPU(struct batched_bit_entropy, batched_entropy_bool);
>  
> -void add_to_free_area_random(struct page *page, struct free_area *area,
> -		int migratetype)
> +bool __shuffle_pick_tail(void)
>  {
>  	struct batched_bit_entropy *batch;
>  	unsigned long entropy;
> @@ -213,8 +211,5 @@ void add_to_free_area_random(struct page *page, struct free_area *area,
>  	batch->position = position;
>  	entropy = batch->entropy_bool;
>  
> -	if (1ul & (entropy >> position))
> -		add_to_free_area(page, area, migratetype);
> -	else
> -		add_to_free_area_tail(page, area, migratetype);
> +	return 1ul & (entropy >> position);
>  }
> diff --git a/mm/shuffle.h b/mm/shuffle.h
> index 777a257a0d2f..0723eb97f22f 100644
> --- a/mm/shuffle.h
> +++ b/mm/shuffle.h
> @@ -3,6 +3,7 @@
>  #ifndef _MM_SHUFFLE_H
>  #define _MM_SHUFFLE_H
>  #include <linux/jump_label.h>
> +#include <linux/random.h>
>  
>  /*
>   * SHUFFLE_ENABLE is called from the command line enabling path, or by
> @@ -22,6 +23,7 @@ enum mm_shuffle_ctl {
>  DECLARE_STATIC_KEY_FALSE(page_alloc_shuffle_key);
>  extern void page_alloc_shuffle(enum mm_shuffle_ctl ctl);
>  extern void __shuffle_free_memory(pg_data_t *pgdat);
> +extern bool __shuffle_pick_tail(void);
>  static inline void shuffle_free_memory(pg_data_t *pgdat)
>  {
>  	if (!static_branch_unlikely(&page_alloc_shuffle_key))
> @@ -43,6 +45,11 @@ static inline bool is_shuffle_order(int order)
>  		return false;
>  	return order >= SHUFFLE_ORDER;
>  }
> +
> +static inline bool shuffle_pick_tail(void)
> +{
> +	return __shuffle_pick_tail();
> +}
>  #else
>  static inline void shuffle_free_memory(pg_data_t *pgdat)
>  {
> @@ -60,5 +67,10 @@ static inline bool is_shuffle_order(int order)
>  {
>  	return false;
>  }
> +
> +static inline bool shuffle_pick_tail(void)
> +{
> +	return false;
> +}
>  #endif
>  #endif /* _MM_SHUFFLE_H */
> 
> 

Acked-by: David Hildenbrand <david@redhat.com>

-- 

Thanks,

David / dhildenb

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: [PATCH v9 3/8] mm: Move set/get_pcppage_migratetype to mmzone.h
  2019-09-07 17:25 ` [PATCH v9 3/8] mm: Move set/get_pcppage_migratetype to mmzone.h Alexander Duyck
@ 2019-09-09  8:22   ` David Hildenbrand
  2019-09-09  9:56   ` Kirill A. Shutemov
  2019-09-10 12:23   ` Michal Hocko
  2 siblings, 0 replies; 82+ messages in thread
From: David Hildenbrand @ 2019-09-09  8:22 UTC (permalink / raw)
  To: Alexander Duyck, virtio-dev, kvm, mst, catalin.marinas,
	dave.hansen, linux-kernel, willy, mhocko, linux-mm, akpm, will,
	linux-arm-kernel, osalvador
  Cc: yang.zhang.wz, pagupta, konrad.wilk, nitesh, riel, lcapitulino,
	wei.w.wang, aarcange, ying.huang, pbonzini, dan.j.williams,
	fengguang.wu, alexander.h.duyck, kirill.shutemov

On 07.09.19 19:25, Alexander Duyck wrote:
> From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> 
> In order to support page reporting it will be necessary to store and
> retrieve the migratetype of a page. To enable that I am moving the set and
> get operations for pcppage_migratetype into the mm/internal.h header so
> that they can be used outside of the page_alloc.c file.
> 
> Reviewed-by: Dan Williams <dan.j.williams@intel.com>
> Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> ---
>  mm/internal.h   |   18 ++++++++++++++++++
>  mm/page_alloc.c |   18 ------------------
>  2 files changed, 18 insertions(+), 18 deletions(-)
> 
> diff --git a/mm/internal.h b/mm/internal.h
> index 0d5f720c75ab..e4a1a57bbd40 100644
> --- a/mm/internal.h
> +++ b/mm/internal.h
> @@ -549,6 +549,24 @@ static inline bool is_migrate_highatomic_page(struct page *page)
>  	return get_pageblock_migratetype(page) == MIGRATE_HIGHATOMIC;
>  }
>  
> +/*
> + * A cached value of the page's pageblock's migratetype, used when the page is
> + * put on a pcplist. Used to avoid the pageblock migratetype lookup when
> + * freeing from pcplists in most cases, at the cost of possibly becoming stale.
> + * Also the migratetype set in the page does not necessarily match the pcplist
> + * index, e.g. page might have MIGRATE_CMA set but be on a pcplist with any
> + * other index - this ensures that it will be put on the correct CMA freelist.
> + */
> +static inline int get_pcppage_migratetype(struct page *page)
> +{
> +	return page->index;
> +}
> +
> +static inline void set_pcppage_migratetype(struct page *page, int migratetype)
> +{
> +	page->index = migratetype;
> +}
> +
>  void setup_zone_pageset(struct zone *zone);
>  extern struct page *alloc_new_node_page(struct page *page, unsigned long node);
>  #endif	/* __MM_INTERNAL_H */
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 4e4356ba66c7..a791f2baeeeb 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -185,24 +185,6 @@ static int __init early_init_on_free(char *buf)
>  }
>  early_param("init_on_free", early_init_on_free);
>  
> -/*
> - * A cached value of the page's pageblock's migratetype, used when the page is
> - * put on a pcplist. Used to avoid the pageblock migratetype lookup when
> - * freeing from pcplists in most cases, at the cost of possibly becoming stale.
> - * Also the migratetype set in the page does not necessarily match the pcplist
> - * index, e.g. page might have MIGRATE_CMA set but be on a pcplist with any
> - * other index - this ensures that it will be put on the correct CMA freelist.
> - */
> -static inline int get_pcppage_migratetype(struct page *page)
> -{
> -	return page->index;
> -}
> -
> -static inline void set_pcppage_migratetype(struct page *page, int migratetype)
> -{
> -	page->index = migratetype;
> -}
> -
>  #ifdef CONFIG_PM_SLEEP
>  /*
>   * The following functions are used by the suspend/hibernate code to temporarily
> 
> 

Still have to understand in detail how this will be used, but the change
certainly looks ok :)

Acked-by: David Hildenbrand <david@redhat.com>

-- 

Thanks,

David / dhildenb

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: [PATCH v9 5/8] arm64: Move hugetlb related definitions out of pgtable.h to page-defs.h
  2019-09-07 17:25 ` [PATCH v9 5/8] arm64: Move hugetlb related definitions out of pgtable.h to page-defs.h Alexander Duyck
@ 2019-09-09  8:52   ` David Hildenbrand
  2019-09-09 15:27     ` Alexander Duyck
  2019-09-17 17:48   ` Will Deacon
  1 sibling, 1 reply; 82+ messages in thread
From: David Hildenbrand @ 2019-09-09  8:52 UTC (permalink / raw)
  To: Alexander Duyck, virtio-dev, kvm, mst, catalin.marinas,
	dave.hansen, linux-kernel, willy, mhocko, linux-mm, akpm, will,
	linux-arm-kernel, osalvador
  Cc: yang.zhang.wz, pagupta, konrad.wilk, nitesh, riel, lcapitulino,
	wei.w.wang, aarcange, ying.huang, pbonzini, dan.j.williams,
	fengguang.wu, alexander.h.duyck, kirill.shutemov

On 07.09.19 19:25, Alexander Duyck wrote:
> From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> 
> Move the static definition for things such as HUGETLB_PAGE_ORDER out of
> asm/pgtable.h and place it in page-defs.h. By doing this the includes
> become much easier to deal with as currently arm64 is the only architecture
> that didn't include this definition in the asm/page.h file or a file
> included by it.
> 
> It also makes logical sense as PAGE_SHIFT was already defined in
> page-defs.h so now we also have HPAGE_SHIFT defined there as well.
> 
> Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> ---
>  arch/arm64/include/asm/page-def.h |    9 +++++++++
>  arch/arm64/include/asm/pgtable.h  |    9 ---------
>  2 files changed, 9 insertions(+), 9 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/page-def.h b/arch/arm64/include/asm/page-def.h
> index f99d48ecbeef..1c5b079e2482 100644
> --- a/arch/arm64/include/asm/page-def.h
> +++ b/arch/arm64/include/asm/page-def.h
> @@ -20,4 +20,13 @@
>  #define CONT_SIZE		(_AC(1, UL) << (CONT_SHIFT + PAGE_SHIFT))
>  #define CONT_MASK		(~(CONT_SIZE-1))
>  
> +/*
> + * Hugetlb definitions.
> + */
> +#define HUGE_MAX_HSTATE		4
> +#define HPAGE_SHIFT		PMD_SHIFT
> +#define HPAGE_SIZE		(_AC(1, UL) << HPAGE_SHIFT)
> +#define HPAGE_MASK		(~(HPAGE_SIZE - 1))
> +#define HUGETLB_PAGE_ORDER	(HPAGE_SHIFT - PAGE_SHIFT)
> +

I wonder if you should initially limit "config PAGE_REPORTING" to x86
only and unlock it for the other targets once we actually test it there.
Or did you test PAGE_REPORTING on other architectures as well?

-- 

Thanks,

David / dhildenb

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: [PATCH v9 7/8] virtio-balloon: Pull page poisoning config out of free page hinting
  2019-09-07 17:26 ` [PATCH v9 7/8] virtio-balloon: Pull page poisoning config out of free page hinting Alexander Duyck
@ 2019-09-09  8:59   ` David Hildenbrand
  2019-09-09 15:31     ` Alexander Duyck
  0 siblings, 1 reply; 82+ messages in thread
From: David Hildenbrand @ 2019-09-09  8:59 UTC (permalink / raw)
  To: Alexander Duyck, virtio-dev, kvm, mst, catalin.marinas,
	dave.hansen, linux-kernel, willy, mhocko, linux-mm, akpm, will,
	linux-arm-kernel, osalvador
  Cc: yang.zhang.wz, pagupta, konrad.wilk, nitesh, riel, lcapitulino,
	wei.w.wang, aarcange, ying.huang, pbonzini, dan.j.williams,
	fengguang.wu, alexander.h.duyck, kirill.shutemov

On 07.09.19 19:26, Alexander Duyck wrote:
> From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> 
> Currently the page poisoning setting wasn't being enabled unless free page
> hinting was enabled. However we will need the page poisoning tracking logic
> as well for unused page reporting. As such pull it out and make it a
> separate bit of config in the probe function.
> 
> In addition we can actually wrap the code in a check for NO_SANITY. If we
> don't care what is actually in the page we can just default to 0 and leave
> it there.
> 
> Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> ---
>  drivers/virtio/virtio_balloon.c |   22 +++++++++++++++-------
>  1 file changed, 15 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
> index 226fbb995fb0..d2547df7de93 100644
> --- a/drivers/virtio/virtio_balloon.c
> +++ b/drivers/virtio/virtio_balloon.c
> @@ -842,7 +842,6 @@ static int virtio_balloon_register_shrinker(struct virtio_balloon *vb)
>  static int virtballoon_probe(struct virtio_device *vdev)
>  {
>  	struct virtio_balloon *vb;
> -	__u32 poison_val;
>  	int err;
>  
>  	if (!vdev->config->get) {
> @@ -909,11 +908,18 @@ static int virtballoon_probe(struct virtio_device *vdev)
>  						  VIRTIO_BALLOON_CMD_ID_STOP);
>  		spin_lock_init(&vb->free_page_list_lock);
>  		INIT_LIST_HEAD(&vb->free_page_list);
> -		if (virtio_has_feature(vdev, VIRTIO_BALLOON_F_PAGE_POISON)) {
> -			memset(&poison_val, PAGE_POISON, sizeof(poison_val));
> -			virtio_cwrite(vb->vdev, struct virtio_balloon_config,
> -				      poison_val, &poison_val);
> -		}
> +	}
> +	if (virtio_has_feature(vdev, VIRTIO_BALLOON_F_PAGE_POISON)) {
> +		__u32 poison_val;
> +
> +		/*
> +		 * Let hypervisor know that we are expecting a specific
> +		 * value to be written back in unused pages.
> +		 */

"Let the hypervisor know" ... ?

> +		memset(&poison_val, PAGE_POISON, sizeof(poison_val));
> +
> +		virtio_cwrite(vb->vdev, struct virtio_balloon_config,
> +			      poison_val, &poison_val);
>  	}
>  	/*
>  	 * We continue to use VIRTIO_BALLOON_F_DEFLATE_ON_OOM to decide if a
> @@ -1014,7 +1020,9 @@ static int virtballoon_restore(struct virtio_device *vdev)
>  
>  static int virtballoon_validate(struct virtio_device *vdev)
>  {
> -	if (!page_poisoning_enabled())
> +	/* Notify host if we care about poison value */

"Tell the host whether we care about poisoned pages." ?

> +	if (IS_ENABLED(CONFIG_PAGE_POISONING_NO_SANITY) ||
> +	    !page_poisoning_enabled())
>  		__virtio_clear_bit(vdev, VIRTIO_BALLOON_F_PAGE_POISON);
>  
>  	__virtio_clear_bit(vdev, VIRTIO_F_IOMMU_PLATFORM);
> 

Reviewed-by: David Hildenbrand <david@redhat.com>

-- 

Thanks,

David / dhildenb

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: [PATCH v9 1/8] mm: Add per-cpu logic to page shuffling
  2019-09-07 17:25 ` [PATCH v9 1/8] mm: Add per-cpu logic to page shuffling Alexander Duyck
  2019-09-09  8:14   ` David Hildenbrand
@ 2019-09-09  9:07   ` Kirill A. Shutemov
  2019-09-09 15:12     ` Alexander Duyck
  1 sibling, 1 reply; 82+ messages in thread
From: Kirill A. Shutemov @ 2019-09-09  9:07 UTC (permalink / raw)
  To: Alexander Duyck
  Cc: virtio-dev, kvm, mst, catalin.marinas, david, dave.hansen,
	linux-kernel, willy, mhocko, linux-mm, akpm, will,
	linux-arm-kernel, osalvador, yang.zhang.wz, pagupta, konrad.wilk,
	nitesh, riel, lcapitulino, wei.w.wang, aarcange, ying.huang,
	pbonzini, dan.j.williams, fengguang.wu, alexander.h.duyck,
	kirill.shutemov

On Sat, Sep 07, 2019 at 10:25:12AM -0700, Alexander Duyck wrote:
> From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> 
> Change the logic used to generate randomness in the suffle path so that we

Typo.

> can avoid cache line bouncing. The previous logic was sharing the offset
> and entropy word between all CPUs. As such this can result in cache line
> bouncing and will ultimately hurt performance when enabled.
> 
> To resolve this I have moved to a per-cpu logic for maintaining a unsigned
> long containing some amount of bits, and an offset value for which bit we
> can use for entropy with each call.
> 
> Reviewed-by: Dan Williams <dan.j.williams@intel.com>
> Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> ---
>  mm/shuffle.c |   33 +++++++++++++++++++++++----------
>  1 file changed, 23 insertions(+), 10 deletions(-)
> 
> diff --git a/mm/shuffle.c b/mm/shuffle.c
> index 3ce12481b1dc..9ba542ecf335 100644
> --- a/mm/shuffle.c
> +++ b/mm/shuffle.c
> @@ -183,25 +183,38 @@ void __meminit __shuffle_free_memory(pg_data_t *pgdat)
>  		shuffle_zone(z);
>  }
>  
> +struct batched_bit_entropy {
> +	unsigned long entropy_bool;
> +	int position;
> +};
> +
> +static DEFINE_PER_CPU(struct batched_bit_entropy, batched_entropy_bool);
> +
>  void add_to_free_area_random(struct page *page, struct free_area *area,
>  		int migratetype)
>  {
> -	static u64 rand;
> -	static u8 rand_bits;
> +	struct batched_bit_entropy *batch;
> +	unsigned long entropy;
> +	int position;
>  
>  	/*
> -	 * The lack of locking is deliberate. If 2 threads race to
> -	 * update the rand state it just adds to the entropy.
> +	 * We shouldn't need to disable IRQs as the only caller is
> +	 * __free_one_page and it should only be called with the zone lock
> +	 * held and either from IRQ context or with local IRQs disabled.
>  	 */
> -	if (rand_bits == 0) {
> -		rand_bits = 64;
> -		rand = get_random_u64();
> +	batch = raw_cpu_ptr(&batched_entropy_bool);
> +	position = batch->position;
> +
> +	if (--position < 0) {
> +		batch->entropy_bool = get_random_long();
> +		position = BITS_PER_LONG - 1;
>  	}
>  
> -	if (rand & 1)
> +	batch->position = position;
> +	entropy = batch->entropy_bool;
> +
> +	if (1ul & (entropy >> position))

Maybe something like this would be more readble:

	if (entropy & BIT(position))

>  		add_to_free_area(page, area, migratetype);
>  	else
>  		add_to_free_area_tail(page, area, migratetype);
> -	rand_bits--;
> -	rand >>= 1;
>  }
> 
> 

-- 
 Kirill A. Shutemov

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: [PATCH v9 2/8] mm: Adjust shuffle code to allow for future coalescing
  2019-09-07 17:25 ` [PATCH v9 2/8] mm: Adjust shuffle code to allow for future coalescing Alexander Duyck
  2019-09-09  8:19   ` David Hildenbrand
@ 2019-09-09  9:47   ` Kirill A. Shutemov
  2019-09-09 15:22     ` Alexander Duyck
  2019-09-09 16:43     ` Alexander Duyck
  2019-09-10 12:20   ` Michal Hocko
  2 siblings, 2 replies; 82+ messages in thread
From: Kirill A. Shutemov @ 2019-09-09  9:47 UTC (permalink / raw)
  To: Alexander Duyck
  Cc: virtio-dev, kvm, mst, catalin.marinas, david, dave.hansen,
	linux-kernel, willy, mhocko, linux-mm, akpm, will,
	linux-arm-kernel, osalvador, yang.zhang.wz, pagupta, konrad.wilk,
	nitesh, riel, lcapitulino, wei.w.wang, aarcange, ying.huang,
	pbonzini, dan.j.williams, fengguang.wu, alexander.h.duyck,
	kirill.shutemov

On Sat, Sep 07, 2019 at 10:25:20AM -0700, Alexander Duyck wrote:
> From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> 
> Move the head/tail adding logic out of the shuffle code and into the
> __free_one_page function since ultimately that is where it is really
> needed anyway. By doing this we should be able to reduce the overhead
> and can consolidate all of the list addition bits in one spot.
> 
> Reviewed-by: Dan Williams <dan.j.williams@intel.com>
> Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> ---
>  include/linux/mmzone.h |   12 --------
>  mm/page_alloc.c        |   70 +++++++++++++++++++++++++++---------------------
>  mm/shuffle.c           |    9 +-----
>  mm/shuffle.h           |   12 ++++++++
>  4 files changed, 53 insertions(+), 50 deletions(-)
> 
> diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
> index bda20282746b..125f300981c6 100644
> --- a/include/linux/mmzone.h
> +++ b/include/linux/mmzone.h
> @@ -116,18 +116,6 @@ static inline void add_to_free_area_tail(struct page *page, struct free_area *ar
>  	area->nr_free++;
>  }
>  
> -#ifdef CONFIG_SHUFFLE_PAGE_ALLOCATOR
> -/* Used to preserve page allocation order entropy */
> -void add_to_free_area_random(struct page *page, struct free_area *area,
> -		int migratetype);
> -#else
> -static inline void add_to_free_area_random(struct page *page,
> -		struct free_area *area, int migratetype)
> -{
> -	add_to_free_area(page, area, migratetype);
> -}
> -#endif
> -
>  /* Used for pages which are on another list */
>  static inline void move_to_free_area(struct page *page, struct free_area *area,
>  			     int migratetype)

Looks like add_to_free_area() and add_to_free_area_tail() can be moved to
mm/page_alloc.c as all users are there now. And the same for struct
free_area definition (but not declaration).

> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index c5d62f1c2851..4e4356ba66c7 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -878,6 +878,36 @@ static inline struct capture_control *task_capc(struct zone *zone)
>  #endif /* CONFIG_COMPACTION */
>  
>  /*
> + * If this is not the largest possible page, check if the buddy
> + * of the next-highest order is free. If it is, it's possible
> + * that pages are being freed that will coalesce soon. In case,
> + * that is happening, add the free page to the tail of the list
> + * so it's less likely to be used soon and more likely to be merged
> + * as a higher order page
> + */
> +static inline bool
> +buddy_merge_likely(unsigned long pfn, unsigned long buddy_pfn,
> +		   struct page *page, unsigned int order)
> +{
> +	struct page *higher_page, *higher_buddy;
> +	unsigned long combined_pfn;
> +
> +	if (order >= MAX_ORDER - 2)
> +		return false;
> +
> +	if (!pfn_valid_within(buddy_pfn))
> +		return false;
> +
> +	combined_pfn = buddy_pfn & pfn;
> +	higher_page = page + (combined_pfn - pfn);
> +	buddy_pfn = __find_buddy_pfn(combined_pfn, order + 1);
> +	higher_buddy = higher_page + (buddy_pfn - combined_pfn);
> +
> +	return pfn_valid_within(buddy_pfn) &&
> +	       page_is_buddy(higher_page, higher_buddy, order + 1);
> +}

Okay, that's much easier to read.

> +
> +/*
>   * Freeing function for a buddy system allocator.
>   *
>   * The concept of a buddy system is to maintain direct-mapped table
> @@ -906,11 +936,12 @@ static inline void __free_one_page(struct page *page,
>  		struct zone *zone, unsigned int order,
>  		int migratetype)
>  {
> -	unsigned long combined_pfn;
> +	struct capture_control *capc = task_capc(zone);
>  	unsigned long uninitialized_var(buddy_pfn);
> -	struct page *buddy;
> +	unsigned long combined_pfn;
> +	struct free_area *area;
>  	unsigned int max_order;
> -	struct capture_control *capc = task_capc(zone);
> +	struct page *buddy;
>  
>  	max_order = min_t(unsigned int, MAX_ORDER, pageblock_order + 1);
>  
> @@ -979,35 +1010,12 @@ static inline void __free_one_page(struct page *page,
>  done_merging:
>  	set_page_order(page, order);
>  
> -	/*
> -	 * If this is not the largest possible page, check if the buddy
> -	 * of the next-highest order is free. If it is, it's possible
> -	 * that pages are being freed that will coalesce soon. In case,
> -	 * that is happening, add the free page to the tail of the list
> -	 * so it's less likely to be used soon and more likely to be merged
> -	 * as a higher order page
> -	 */
> -	if ((order < MAX_ORDER-2) && pfn_valid_within(buddy_pfn)
> -			&& !is_shuffle_order(order)) {
> -		struct page *higher_page, *higher_buddy;
> -		combined_pfn = buddy_pfn & pfn;
> -		higher_page = page + (combined_pfn - pfn);
> -		buddy_pfn = __find_buddy_pfn(combined_pfn, order + 1);
> -		higher_buddy = higher_page + (buddy_pfn - combined_pfn);
> -		if (pfn_valid_within(buddy_pfn) &&
> -		    page_is_buddy(higher_page, higher_buddy, order + 1)) {
> -			add_to_free_area_tail(page, &zone->free_area[order],
> -					      migratetype);
> -			return;
> -		}
> -	}
> -
> -	if (is_shuffle_order(order))
> -		add_to_free_area_random(page, &zone->free_area[order],
> -				migratetype);
> +	area = &zone->free_area[order];
> +	if (is_shuffle_order(order) ? shuffle_pick_tail() :
> +	    buddy_merge_likely(pfn, buddy_pfn, page, order))

Too loaded condition to my taste. Maybe

	bool to_tail;
	...
	if (is_shuffle_order(order))
		to_tail = shuffle_pick_tail();
	else if (buddy_merge_likely(pfn, buddy_pfn, page, order))
		to_tail = true;
	else
		to_tail = false;

	if (to_tail)
		add_to_free_area_tail(page, area, migratetype);
	else
		add_to_free_area(page, area, migratetype);

> +		add_to_free_area_tail(page, area, migratetype);
>  	else
> -		add_to_free_area(page, &zone->free_area[order], migratetype);
> -
> +		add_to_free_area(page, area, migratetype);
>  }
>  
>  /*
> diff --git a/mm/shuffle.c b/mm/shuffle.c
> index 9ba542ecf335..345cb4347455 100644
> --- a/mm/shuffle.c
> +++ b/mm/shuffle.c
> @@ -4,7 +4,6 @@
>  #include <linux/mm.h>
>  #include <linux/init.h>
>  #include <linux/mmzone.h>
> -#include <linux/random.h>
>  #include <linux/moduleparam.h>
>  #include "internal.h"
>  #include "shuffle.h"

Why do you move #include <linux/random.h> from .c to .h?
It's not obvious to me.

> @@ -190,8 +189,7 @@ struct batched_bit_entropy {
>  
>  static DEFINE_PER_CPU(struct batched_bit_entropy, batched_entropy_bool);
>  
> -void add_to_free_area_random(struct page *page, struct free_area *area,
> -		int migratetype)
> +bool __shuffle_pick_tail(void)
>  {
>  	struct batched_bit_entropy *batch;
>  	unsigned long entropy;
> @@ -213,8 +211,5 @@ void add_to_free_area_random(struct page *page, struct free_area *area,
>  	batch->position = position;
>  	entropy = batch->entropy_bool;
>  
> -	if (1ul & (entropy >> position))
> -		add_to_free_area(page, area, migratetype);
> -	else
> -		add_to_free_area_tail(page, area, migratetype);
> +	return 1ul & (entropy >> position);
>  }
> diff --git a/mm/shuffle.h b/mm/shuffle.h
> index 777a257a0d2f..0723eb97f22f 100644
> --- a/mm/shuffle.h
> +++ b/mm/shuffle.h
> @@ -3,6 +3,7 @@
>  #ifndef _MM_SHUFFLE_H
>  #define _MM_SHUFFLE_H
>  #include <linux/jump_label.h>
> +#include <linux/random.h>
>  
>  /*
>   * SHUFFLE_ENABLE is called from the command line enabling path, or by
> @@ -22,6 +23,7 @@ enum mm_shuffle_ctl {
>  DECLARE_STATIC_KEY_FALSE(page_alloc_shuffle_key);
>  extern void page_alloc_shuffle(enum mm_shuffle_ctl ctl);
>  extern void __shuffle_free_memory(pg_data_t *pgdat);
> +extern bool __shuffle_pick_tail(void);
>  static inline void shuffle_free_memory(pg_data_t *pgdat)
>  {
>  	if (!static_branch_unlikely(&page_alloc_shuffle_key))
> @@ -43,6 +45,11 @@ static inline bool is_shuffle_order(int order)
>  		return false;
>  	return order >= SHUFFLE_ORDER;
>  }
> +
> +static inline bool shuffle_pick_tail(void)
> +{
> +	return __shuffle_pick_tail();
> +}

I don't see a reason in __shuffle_pick_tail() existing if you call it
unconditionally.

>  #else
>  static inline void shuffle_free_memory(pg_data_t *pgdat)
>  {
> @@ -60,5 +67,10 @@ static inline bool is_shuffle_order(int order)
>  {
>  	return false;
>  }
> +
> +static inline bool shuffle_pick_tail(void)
> +{
> +	return false;
> +}
>  #endif
>  #endif /* _MM_SHUFFLE_H */
> 
> 

-- 
 Kirill A. Shutemov

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: [PATCH v9 3/8] mm: Move set/get_pcppage_migratetype to mmzone.h
  2019-09-07 17:25 ` [PATCH v9 3/8] mm: Move set/get_pcppage_migratetype to mmzone.h Alexander Duyck
  2019-09-09  8:22   ` David Hildenbrand
@ 2019-09-09  9:56   ` Kirill A. Shutemov
  2019-09-09 18:01     ` Alexander Duyck
  2019-09-10 12:23   ` Michal Hocko
  2 siblings, 1 reply; 82+ messages in thread
From: Kirill A. Shutemov @ 2019-09-09  9:56 UTC (permalink / raw)
  To: Alexander Duyck
  Cc: virtio-dev, kvm, mst, catalin.marinas, david, dave.hansen,
	linux-kernel, willy, mhocko, linux-mm, akpm, will,
	linux-arm-kernel, osalvador, yang.zhang.wz, pagupta, konrad.wilk,
	nitesh, riel, lcapitulino, wei.w.wang, aarcange, ying.huang,
	pbonzini, dan.j.williams, fengguang.wu, alexander.h.duyck,
	kirill.shutemov

On Sat, Sep 07, 2019 at 10:25:28AM -0700, Alexander Duyck wrote:
> From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> 
> In order to support page reporting it will be necessary to store and
> retrieve the migratetype of a page. To enable that I am moving the set and
> get operations for pcppage_migratetype into the mm/internal.h header so
> that they can be used outside of the page_alloc.c file.
> 
> Reviewed-by: Dan Williams <dan.j.williams@intel.com>
> Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>

I'm not sure that it's great idea to export this functionality beyond
mm/page_alloc.c without any additional safeguards. How would we avoid to
messing with ->index when the page is not in the right state of its
life-cycle. Can we add some VM_BUG_ON()s here?

-- 
 Kirill A. Shutemov

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: [PATCH v9 6/8] mm: Introduce Reported pages
  2019-09-07 17:25 ` [PATCH v9 6/8] mm: Introduce Reported pages Alexander Duyck
@ 2019-09-09 14:42   ` Kirill A. Shutemov
  2019-09-09 16:25     ` Alexander Duyck
  0 siblings, 1 reply; 82+ messages in thread
From: Kirill A. Shutemov @ 2019-09-09 14:42 UTC (permalink / raw)
  To: Alexander Duyck
  Cc: virtio-dev, kvm, mst, catalin.marinas, david, dave.hansen,
	linux-kernel, willy, mhocko, linux-mm, akpm, will,
	linux-arm-kernel, osalvador, yang.zhang.wz, pagupta, konrad.wilk,
	nitesh, riel, lcapitulino, wei.w.wang, aarcange, ying.huang,
	pbonzini, dan.j.williams, fengguang.wu, alexander.h.duyck,
	kirill.shutemov

On Sat, Sep 07, 2019 at 10:25:53AM -0700, Alexander Duyck wrote:
> From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> 
> In order to pave the way for free page reporting in virtualized
> environments we will need a way to get pages out of the free lists and
> identify those pages after they have been returned. To accomplish this,
> this patch adds the concept of a Reported Buddy, which is essentially
> meant to just be the Uptodate flag used in conjunction with the Buddy
> page type.
> 
> It adds a set of pointers we shall call "boundary" which represents the
> upper boundary between the unreported and reported pages. The general idea
> is that in order for a page to cross from one side of the boundary to the
> other it will need to go through the reporting process. Ultimately a
> free_list has been fully processed when the boundary has been moved from
> the tail all they way up to occupying the first entry in the list.
> 
> Doing this we should be able to make certain that we keep the reported
> pages as one contiguous block in each free list. This will allow us to
> efficiently manipulate the free lists whenever we need to go in and start
> sending reports to the hypervisor that there are new pages that have been
> freed and are no longer in use.
> 
> An added advantage to this approach is that we should be reducing the
> overall memory footprint of the guest as it will be more likely to recycle
> warm pages versus trying to allocate the reported pages that were likely
> evicted from the guest memory.
> 
> Since we will only be reporting one zone at a time we keep the boundary
> limited to being defined for just the zone we are currently reporting pages
> from. Doing this we can keep the number of additional pointers needed quite
> small. To flag that the boundaries are in place we use a single bit
> in the zone to indicate that reporting and the boundaries are active.
> 
> The determination of when to start reporting is based on the tracking of
> the number of free pages in a given area versus the number of reported
> pages in that area. We keep track of the number of reported pages per
> free_area in a separate zone specific area. We do this to avoid modifying
> the free_area structure as this can lead to false sharing for the highest
> order with the zone lock which leads to a noticeable performance
> degradation.
> 
> Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> ---
>  include/linux/mmzone.h         |   52 +++++-
>  include/linux/page-flags.h     |   11 +
>  include/linux/page_reporting.h |  178 ++++++++++++++++++++
>  mm/Kconfig                     |    5 +
>  mm/Makefile                    |    1 
>  mm/memory_hotplug.c            |    1 
>  mm/page_alloc.c                |  115 ++++++++++++-
>  mm/page_reporting.c            |  358 ++++++++++++++++++++++++++++++++++++++++
>  8 files changed, 711 insertions(+), 10 deletions(-)
>  create mode 100644 include/linux/page_reporting.h
>  create mode 100644 mm/page_reporting.c
> 
> diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
> index 2ddf1f1971c0..4b2c44d7e266 100644
> --- a/include/linux/mmzone.h
> +++ b/include/linux/mmzone.h
> @@ -463,6 +463,14 @@ struct zone {
>  	seqlock_t		span_seqlock;
>  #endif
>  
> +#ifdef CONFIG_PAGE_REPORTING
> +	/*
> +	 * Pointer to reported page tracking statistics array. The size of
> +	 * the array is MAX_ORDER - PAGE_REPORTING_MIN_ORDER. NULL when
> +	 * unused page reporting is not present.
> +	 */
> +	unsigned long		*reported_pages;
> +#endif
>  	int initialized;
>  
>  	/* Write-intensive fields used from the page allocator */
> @@ -538,6 +546,14 @@ enum zone_flags {
>  	ZONE_BOOSTED_WATERMARK,		/* zone recently boosted watermarks.
>  					 * Cleared when kswapd is woken.
>  					 */
> +	ZONE_PAGE_REPORTING_REQUESTED,	/* zone enabled page reporting and has
> +					 * requested flushing the data out of
> +					 * higher order pages.
> +					 */
> +	ZONE_PAGE_REPORTING_ACTIVE,	/* zone enabled page reporting and is
> +					 * activly flushing the data out of
> +					 * higher order pages.
> +					 */
>  };
>  
>  static inline unsigned long zone_managed_pages(struct zone *zone)
> @@ -764,6 +780,8 @@ static inline bool pgdat_is_empty(pg_data_t *pgdat)
>  	return !pgdat->node_start_pfn && !pgdat->node_spanned_pages;
>  }
>  
> +#include <linux/page_reporting.h>
> +
>  /* Used for pages not on another list */
>  static inline void add_to_free_list(struct page *page, struct zone *zone,
>  				    unsigned int order, int migratetype)
> @@ -778,24 +796,48 @@ static inline void add_to_free_list(struct page *page, struct zone *zone,
>  static inline void add_to_free_list_tail(struct page *page, struct zone *zone,
>  					 unsigned int order, int migratetype)
>  {
> -	struct free_area *area = &zone->free_area[order];
> +	struct list_head *tail = get_unreported_tail(zone, order, migratetype);
>  
> -	list_add_tail(&page->lru, &area->free_list[migratetype]);
> -	area->nr_free++;
> +	/*
> +	 * To prevent the unreported pages from being interleaved with the
> +	 * reported ones while we are actively processing pages we will use
> +	 * the head of the reported pages to determine the tail of the free
> +	 * list.
> +	 */
> +	list_add_tail(&page->lru, tail);
> +	zone->free_area[order].nr_free++;
>  }
>  
>  /* Used for pages which are on another list */
>  static inline void move_to_free_list(struct page *page, struct zone *zone,
>  				     unsigned int order, int migratetype)
>  {
> -	struct free_area *area = &zone->free_area[order];
> +	struct list_head *tail = get_unreported_tail(zone, order, migratetype);
> +
> +	/*
> +	 * We must get the tail for our target list before moving the page on
> +	 * the reported list as we will possibly be replacing the tail page of
> +	 * the list with our current page if it is reported.
> +	 */
> +	if (unlikely(PageReported(page)))
> +		move_page_to_reported_list(page, zone, migratetype);
>  
> -	list_move(&page->lru, &area->free_list[migratetype]);
> +	/*
> +	 * To prevent unreported pages from being mixed with the reported
> +	 * ones we add pages to the tail of the list. By doing this the function
> +	 * above can either label them as included in the reported list or not
> +	 * and the result will be consistent.
> +	 */
> +	list_move_tail(&page->lru, tail);
>  }
>  
>  static inline void del_page_from_free_list(struct page *page, struct zone *zone,
>  					   unsigned int order)
>  {
> +	/* remove page from reported list, and clear reported state */
> +	if (unlikely(PageReported(page)))
> +		del_page_from_reported_list(page, zone);
> +
>  	list_del(&page->lru);
>  	__ClearPageBuddy(page);
>  	set_page_private(page, 0);
> diff --git a/include/linux/page-flags.h b/include/linux/page-flags.h
> index f91cb8898ff0..759a3b3956f2 100644
> --- a/include/linux/page-flags.h
> +++ b/include/linux/page-flags.h
> @@ -163,6 +163,9 @@ enum pageflags {
>  
>  	/* non-lru isolated movable page */
>  	PG_isolated = PG_reclaim,
> +
> +	/* Buddy pages. Used to track which pages have been reported */
> +	PG_reported = PG_uptodate,
>  };
>  
>  #ifndef __GENERATING_BOUNDS_H
> @@ -432,6 +435,14 @@ static inline bool set_hwpoison_free_buddy_page(struct page *page)
>  #endif
>  
>  /*
> + * PageReported() is used to track reported free pages within the Buddy
> + * allocator. We can use the non-atomic version of the test and set
> + * operations as both should be shielded with the zone lock to prevent
> + * any possible races on the setting or clearing of the bit.
> + */
> +__PAGEFLAG(Reported, reported, PF_NO_COMPOUND)
> +
> +/*
>   * On an anonymous page mapped into a user virtual memory area,
>   * page->mapping points to its anon_vma, not to a struct address_space;
>   * with the PAGE_MAPPING_ANON bit set to distinguish it.  See rmap.h.
> diff --git a/include/linux/page_reporting.h b/include/linux/page_reporting.h
> new file mode 100644
> index 000000000000..836033ca237b
> --- /dev/null
> +++ b/include/linux/page_reporting.h
> @@ -0,0 +1,178 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef _LINUX_PAGE_REPORTING_H
> +#define _LINUX_PAGE_REPORTING_H
> +
> +#include <linux/mmzone.h>
> +#include <linux/jump_label.h>
> +#include <linux/pageblock-flags.h>
> +
> +#define PAGE_REPORTING_MIN_ORDER	pageblock_order
> +#define PAGE_REPORTING_HWM		32
> +
> +#ifdef CONFIG_PAGE_REPORTING
> +struct page_reporting_dev_info {
> +	/* function that alters pages to make them "reported" */
> +	void (*report)(struct page_reporting_dev_info *phdev,
> +		       unsigned int nents);
> +
> +	/* scatterlist containing pages to be processed */
> +	struct scatterlist *sg;
> +
> +	/*
> +	 * Upper limit on the number of pages that the react function
> +	 * expects to be placed into the batch list to be processed.
> +	 */
> +	unsigned long capacity;
> +
> +	/* work struct for processing reports */
> +	struct delayed_work work;
> +
> +	/*
> +	 * The number of zones requesting reporting, plus one additional if
> +	 * processing thread is active.
> +	 */
> +	atomic_t refcnt;
> +};
> +
> +/* Boundary functions */
> +struct list_head *__page_reporting_get_boundary(unsigned int order,
> +						int migratetype);
> +void page_reporting_del_from_boundary(struct page *page);
> +void page_reporting_add_to_boundary(struct page *page, int migratetype);
> +void page_reporting_move_to_boundary(struct page *page, struct zone *zone,
> +				     int migratetype);
> +
> +/* Reported page accessors, defined in page_alloc.c */
> +struct page *get_unreported_page(struct zone *zone, unsigned int order,
> +				 int migratetype);
> +void free_reported_page(struct page *page, unsigned int order);
> +
> +/* Tear-down and bring-up for page reporting devices */
> +void page_reporting_shutdown(struct page_reporting_dev_info *phdev);
> +int page_reporting_startup(struct page_reporting_dev_info *phdev);
> +
> +void __page_reporting_free_stats(struct zone *zone);
> +void __page_reporting_request(struct zone *zone);
> +
> +static inline void __del_page_from_reported_list(struct page *page,
> +						 struct zone *zone)
> +{
> +	/* page_private will contain the page order, so just use it directly */
> +	zone->reported_pages[page_private(page) - PAGE_REPORTING_MIN_ORDER]--;
> +
> +	/* clear the flag so we can report on it when it returns */
> +	__ClearPageReported(page);
> +}
> +#endif /* CONFIG_PAGE_REPORTING */
> +
> +/*
> + * Method for obtaining the tail of the free list. Using this allows for
> + * tail insertions of unreported pages into the region that is currently
> + * being scanned so as to avoid interleaving reported and unreported pages.
> + */
> +static inline struct list_head *
> +get_unreported_tail(struct zone *zone, unsigned int order, int migratetype)
> +{
> +#ifdef CONFIG_PAGE_REPORTING
> +	if (order >= PAGE_REPORTING_MIN_ORDER &&
> +	    test_bit(ZONE_PAGE_REPORTING_ACTIVE, &zone->flags))
> +		return __page_reporting_get_boundary(order, migratetype);
> +#endif
> +	return &zone->free_area[order].free_list[migratetype];
> +}
> +
> +/*
> + * Functions for adding/removing pages from reported end of list.
> + * All of them expect the zone lock to be held to maintain
> + * consistency of the reported list as a subset of the free list.
> + */
> +static inline void add_page_to_reported_list(struct page *page,
> +					     struct zone *zone,
> +					     int order,
> +					     int migratetype)
> +{
> +#ifdef CONFIG_PAGE_REPORTING

Instead of ifdefing full body of the helpers, can we have two sets of
these helpres defined for CONFIG_PAGE_REPORTING and for
!CONFIG_PAGE_REPORTING cases?

Or can we get all this working with IS_ENABLED() instead of #ifdef?

> +	/* flag page as reported */
> +	__SetPageReported(page);
> +
> +	/* update areated page accounting */
> +	zone->reported_pages[order - PAGE_REPORTING_MIN_ORDER]++;
> +
> +	/* update boundary of new migratetype and record it */
> +	page_reporting_add_to_boundary(page, migratetype);
> +#endif
> +}
> +
> +static inline void del_page_from_reported_list(struct page *page,
> +					       struct zone *zone)
> +{
> +#ifdef CONFIG_PAGE_REPORTING
> +	/* push boundary back if we removed the upper boundary */
> +	if (test_bit(ZONE_PAGE_REPORTING_ACTIVE, &zone->flags))
> +		page_reporting_del_from_boundary(page);
> +
> +	__del_page_from_reported_list(page, zone);
> +#endif
> +}
> +
> +static inline void move_page_to_reported_list(struct page *page,
> +					      struct zone *zone,
> +					      int migratetype)
> +{
> +#ifdef CONFIG_PAGE_REPORTING
> +	page_reporting_move_to_boundary(page, zone, migratetype);
> +#endif
> +}
> +
> +/* Free reported_pages and reset reported page tracking count to 0 */
> +static inline void page_reporting_reset(struct zone *zone)
> +{
> +#ifdef CONFIG_PAGE_REPORTING
> +	if (zone->reported_pages)
> +		__page_reporting_free_stats(zone);
> +#endif
> +}
> +
> +DECLARE_STATIC_KEY_FALSE(page_reporting_notify_enabled);
> +
> +/**
> + * page_reporting_notify_free - Free page notification to start page processing
> + * @zone: Pointer to current zone of last page processed
> + * @order: Order of last page added to zone
> + *
> + * This function is meant to act as a screener for __page_reporting_request
> + * which will determine if a give zone has crossed over the high-water mark
> + * that will justify us beginning page treatment. If we have crossed that
> + * threshold then it will start the process of pulling some pages and
> + * placing them in the batch list for treatment.
> + */
> +static inline void page_reporting_notify_free(struct zone *zone, int order)
> +{
> +#ifdef CONFIG_PAGE_REPORTING
> +	unsigned long nr_reported;
> +
> +	/* Called from hot path in __free_one_page() */
> +	if (!static_branch_unlikely(&page_reporting_notify_enabled))
> +		return;
> +
> +	/* Limit notifications only to higher order pages */
> +	if (order < PAGE_REPORTING_MIN_ORDER)
> +		return;
> +
> +	/* Do not bother with tests if we have already requested reporting */
> +	if (test_bit(ZONE_PAGE_REPORTING_REQUESTED, &zone->flags))
> +		return;

How is it not racy wrt page_reporting_fill()? Do we hold zone->lock or
something?

> +
> +	/* If reported_pages is not populated, assume 0 */
> +	nr_reported = zone->reported_pages ?
> +		    zone->reported_pages[order - PAGE_REPORTING_MIN_ORDER] : 0;
> +
> +	/* Only request it if we have enough to begin the page reporting */
> +	if (zone->free_area[order].nr_free < nr_reported + PAGE_REPORTING_HWM)
> +		return;
> +
> +	/* This is slow, but should be called very rarely */
> +	__page_reporting_request(zone);
> +#endif
> +}
> +#endif /*_LINUX_PAGE_REPORTING_H */
> diff --git a/mm/Kconfig b/mm/Kconfig
> index a5dae9a7eb51..be1a5db50df5 100644
> --- a/mm/Kconfig
> +++ b/mm/Kconfig
> @@ -237,6 +237,11 @@ config COMPACTION
>            linux-mm@kvack.org.
>  
>  #
> +# support for unused page reporting
> +config PAGE_REPORTING
> +	bool
> +
> +#

Proper description for the config option?

>  # support for page migration
>  #
>  config MIGRATION
> diff --git a/mm/Makefile b/mm/Makefile
> index d996846697ef..fc4fa17b6c83 100644
> --- a/mm/Makefile
> +++ b/mm/Makefile
> @@ -107,3 +107,4 @@ obj-$(CONFIG_PERCPU_STATS) += percpu-stats.o
>  obj-$(CONFIG_ZONE_DEVICE) += memremap.o
>  obj-$(CONFIG_HMM_MIRROR) += hmm.o
>  obj-$(CONFIG_MEMFD_CREATE) += memfd.o
> +obj-$(CONFIG_PAGE_REPORTING) += page_reporting.o
> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> index 49f7bf91c25a..cb71a7190682 100644
> --- a/mm/memory_hotplug.c
> +++ b/mm/memory_hotplug.c
> @@ -1613,6 +1613,7 @@ static int __ref __offline_pages(unsigned long start_pfn,
>  	if (!populated_zone(zone)) {
>  		zone_pcp_reset(zone);
>  		build_all_zonelists(NULL);
> +		page_reporting_reset(zone);
>  	} else
>  		zone_pcp_update(zone);
>  
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index f85dc1561b85..615aea24c082 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -68,6 +68,7 @@
>  #include <linux/lockdep.h>
>  #include <linux/nmi.h>
>  #include <linux/psi.h>
> +#include <linux/page_reporting.h>
>  
>  #include <asm/sections.h>
>  #include <asm/tlbflush.h>
> @@ -916,7 +917,7 @@ static inline struct capture_control *task_capc(struct zone *zone)
>  static inline void __free_one_page(struct page *page,
>  		unsigned long pfn,
>  		struct zone *zone, unsigned int order,
> -		int migratetype)
> +		int migratetype, bool reported)
>  {
>  	struct capture_control *capc = task_capc(zone);
>  	unsigned long uninitialized_var(buddy_pfn);
> @@ -991,11 +992,20 @@ static inline void __free_one_page(struct page *page,
>  done_merging:
>  	set_page_order(page, order);
>  
> -	if (is_shuffle_order(order) ? shuffle_pick_tail() :
> -	    buddy_merge_likely(pfn, buddy_pfn, page, order))
> +	if (reported ||
> +	    (is_shuffle_order(order) ? shuffle_pick_tail() :
> +	     buddy_merge_likely(pfn, buddy_pfn, page, order)))
>  		add_to_free_list_tail(page, zone, order, migratetype);
>  	else
>  		add_to_free_list(page, zone, order, migratetype);
> +
> +	/*
> +	 * No need to notify on a reported page as the total count of
> +	 * unreported pages will not have increased since we have essentially
> +	 * merged the reported page with one or more unreported pages.
> +	 */
> +	if (!reported)
> +		page_reporting_notify_free(zone, order);
>  }
>  
>  /*
> @@ -1306,7 +1316,7 @@ static void free_pcppages_bulk(struct zone *zone, int count,
>  		if (unlikely(isolated_pageblocks))
>  			mt = get_pageblock_migratetype(page);
>  
> -		__free_one_page(page, page_to_pfn(page), zone, 0, mt);
> +		__free_one_page(page, page_to_pfn(page), zone, 0, mt, false);
>  		trace_mm_page_pcpu_drain(page, 0, mt);
>  	}
>  	spin_unlock(&zone->lock);
> @@ -1322,7 +1332,7 @@ static void free_one_page(struct zone *zone,
>  		is_migrate_isolate(migratetype))) {
>  		migratetype = get_pfnblock_migratetype(page, pfn);
>  	}
> -	__free_one_page(page, pfn, zone, order, migratetype);
> +	__free_one_page(page, pfn, zone, order, migratetype, false);
>  	spin_unlock(&zone->lock);
>  }
>  
> @@ -2184,6 +2194,101 @@ struct page *__rmqueue_smallest(struct zone *zone, unsigned int order,
>  	return NULL;
>  }
>  
> +#ifdef CONFIG_PAGE_REPORTING
> +/**
> + * free_reported_page - Return a now-reported page back where we got it
> + * @page: Page that was reported
> + * @order: Order of the reported page
> + *
> + * This function will pull the migratetype and order information out
> + * of the page and attempt to return it where it found it. If the page
> + * is added to the free list without changes we will mark it as being
> + * reported.
> + */
> +void free_reported_page(struct page *page, unsigned int order)
> +{
> +	struct zone *zone = page_zone(page);
> +	unsigned long pfn;
> +	unsigned int mt;
> +
> +	/* zone lock should be held when this function is called */
> +	lockdep_assert_held(&zone->lock);
> +
> +	pfn = page_to_pfn(page);
> +	mt = get_pfnblock_migratetype(page, pfn);
> +	__free_one_page(page, pfn, zone, order, mt, true);
> +
> +	/*
> +	 * If page was not comingled with another page we can consider
> +	 * the result to be "reported" since part of the page hasn't been
> +	 * modified, otherwise we would need to report on the new larger
> +	 * page.
> +	 */
> +	if (PageBuddy(page) && page_order(page) == order)
> +		add_page_to_reported_list(page, zone, order, mt);
> +}
> +
> +/**
> + * get_unreported_page - Pull an unreported page from the free_list
> + * @zone: Zone to draw pages from
> + * @order: Order to draw pages from
> + * @mt: Migratetype to draw pages from
> + *
> + * This function will obtain a page from the free list. It will start by
> + * attempting to pull from the tail of the free list and if that is already
> + * reported on it will instead pull the head if that is unreported.
> + *
> + * The page will have the migrate type and order stored in the page
> + * metadata. While being processed the page will not be avaialble for
> + * allocation.
> + *
> + * Return: page pointer if raw page found, otherwise NULL
> + */
> +struct page *get_unreported_page(struct zone *zone, unsigned int order, int mt)
> +{
> +	struct list_head *tail = get_unreported_tail(zone, order, mt);
> +	struct free_area *area = &(zone->free_area[order]);
> +	struct list_head *list = &area->free_list[mt];
> +	struct page *page;
> +
> +	/* zone lock should be held when this function is called */
> +	lockdep_assert_held(&zone->lock);
> +
> +	/* Find a page of the appropriate size in the preferred list */
> +	page = list_last_entry(tail, struct page, lru);
> +	list_for_each_entry_from_reverse(page, list, lru) {
> +		/* If we entered this loop then the "raw" list isn't empty */
> +
> +		/* If the page is reported try the head of the list */
> +		if (PageReported(page)) {
> +			page = list_first_entry(list, struct page, lru);
> +
> +			/*
> +			 * If both the head and tail are reported then reset
> +			 * the boundary so that we read as an empty list
> +			 * next time and bail out.
> +			 */
> +			if (PageReported(page)) {
> +				page_reporting_add_to_boundary(page, mt);
> +				break;
> +			}
> +		}
> +
> +		del_page_from_free_list(page, zone, order);
> +
> +		/*
> +		 * Page will not be available for allocation while we are
> +		 * processing it so update the freepage state.
> +		 */
> +		__mod_zone_freepage_state(zone, -(1 << order), mt);
> +
> +		return page;
> +	}
> +
> +	return NULL;
> +}
> +#endif /* CONFIG_PAGE_REPORTING */
> +
>  /*
>   * This array describes the order lists are fallen back to when
>   * the free lists for the desirable migrate type are depleted
> diff --git a/mm/page_reporting.c b/mm/page_reporting.c
> new file mode 100644
> index 000000000000..a59ef53eb0b8
> --- /dev/null
> +++ b/mm/page_reporting.c
> @@ -0,0 +1,358 @@
> +// SPDX-License-Identifier: GPL-2.0
> +#include <linux/mm.h>
> +#include <linux/mmzone.h>
> +#include <linux/page-isolation.h>
> +#include <linux/gfp.h>
> +#include <linux/export.h>
> +#include <linux/delay.h>
> +#include <linux/slab.h>
> +#include <linux/scatterlist.h>
> +#include "internal.h"
> +
> +static struct page_reporting_dev_info __rcu *ph_dev_info __read_mostly;
> +struct list_head **boundary __read_mostly;
> +
> +static inline struct list_head **get_boundary_ptr(unsigned int order,
> +						  unsigned int migratetype)
> +{
> +	return boundary +
> +	       (order - PAGE_REPORTING_MIN_ORDER) * MIGRATE_TYPES + migratetype;
> +}
> +
> +static void page_reporting_reset_boundary(struct zone *zone, unsigned int order,
> +					  unsigned int migratetype)
> +{
> +	struct list_head **tail = get_boundary_ptr(order, migratetype);
> +
> +	*tail = &zone->free_area[order].free_list[migratetype];
> +}
> +
> +#define for_each_reporting_migratetype_order(_order, _type) \
> +	for (_order = MAX_ORDER; _order-- != PAGE_REPORTING_MIN_ORDER;) \
> +		for (_type = MIGRATE_TYPES; _type--;) \
> +			if (!is_migrate_isolate(_type))
> +
> +static int page_reporting_populate_metadata(struct zone *zone)
> +{
> +	unsigned int order, mt;
> +
> +	/*
> +	 * We need to make sure we have somewhere to store the tracking
> +	 * data for how many reported pages are in the zone. To do that
> +	 * we need to make certain zone->reported_pages is populated.
> +	 */
> +	if (!zone->reported_pages) {
> +		zone->reported_pages =
> +			kcalloc(MAX_ORDER - PAGE_REPORTING_MIN_ORDER,
> +				sizeof(unsigned long),
> +				GFP_KERNEL);
> +		if (!zone->reported_pages)
> +			return -ENOMEM;
> +	}
> +
> +	/* Update boundary data to reflect the zone we are currently working */
> +	for_each_reporting_migratetype_order(order, mt)
> +		page_reporting_reset_boundary(zone, order, mt);
> +
> +	return 0;
> +}
> +
> +struct list_head *__page_reporting_get_boundary(unsigned int order,
> +						int migratetype)
> +{
> +	return *get_boundary_ptr(order, migratetype);
> +}
> +
> +void page_reporting_del_from_boundary(struct page *page)
> +{
> +	unsigned int order = page_private(page);
> +	int mt = get_pcppage_migratetype(page);
> +	struct list_head **tail = get_boundary_ptr(order, mt);
> +
> +	if (*tail == &page->lru)
> +		*tail = page->lru.next;
> +}
> +
> +void page_reporting_add_to_boundary(struct page *page, int migratetype)
> +{
> +	unsigned int order = page_private(page);
> +	struct list_head **tail = get_boundary_ptr(order, migratetype);
> +
> +	*tail = &page->lru;
> +	set_pcppage_migratetype(page, migratetype);
> +}
> +
> +void page_reporting_move_to_boundary(struct page *page, struct zone *zone,
> +				     int dest_mt)
> +{
> +	/*
> +	 * We essentially have two options available to us. The first is to
> +	 * move the page from the boundary list on one migratetype to the
> +	 * list for the new migratetype assuming reporting is still active.
> +	 *
> +	 * The other option is to clear the reported state of the page as
> +	 * we will not be adding it to the group of pages that were already
> +	 * reported. It is cheaper to just rereport such pages then go
> +	 * through and do a special search to skip over them. If the page
> +	 * is being moved into isolation we can defer this until the page
> +	 * comes out of isolation since we do not scan the isolated
> +	 * migratetype.
> +	 */
> +	if (test_bit(ZONE_PAGE_REPORTING_ACTIVE, &zone->flags)) {
> +		page_reporting_del_from_boundary(page);
> +		page_reporting_add_to_boundary(page, dest_mt);
> +	} else if (!is_migrate_isolate(dest_mt)) {
> +		__del_page_from_reported_list(page, zone);
> +	}
> +}
> +
> +static unsigned int page_reporting_fill(struct zone *zone,
> +					struct page_reporting_dev_info *phdev)
> +{
> +	struct scatterlist *sg = phdev->sg;
> +	unsigned int order, mt, count = 0;
> +
> +	sg_init_table(phdev->sg, phdev->capacity);
> +
> +	for_each_reporting_migratetype_order(order, mt) {
> +		struct page *page;
> +
> +		/*
> +		 * Pull pages from free list until we have drained
> +		 * it or we have reached capacity.
> +		 */
> +		while ((page = get_unreported_page(zone, order, mt))) {
> +			sg_set_page(&sg[count], page, PAGE_SIZE << order, 0);
> +
> +			if (++count == phdev->capacity)
> +				return count;
> +		}
> +	}
> +
> +	/* mark end of scatterlist due to underflow */
> +	if (count)
> +		sg_mark_end(&sg[count - 1]);
> +
> +	/*
> +	 * If there are no longer enough free pages to fully populate
> +	 * the scatterlist, then we can just shut it down for this zone.
> +	 */
> +	__clear_bit(ZONE_PAGE_REPORTING_REQUESTED, &zone->flags);
> +	atomic_dec(&phdev->refcnt);
> +
> +	return count;
> +}
> +
> +static void page_reporting_drain(struct page_reporting_dev_info *phdev)
> +{
> +	struct scatterlist *sg = phdev->sg;
> +
> +	/*
> +	 * Drain the now reported pages back into their respective
> +	 * free lists/areas. We assume at least one page is populated.
> +	 */
> +	do {
> +		free_reported_page(sg_page(sg), get_order(sg->length));
> +	} while (!sg_is_last(sg++));
> +}
> +
> +/*
> + * The page reporting cycle consists of 4 stages, fill, report, drain, and idle.
> + * We will cycle through the first 3 stages until we fail to obtain any
> + * pages, in that case we will switch to idle.
> + */
> +static void page_reporting_cycle(struct zone *zone,
> +				 struct page_reporting_dev_info *phdev)
> +{
> +	/*
> +	 * Guarantee boundaries and stats are populated before we
> +	 * start placing reported pages in the zone.
> +	 */
> +	if (page_reporting_populate_metadata(zone))
> +		return;
> +
> +	spin_lock_irq(&zone->lock);
> +
> +	/* set bit indicating boundaries are present */
> +	__set_bit(ZONE_PAGE_REPORTING_ACTIVE, &zone->flags);
> +
> +	do {
> +		/* Pull pages out of allocator into a scaterlist */
> +		unsigned int nents = page_reporting_fill(zone, phdev);
> +
> +		/* no pages were acquired, give up */
> +		if (!nents)
> +			break;
> +
> +		spin_unlock_irq(&zone->lock);
> +
> +		/* begin processing pages in local list */
> +		phdev->report(phdev, nents);
> +
> +		spin_lock_irq(&zone->lock);
> +
> +		/*
> +		 * We should have a scatterlist of pages that have been
> +		 * processed. Return them to their original free lists.
> +		 */
> +		page_reporting_drain(phdev);
> +
> +		/* keep pulling pages till there are none to pull */
> +	} while (test_bit(ZONE_PAGE_REPORTING_REQUESTED, &zone->flags));
> +
> +	/* processing of the zone is complete, we can disable boundaries */
> +	__clear_bit(ZONE_PAGE_REPORTING_ACTIVE, &zone->flags);
> +
> +	spin_unlock_irq(&zone->lock);
> +}
> +
> +static void page_reporting_process(struct work_struct *work)
> +{
> +	struct delayed_work *d_work = to_delayed_work(work);
> +	struct page_reporting_dev_info *phdev =
> +		container_of(d_work, struct page_reporting_dev_info, work);
> +	struct zone *zone = first_online_pgdat()->node_zones;
> +
> +	do {
> +		if (test_bit(ZONE_PAGE_REPORTING_REQUESTED, &zone->flags))
> +			page_reporting_cycle(zone, phdev);
> +
> +		/* Move to next zone, if at end of list start over */
> +		zone = next_zone(zone) ? : first_online_pgdat()->node_zones;
> +
> +		/*
> +		 * As long as refcnt has not reached zero there are still
> +		 * zones to be processed.
> +		 */
> +	} while (atomic_read(&phdev->refcnt));
> +}
> +
> +/* request page reporting on this zone */
> +void __page_reporting_request(struct zone *zone)
> +{
> +	struct page_reporting_dev_info *phdev;
> +
> +	rcu_read_lock();
> +
> +	/*
> +	 * We use RCU to protect the ph_dev_info pointer. In almost all
> +	 * cases this should be present, however in the unlikely case of
> +	 * a shutdown this will be NULL and we should exit.
> +	 */
> +	phdev = rcu_dereference(ph_dev_info);
> +	if (unlikely(!phdev))
> +		goto out;
> +
> +	/*
> +	 * We can use separate test and set operations here as there
> +	 * is nothing else that can set or clear this bit while we are
> +	 * holding the zone lock. The advantage to doing it this way is
> +	 * that we don't have to dirty the cacheline unless we are
> +	 * changing the value.
> +	 */
> +	__set_bit(ZONE_PAGE_REPORTING_REQUESTED, &zone->flags);
> +
> +	/*
> +	 * Delay the start of work to allow a sizable queue to
> +	 * build. For now we are limiting this to running no more
> +	 * than 10 times per second.
> +	 */
> +	if (!atomic_fetch_inc(&phdev->refcnt))
> +		schedule_delayed_work(&phdev->work, HZ / 10);
> +out:
> +	rcu_read_unlock();
> +}
> +
> +void __page_reporting_free_stats(struct zone *zone)
> +{
> +	/* free reported_page statisitics */
> +	kfree(zone->reported_pages);
> +	zone->reported_pages = NULL;
> +}
> +
> +static DEFINE_MUTEX(page_reporting_mutex);
> +DEFINE_STATIC_KEY_FALSE(page_reporting_notify_enabled);
> +
> +void page_reporting_shutdown(struct page_reporting_dev_info *phdev)
> +{
> +	mutex_lock(&page_reporting_mutex);
> +
> +	if (rcu_access_pointer(ph_dev_info) == phdev) {
> +		/* Disable page reporting notification */
> +		static_branch_disable(&page_reporting_notify_enabled);
> +		RCU_INIT_POINTER(ph_dev_info, NULL);
> +		synchronize_rcu();
> +
> +		/* Flush any existing work, and lock it out */
> +		cancel_delayed_work_sync(&phdev->work);
> +
> +		/* Free scatterlist */
> +		kfree(phdev->sg);
> +		phdev->sg = NULL;
> +
> +		/* Free boundaries */
> +		kfree(boundary);
> +		boundary = NULL;
> +	}
> +
> +	mutex_unlock(&page_reporting_mutex);
> +}
> +EXPORT_SYMBOL_GPL(page_reporting_shutdown);
> +
> +int page_reporting_startup(struct page_reporting_dev_info *phdev)
> +{
> +	struct zone *zone;
> +	int err = 0;
> +
> +	/* No point in enabling this if it cannot handle any pages */
> +	if (!phdev->capacity)
> +		return -EINVAL;

Looks like a usage error. Maybe WARN_ON()?

> +
> +	mutex_lock(&page_reporting_mutex);
> +
> +	/* nothing to do if already in use */
> +	if (rcu_access_pointer(ph_dev_info)) {
> +		err = -EBUSY;
> +		goto err_out;
> +	}

Again, it's from "something went horribly wrong" category.
Maybe WARN_ON()?

> +
> +	boundary = kcalloc(MAX_ORDER - PAGE_REPORTING_MIN_ORDER,
> +			   sizeof(struct list_head *) * MIGRATE_TYPES,
> +			   GFP_KERNEL);

Could you comment here on why this size of array is allocated?
The calculation is not obvious to a reader.

> +	if (!boundary) {
> +		err = -ENOMEM;
> +		goto err_out;
> +	}
> +
> +	/* allocate scatterlist to store pages being reported on */
> +	phdev->sg = kcalloc(phdev->capacity, sizeof(*phdev->sg), GFP_KERNEL);
> +	if (!phdev->sg) {
> +		err = -ENOMEM;
> +
> +		kfree(boundary);
> +		boundary = NULL;
> +
> +		goto err_out;
> +	}
> +
> +
> +	/* initialize refcnt and work structures */
> +	atomic_set(&phdev->refcnt, 0);
> +	INIT_DELAYED_WORK(&phdev->work, &page_reporting_process);
> +
> +	/* assign device, and begin initial flush of populated zones */
> +	rcu_assign_pointer(ph_dev_info, phdev);
> +	for_each_populated_zone(zone) {
> +		spin_lock_irq(&zone->lock);
> +		__page_reporting_request(zone);
> +		spin_unlock_irq(&zone->lock);
> +	}
> +
> +	/* enable page reporting notification */
> +	static_branch_enable(&page_reporting_notify_enabled);
> +err_out:
> +	mutex_unlock(&page_reporting_mutex);
> +
> +	return err;
> +}
> +EXPORT_SYMBOL_GPL(page_reporting_startup);
> 
> 

-- 
 Kirill A. Shutemov

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: [PATCH v9 1/8] mm: Add per-cpu logic to page shuffling
  2019-09-09  8:14   ` David Hildenbrand
@ 2019-09-09 15:11     ` Alexander Duyck
  2019-09-10 12:11       ` Michal Hocko
  2019-09-10 22:11     ` Alexander Duyck
  1 sibling, 1 reply; 82+ messages in thread
From: Alexander Duyck @ 2019-09-09 15:11 UTC (permalink / raw)
  To: David Hildenbrand, Alexander Duyck, virtio-dev, kvm, mst,
	catalin.marinas, dave.hansen, linux-kernel, willy, mhocko,
	linux-mm, akpm, will, linux-arm-kernel, osalvador
  Cc: yang.zhang.wz, pagupta, konrad.wilk, nitesh, riel, lcapitulino,
	wei.w.wang, aarcange, ying.huang, pbonzini, dan.j.williams,
	fengguang.wu, kirill.shutemov

On Mon, 2019-09-09 at 10:14 +0200, David Hildenbrand wrote:
> On 07.09.19 19:25, Alexander Duyck wrote:
> > From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> > 
> > Change the logic used to generate randomness in the suffle path so that we
> > can avoid cache line bouncing. The previous logic was sharing the offset
> > and entropy word between all CPUs. As such this can result in cache line
> > bouncing and will ultimately hurt performance when enabled.
> 
> So, usually we perform such changes if there is real evidence. Do you
> have any such performance numbers to back your claims?

I'll have to go rerun the test to get the exact numbers. The reason this
came up is that my original test was spanning NUMA nodes and that made
this more expensive as a result since the memory was both not local to the
CPU and was being updated by multiple sockets.

I will try building a pair of host kernels with shuffling enabled and this
patch applied to one and can add that data to the patch description.

- Alex



^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: [PATCH v9 1/8] mm: Add per-cpu logic to page shuffling
  2019-09-09  9:07   ` Kirill A. Shutemov
@ 2019-09-09 15:12     ` Alexander Duyck
  0 siblings, 0 replies; 82+ messages in thread
From: Alexander Duyck @ 2019-09-09 15:12 UTC (permalink / raw)
  To: Kirill A. Shutemov, Alexander Duyck
  Cc: virtio-dev, kvm, mst, catalin.marinas, david, dave.hansen,
	linux-kernel, willy, mhocko, linux-mm, akpm, will,
	linux-arm-kernel, osalvador, yang.zhang.wz, pagupta, konrad.wilk,
	nitesh, riel, lcapitulino, wei.w.wang, aarcange, ying.huang,
	pbonzini, dan.j.williams, fengguang.wu, kirill.shutemov

On Mon, 2019-09-09 at 12:07 +0300, Kirill A. Shutemov wrote:
> On Sat, Sep 07, 2019 at 10:25:12AM -0700, Alexander Duyck wrote:
> > From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> > 
> > Change the logic used to generate randomness in the suffle path so that we
> 
> Typo.
> 
> > can avoid cache line bouncing. The previous logic was sharing the offset
> > and entropy word between all CPUs. As such this can result in cache line
> > bouncing and will ultimately hurt performance when enabled.
> > 
> > To resolve this I have moved to a per-cpu logic for maintaining a unsigned
> > long containing some amount of bits, and an offset value for which bit we
> > can use for entropy with each call.
> > 
> > Reviewed-by: Dan Williams <dan.j.williams@intel.com>
> > Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> > ---
> >  mm/shuffle.c |   33 +++++++++++++++++++++++----------
> >  1 file changed, 23 insertions(+), 10 deletions(-)
> > 
> > diff --git a/mm/shuffle.c b/mm/shuffle.c
> > index 3ce12481b1dc..9ba542ecf335 100644
> > --- a/mm/shuffle.c
> > +++ b/mm/shuffle.c
> > @@ -183,25 +183,38 @@ void __meminit __shuffle_free_memory(pg_data_t *pgdat)
> >  		shuffle_zone(z);
> >  }
> >  
> > +struct batched_bit_entropy {
> > +	unsigned long entropy_bool;
> > +	int position;
> > +};
> > +
> > +static DEFINE_PER_CPU(struct batched_bit_entropy, batched_entropy_bool);
> > +
> >  void add_to_free_area_random(struct page *page, struct free_area *area,
> >  		int migratetype)
> >  {
> > -	static u64 rand;
> > -	static u8 rand_bits;
> > +	struct batched_bit_entropy *batch;
> > +	unsigned long entropy;
> > +	int position;
> >  
> >  	/*
> > -	 * The lack of locking is deliberate. If 2 threads race to
> > -	 * update the rand state it just adds to the entropy.
> > +	 * We shouldn't need to disable IRQs as the only caller is
> > +	 * __free_one_page and it should only be called with the zone lock
> > +	 * held and either from IRQ context or with local IRQs disabled.
> >  	 */
> > -	if (rand_bits == 0) {
> > -		rand_bits = 64;
> > -		rand = get_random_u64();
> > +	batch = raw_cpu_ptr(&batched_entropy_bool);
> > +	position = batch->position;
> > +
> > +	if (--position < 0) {
> > +		batch->entropy_bool = get_random_long();
> > +		position = BITS_PER_LONG - 1;
> >  	}
> >  
> > -	if (rand & 1)
> > +	batch->position = position;
> > +	entropy = batch->entropy_bool;
> > +
> > +	if (1ul & (entropy >> position))
> 
> Maybe something like this would be more readble:
> 
> 	if (entropy & BIT(position))
> 
> >  		add_to_free_area(page, area, migratetype);
> >  	else
> >  		add_to_free_area_tail(page, area, migratetype);
> > -	rand_bits--;
> > -	rand >>= 1;
> >  }
> > 
> > 

Thanks for the review. I will update these two items for v10.

- Alex


^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: [PATCH v9 2/8] mm: Adjust shuffle code to allow for future coalescing
  2019-09-09  9:47   ` Kirill A. Shutemov
@ 2019-09-09 15:22     ` Alexander Duyck
  2019-09-09 15:35       ` Kirill A. Shutemov
  2019-09-09 16:43     ` Alexander Duyck
  1 sibling, 1 reply; 82+ messages in thread
From: Alexander Duyck @ 2019-09-09 15:22 UTC (permalink / raw)
  To: Kirill A. Shutemov, Alexander Duyck
  Cc: virtio-dev, kvm, mst, catalin.marinas, david, dave.hansen,
	linux-kernel, willy, mhocko, linux-mm, akpm, will,
	linux-arm-kernel, osalvador, yang.zhang.wz, pagupta, konrad.wilk,
	nitesh, riel, lcapitulino, wei.w.wang, aarcange, ying.huang,
	pbonzini, dan.j.williams, fengguang.wu, kirill.shutemov

On Mon, 2019-09-09 at 12:47 +0300, Kirill A. Shutemov wrote:
> On Sat, Sep 07, 2019 at 10:25:20AM -0700, Alexander Duyck wrote:
> > From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> > 
> > Move the head/tail adding logic out of the shuffle code and into the
> > __free_one_page function since ultimately that is where it is really
> > needed anyway. By doing this we should be able to reduce the overhead
> > and can consolidate all of the list addition bits in one spot.
> > 
> > Reviewed-by: Dan Williams <dan.j.williams@intel.com>
> > Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> > ---
> >  include/linux/mmzone.h |   12 --------
> >  mm/page_alloc.c        |   70 +++++++++++++++++++++++++++---------------------
> >  mm/shuffle.c           |    9 +-----
> >  mm/shuffle.h           |   12 ++++++++
> >  4 files changed, 53 insertions(+), 50 deletions(-)
> > 
> > diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
> > index bda20282746b..125f300981c6 100644
> > --- a/include/linux/mmzone.h
> > +++ b/include/linux/mmzone.h
> > @@ -116,18 +116,6 @@ static inline void add_to_free_area_tail(struct page *page, struct free_area *ar
> >  	area->nr_free++;
> >  }
> >  
> > -#ifdef CONFIG_SHUFFLE_PAGE_ALLOCATOR
> > -/* Used to preserve page allocation order entropy */
> > -void add_to_free_area_random(struct page *page, struct free_area *area,
> > -		int migratetype);
> > -#else
> > -static inline void add_to_free_area_random(struct page *page,
> > -		struct free_area *area, int migratetype)
> > -{
> > -	add_to_free_area(page, area, migratetype);
> > -}
> > -#endif
> > -
> >  /* Used for pages which are on another list */
> >  static inline void move_to_free_area(struct page *page, struct free_area *area,
> >  			     int migratetype)
> 
> Looks like add_to_free_area() and add_to_free_area_tail() can be moved to
> mm/page_alloc.c as all users are there now. And the same for struct
> free_area definition (but not declaration).
> 
> > diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> > index c5d62f1c2851..4e4356ba66c7 100644
> > --- a/mm/page_alloc.c
> > +++ b/mm/page_alloc.c
> > @@ -878,6 +878,36 @@ static inline struct capture_control *task_capc(struct zone *zone)
> >  #endif /* CONFIG_COMPACTION */
> >  
> >  /*
> > + * If this is not the largest possible page, check if the buddy
> > + * of the next-highest order is free. If it is, it's possible
> > + * that pages are being freed that will coalesce soon. In case,
> > + * that is happening, add the free page to the tail of the list
> > + * so it's less likely to be used soon and more likely to be merged
> > + * as a higher order page
> > + */
> > +static inline bool
> > +buddy_merge_likely(unsigned long pfn, unsigned long buddy_pfn,
> > +		   struct page *page, unsigned int order)
> > +{
> > +	struct page *higher_page, *higher_buddy;
> > +	unsigned long combined_pfn;
> > +
> > +	if (order >= MAX_ORDER - 2)
> > +		return false;
> > +
> > +	if (!pfn_valid_within(buddy_pfn))
> > +		return false;
> > +
> > +	combined_pfn = buddy_pfn & pfn;
> > +	higher_page = page + (combined_pfn - pfn);
> > +	buddy_pfn = __find_buddy_pfn(combined_pfn, order + 1);
> > +	higher_buddy = higher_page + (buddy_pfn - combined_pfn);
> > +
> > +	return pfn_valid_within(buddy_pfn) &&
> > +	       page_is_buddy(higher_page, higher_buddy, order + 1);
> > +}
> 
> Okay, that's much easier to read.
> 
> > +
> > +/*
> >   * Freeing function for a buddy system allocator.
> >   *
> >   * The concept of a buddy system is to maintain direct-mapped table
> > @@ -906,11 +936,12 @@ static inline void __free_one_page(struct page *page,
> >  		struct zone *zone, unsigned int order,
> >  		int migratetype)
> >  {
> > -	unsigned long combined_pfn;
> > +	struct capture_control *capc = task_capc(zone);
> >  	unsigned long uninitialized_var(buddy_pfn);
> > -	struct page *buddy;
> > +	unsigned long combined_pfn;
> > +	struct free_area *area;
> >  	unsigned int max_order;
> > -	struct capture_control *capc = task_capc(zone);
> > +	struct page *buddy;
> >  
> >  	max_order = min_t(unsigned int, MAX_ORDER, pageblock_order + 1);
> >  
> > @@ -979,35 +1010,12 @@ static inline void __free_one_page(struct page *page,
> >  done_merging:
> >  	set_page_order(page, order);
> >  
> > -	/*
> > -	 * If this is not the largest possible page, check if the buddy
> > -	 * of the next-highest order is free. If it is, it's possible
> > -	 * that pages are being freed that will coalesce soon. In case,
> > -	 * that is happening, add the free page to the tail of the list
> > -	 * so it's less likely to be used soon and more likely to be merged
> > -	 * as a higher order page
> > -	 */
> > -	if ((order < MAX_ORDER-2) && pfn_valid_within(buddy_pfn)
> > -			&& !is_shuffle_order(order)) {
> > -		struct page *higher_page, *higher_buddy;
> > -		combined_pfn = buddy_pfn & pfn;
> > -		higher_page = page + (combined_pfn - pfn);
> > -		buddy_pfn = __find_buddy_pfn(combined_pfn, order + 1);
> > -		higher_buddy = higher_page + (buddy_pfn - combined_pfn);
> > -		if (pfn_valid_within(buddy_pfn) &&
> > -		    page_is_buddy(higher_page, higher_buddy, order + 1)) {
> > -			add_to_free_area_tail(page, &zone->free_area[order],
> > -					      migratetype);
> > -			return;
> > -		}
> > -	}
> > -
> > -	if (is_shuffle_order(order))
> > -		add_to_free_area_random(page, &zone->free_area[order],
> > -				migratetype);
> > +	area = &zone->free_area[order];
> > +	if (is_shuffle_order(order) ? shuffle_pick_tail() :
> > +	    buddy_merge_likely(pfn, buddy_pfn, page, order))
> 
> Too loaded condition to my taste. Maybe
> 
> 	bool to_tail;
> 	...
> 	if (is_shuffle_order(order))
> 		to_tail = shuffle_pick_tail();
> 	else if (buddy_merge_likely(pfn, buddy_pfn, page, order))
> 		to_tail = true;
> 	else
> 		to_tail = false;

I can do that, although I would tweak this slightly and do something more
like:
        if (is_shuffle_order(order))
                to_tail = shuffle_pick_tail();
        else
                to_tail = buddy+_merge_likely(pfn, buddy_pfn, page, order);

> 
> 	if (to_tail)
> 		add_to_free_area_tail(page, area, migratetype);
> 	else
> 		add_to_free_area(page, area, migratetype);
> 
> > +		add_to_free_area_tail(page, area, migratetype);
> >  	else
> > -		add_to_free_area(page, &zone->free_area[order], migratetype);
> > -
> > +		add_to_free_area(page, area, migratetype);
> >  }
> >  
> >  /*
> > diff --git a/mm/shuffle.c b/mm/shuffle.c
> > index 9ba542ecf335..345cb4347455 100644
> > --- a/mm/shuffle.c
> > +++ b/mm/shuffle.c
> > @@ -4,7 +4,6 @@
> >  #include <linux/mm.h>
> >  #include <linux/init.h>
> >  #include <linux/mmzone.h>
> > -#include <linux/random.h>
> >  #include <linux/moduleparam.h>
> >  #include "internal.h"
> >  #include "shuffle.h"
> 
> Why do you move #include <linux/random.h> from .c to .h?
> It's not obvious to me.

Because I had originally put the shuffle logic in an inline function. I
can undo that now as I when back to doing the randomness in the .c
sometime v5 I believe.

> > @@ -190,8 +189,7 @@ struct batched_bit_entropy {
> >  
> >  static DEFINE_PER_CPU(struct batched_bit_entropy, batched_entropy_bool);
> >  
> > -void add_to_free_area_random(struct page *page, struct free_area *area,
> > -		int migratetype)
> > +bool __shuffle_pick_tail(void)
> >  {
> >  	struct batched_bit_entropy *batch;
> >  	unsigned long entropy;
> > @@ -213,8 +211,5 @@ void add_to_free_area_random(struct page *page, struct free_area *area,
> >  	batch->position = position;
> >  	entropy = batch->entropy_bool;
> >  
> > -	if (1ul & (entropy >> position))
> > -		add_to_free_area(page, area, migratetype);
> > -	else
> > -		add_to_free_area_tail(page, area, migratetype);
> > +	return 1ul & (entropy >> position);
> >  }
> > diff --git a/mm/shuffle.h b/mm/shuffle.h
> > index 777a257a0d2f..0723eb97f22f 100644
> > --- a/mm/shuffle.h
> > +++ b/mm/shuffle.h
> > @@ -3,6 +3,7 @@
> >  #ifndef _MM_SHUFFLE_H
> >  #define _MM_SHUFFLE_H
> >  #include <linux/jump_label.h>
> > +#include <linux/random.h>
> >  
> >  /*
> >   * SHUFFLE_ENABLE is called from the command line enabling path, or by
> > @@ -22,6 +23,7 @@ enum mm_shuffle_ctl {
> >  DECLARE_STATIC_KEY_FALSE(page_alloc_shuffle_key);
> >  extern void page_alloc_shuffle(enum mm_shuffle_ctl ctl);
> >  extern void __shuffle_free_memory(pg_data_t *pgdat);
> > +extern bool __shuffle_pick_tail(void);
> >  static inline void shuffle_free_memory(pg_data_t *pgdat)
> >  {
> >  	if (!static_branch_unlikely(&page_alloc_shuffle_key))
> > @@ -43,6 +45,11 @@ static inline bool is_shuffle_order(int order)
> >  		return false;
> >  	return order >= SHUFFLE_ORDER;
> >  }
> > +
> > +static inline bool shuffle_pick_tail(void)
> > +{
> > +	return __shuffle_pick_tail();
> > +}
> 
> I don't see a reason in __shuffle_pick_tail() existing if you call it
> unconditionally.

That is for compilation purposes. The function is not used in the
shuffle_pick_tail below that always returns false.

> >  #else
> >  static inline void shuffle_free_memory(pg_data_t *pgdat)
> >  {
> > @@ -60,5 +67,10 @@ static inline bool is_shuffle_order(int order)
> >  {
> >  	return false;
> >  }
> > +
> > +static inline bool shuffle_pick_tail(void)
> > +{
> > +	return false;
> > +}
> >  #endif
> >  #endif /* _MM_SHUFFLE_H */
> > 
> > 



^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: [PATCH v9 5/8] arm64: Move hugetlb related definitions out of pgtable.h to page-defs.h
  2019-09-09  8:52   ` David Hildenbrand
@ 2019-09-09 15:27     ` Alexander Duyck
  0 siblings, 0 replies; 82+ messages in thread
From: Alexander Duyck @ 2019-09-09 15:27 UTC (permalink / raw)
  To: David Hildenbrand, Alexander Duyck, virtio-dev, kvm, mst,
	catalin.marinas, dave.hansen, linux-kernel, willy, mhocko,
	linux-mm, akpm, will, linux-arm-kernel, osalvador
  Cc: yang.zhang.wz, pagupta, konrad.wilk, nitesh, riel, lcapitulino,
	wei.w.wang, aarcange, ying.huang, pbonzini, dan.j.williams,
	fengguang.wu, kirill.shutemov

On Mon, 2019-09-09 at 10:52 +0200, David Hildenbrand wrote:
> On 07.09.19 19:25, Alexander Duyck wrote:
> > From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> > 
> > Move the static definition for things such as HUGETLB_PAGE_ORDER out of
> > asm/pgtable.h and place it in page-defs.h. By doing this the includes
> > become much easier to deal with as currently arm64 is the only architecture
> > that didn't include this definition in the asm/page.h file or a file
> > included by it.
> > 
> > It also makes logical sense as PAGE_SHIFT was already defined in
> > page-defs.h so now we also have HPAGE_SHIFT defined there as well.
> > 
> > Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> > ---
> >  arch/arm64/include/asm/page-def.h |    9 +++++++++
> >  arch/arm64/include/asm/pgtable.h  |    9 ---------
> >  2 files changed, 9 insertions(+), 9 deletions(-)
> > 
> > diff --git a/arch/arm64/include/asm/page-def.h b/arch/arm64/include/asm/page-def.h
> > index f99d48ecbeef..1c5b079e2482 100644
> > --- a/arch/arm64/include/asm/page-def.h
> > +++ b/arch/arm64/include/asm/page-def.h
> > @@ -20,4 +20,13 @@
> >  #define CONT_SIZE		(_AC(1, UL) << (CONT_SHIFT + PAGE_SHIFT))
> >  #define CONT_MASK		(~(CONT_SIZE-1))
> >  
> > +/*
> > + * Hugetlb definitions.
> > + */
> > +#define HUGE_MAX_HSTATE		4
> > +#define HPAGE_SHIFT		PMD_SHIFT
> > +#define HPAGE_SIZE		(_AC(1, UL) << HPAGE_SHIFT)
> > +#define HPAGE_MASK		(~(HPAGE_SIZE - 1))
> > +#define HUGETLB_PAGE_ORDER	(HPAGE_SHIFT - PAGE_SHIFT)
> > +
> 
> I wonder if you should initially limit "config PAGE_REPORTING" to x86
> only and unlock it for the other targets once we actually test it there.
> Or did you test PAGE_REPORTING on other architectures as well?
> 

I haven't, but essentially the effects should be the same regardless of
architecture. In addition since this is a feature that can be
enabled/disabled via QEMU I am not sure there is much harm other than
getting additional testing by enabling for all of the architectures at
once.


^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: [PATCH v9 7/8] virtio-balloon: Pull page poisoning config out of free page hinting
  2019-09-09  8:59   ` David Hildenbrand
@ 2019-09-09 15:31     ` Alexander Duyck
  0 siblings, 0 replies; 82+ messages in thread
From: Alexander Duyck @ 2019-09-09 15:31 UTC (permalink / raw)
  To: David Hildenbrand, Alexander Duyck, virtio-dev, kvm, mst,
	catalin.marinas, dave.hansen, linux-kernel, willy, mhocko,
	linux-mm, akpm, will, linux-arm-kernel, osalvador
  Cc: yang.zhang.wz, pagupta, konrad.wilk, nitesh, riel, lcapitulino,
	wei.w.wang, aarcange, ying.huang, pbonzini, dan.j.williams,
	fengguang.wu, kirill.shutemov

On Mon, 2019-09-09 at 10:59 +0200, David Hildenbrand wrote:
> On 07.09.19 19:26, Alexander Duyck wrote:
> > From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> > 
> > Currently the page poisoning setting wasn't being enabled unless free page
> > hinting was enabled. However we will need the page poisoning tracking logic
> > as well for unused page reporting. As such pull it out and make it a
> > separate bit of config in the probe function.
> > 
> > In addition we can actually wrap the code in a check for NO_SANITY. If we
> > don't care what is actually in the page we can just default to 0 and leave
> > it there.
> > 
> > Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> > ---
> >  drivers/virtio/virtio_balloon.c |   22 +++++++++++++++-------
> >  1 file changed, 15 insertions(+), 7 deletions(-)
> > 
> > diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
> > index 226fbb995fb0..d2547df7de93 100644
> > --- a/drivers/virtio/virtio_balloon.c
> > +++ b/drivers/virtio/virtio_balloon.c
> > @@ -842,7 +842,6 @@ static int virtio_balloon_register_shrinker(struct virtio_balloon *vb)
> >  static int virtballoon_probe(struct virtio_device *vdev)
> >  {
> >  	struct virtio_balloon *vb;
> > -	__u32 poison_val;
> >  	int err;
> >  
> >  	if (!vdev->config->get) {
> > @@ -909,11 +908,18 @@ static int virtballoon_probe(struct virtio_device *vdev)
> >  						  VIRTIO_BALLOON_CMD_ID_STOP);
> >  		spin_lock_init(&vb->free_page_list_lock);
> >  		INIT_LIST_HEAD(&vb->free_page_list);
> > -		if (virtio_has_feature(vdev, VIRTIO_BALLOON_F_PAGE_POISON)) {
> > -			memset(&poison_val, PAGE_POISON, sizeof(poison_val));
> > -			virtio_cwrite(vb->vdev, struct virtio_balloon_config,
> > -				      poison_val, &poison_val);
> > -		}
> > +	}
> > +	if (virtio_has_feature(vdev, VIRTIO_BALLOON_F_PAGE_POISON)) {
> > +		__u32 poison_val;
> > +
> > +		/*
> > +		 * Let hypervisor know that we are expecting a specific
> > +		 * value to be written back in unused pages.
> > +		 */
> 
> "Let the hypervisor know" ... ?
> 
> > +		memset(&poison_val, PAGE_POISON, sizeof(poison_val));
> > +
> > +		virtio_cwrite(vb->vdev, struct virtio_balloon_config,
> > +			      poison_val, &poison_val);
> >  	}
> >  	/*
> >  	 * We continue to use VIRTIO_BALLOON_F_DEFLATE_ON_OOM to decide if a
> > @@ -1014,7 +1020,9 @@ static int virtballoon_restore(struct virtio_device *vdev)
> >  
> >  static int virtballoon_validate(struct virtio_device *vdev)
> >  {
> > -	if (!page_poisoning_enabled())
> > +	/* Notify host if we care about poison value */
> 
> "Tell the host whether we care about poisoned pages." ?
> 
> > +	if (IS_ENABLED(CONFIG_PAGE_POISONING_NO_SANITY) ||
> > +	    !page_poisoning_enabled())
> >  		__virtio_clear_bit(vdev, VIRTIO_BALLOON_F_PAGE_POISON);
> >  
> >  	__virtio_clear_bit(vdev, VIRTIO_F_IOMMU_PLATFORM);
> > 
> 
> Reviewed-by: David Hildenbrand <david@redhat.com>
> 

Thanks. I will update the comments for v10.

- Alex


^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: [PATCH v9 2/8] mm: Adjust shuffle code to allow for future coalescing
  2019-09-09 15:22     ` Alexander Duyck
@ 2019-09-09 15:35       ` Kirill A. Shutemov
  2019-09-09 15:37         ` Alexander Duyck
  0 siblings, 1 reply; 82+ messages in thread
From: Kirill A. Shutemov @ 2019-09-09 15:35 UTC (permalink / raw)
  To: Alexander Duyck
  Cc: Alexander Duyck, virtio-dev, kvm, mst, catalin.marinas, david,
	dave.hansen, linux-kernel, willy, mhocko, linux-mm, akpm, will,
	linux-arm-kernel, osalvador, yang.zhang.wz, pagupta, konrad.wilk,
	nitesh, riel, lcapitulino, wei.w.wang, aarcange, ying.huang,
	pbonzini, dan.j.williams, fengguang.wu, kirill.shutemov

On Mon, Sep 09, 2019 at 08:22:11AM -0700, Alexander Duyck wrote:
> > > +	area = &zone->free_area[order];
> > > +	if (is_shuffle_order(order) ? shuffle_pick_tail() :
> > > +	    buddy_merge_likely(pfn, buddy_pfn, page, order))
> > 
> > Too loaded condition to my taste. Maybe
> > 
> > 	bool to_tail;
> > 	...
> > 	if (is_shuffle_order(order))
> > 		to_tail = shuffle_pick_tail();
> > 	else if (buddy_merge_likely(pfn, buddy_pfn, page, order))
> > 		to_tail = true;
> > 	else
> > 		to_tail = false;
> 
> I can do that, although I would tweak this slightly and do something more
> like:
>         if (is_shuffle_order(order))
>                 to_tail = shuffle_pick_tail();
>         else
>                 to_tail = buddy+_merge_likely(pfn, buddy_pfn, page, order);

Okay. Looks fine.

> > 	if (to_tail)
> > 		add_to_free_area_tail(page, area, migratetype);
> > 	else
> > 		add_to_free_area(page, area, migratetype);
> > 
> > > +		add_to_free_area_tail(page, area, migratetype);
> > >  	else
> > > -		add_to_free_area(page, &zone->free_area[order], migratetype);
> > > -
> > > +		add_to_free_area(page, area, migratetype);
> > >  }
> > >  
> > >  /*
> > > diff --git a/mm/shuffle.c b/mm/shuffle.c
> > > index 9ba542ecf335..345cb4347455 100644
> > > --- a/mm/shuffle.c
> > > +++ b/mm/shuffle.c
> > > @@ -4,7 +4,6 @@
> > >  #include <linux/mm.h>
> > >  #include <linux/init.h>
> > >  #include <linux/mmzone.h>
> > > -#include <linux/random.h>
> > >  #include <linux/moduleparam.h>
> > >  #include "internal.h"
> > >  #include "shuffle.h"
> > 
> > Why do you move #include <linux/random.h> from .c to .h?
> > It's not obvious to me.
> 
> Because I had originally put the shuffle logic in an inline function. I
> can undo that now as I when back to doing the randomness in the .c
> sometime v5 I believe.

Yes, please. It's needless change now.

> 
> > > @@ -190,8 +189,7 @@ struct batched_bit_entropy {
> > >  
> > >  static DEFINE_PER_CPU(struct batched_bit_entropy, batched_entropy_bool);
> > >  
> > > -void add_to_free_area_random(struct page *page, struct free_area *area,
> > > -		int migratetype)
> > > +bool __shuffle_pick_tail(void)
> > >  {
> > >  	struct batched_bit_entropy *batch;
> > >  	unsigned long entropy;
> > > @@ -213,8 +211,5 @@ void add_to_free_area_random(struct page *page, struct free_area *area,
> > >  	batch->position = position;
> > >  	entropy = batch->entropy_bool;
> > >  
> > > -	if (1ul & (entropy >> position))
> > > -		add_to_free_area(page, area, migratetype);
> > > -	else
> > > -		add_to_free_area_tail(page, area, migratetype);
> > > +	return 1ul & (entropy >> position);
> > >  }
> > > diff --git a/mm/shuffle.h b/mm/shuffle.h
> > > index 777a257a0d2f..0723eb97f22f 100644
> > > --- a/mm/shuffle.h
> > > +++ b/mm/shuffle.h
> > > @@ -3,6 +3,7 @@
> > >  #ifndef _MM_SHUFFLE_H
> > >  #define _MM_SHUFFLE_H
> > >  #include <linux/jump_label.h>
> > > +#include <linux/random.h>
> > >  
> > >  /*
> > >   * SHUFFLE_ENABLE is called from the command line enabling path, or by
> > > @@ -22,6 +23,7 @@ enum mm_shuffle_ctl {
> > >  DECLARE_STATIC_KEY_FALSE(page_alloc_shuffle_key);
> > >  extern void page_alloc_shuffle(enum mm_shuffle_ctl ctl);
> > >  extern void __shuffle_free_memory(pg_data_t *pgdat);
> > > +extern bool __shuffle_pick_tail(void);
> > >  static inline void shuffle_free_memory(pg_data_t *pgdat)
> > >  {
> > >  	if (!static_branch_unlikely(&page_alloc_shuffle_key))
> > > @@ -43,6 +45,11 @@ static inline bool is_shuffle_order(int order)
> > >  		return false;
> > >  	return order >= SHUFFLE_ORDER;
> > >  }
> > > +
> > > +static inline bool shuffle_pick_tail(void)
> > > +{
> > > +	return __shuffle_pick_tail();
> > > +}
> > 
> > I don't see a reason in __shuffle_pick_tail() existing if you call it
> > unconditionally.
> 
> That is for compilation purposes. The function is not used in the
> shuffle_pick_tail below that always returns false.

Wouldn't it be the same if you rename __shuffle_pick_tail() to
shuffle_pick_tail() and put its declaration under the same #ifdef?

-- 
 Kirill A. Shutemov

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: [PATCH v9 2/8] mm: Adjust shuffle code to allow for future coalescing
  2019-09-09 15:35       ` Kirill A. Shutemov
@ 2019-09-09 15:37         ` Alexander Duyck
  0 siblings, 0 replies; 82+ messages in thread
From: Alexander Duyck @ 2019-09-09 15:37 UTC (permalink / raw)
  To: Kirill A. Shutemov
  Cc: Alexander Duyck, virtio-dev, kvm, mst, catalin.marinas, david,
	dave.hansen, linux-kernel, willy, mhocko, linux-mm, akpm, will,
	linux-arm-kernel, osalvador, yang.zhang.wz, pagupta, konrad.wilk,
	nitesh, riel, lcapitulino, wei.w.wang, aarcange, ying.huang,
	pbonzini, dan.j.williams, fengguang.wu, kirill.shutemov

On Mon, 2019-09-09 at 18:35 +0300, Kirill A. Shutemov wrote:
> On Mon, Sep 09, 2019 at 08:22:11AM -0700, Alexander Duyck wrote:
> > > > +	area = &zone->free_area[order];
> > > > +	if (is_shuffle_order(order) ? shuffle_pick_tail() :
> > > > +	    buddy_merge_likely(pfn, buddy_pfn, page, order))
> > > 
> > > Too loaded condition to my taste. Maybe
> > > 
> > > 	bool to_tail;
> > > 	...
> > > 	if (is_shuffle_order(order))
> > > 		to_tail = shuffle_pick_tail();
> > > 	else if (buddy_merge_likely(pfn, buddy_pfn, page, order))
> > > 		to_tail = true;
> > > 	else
> > > 		to_tail = false;
> > 
> > I can do that, although I would tweak this slightly and do something more
> > like:
> >         if (is_shuffle_order(order))
> >                 to_tail = shuffle_pick_tail();
> >         else
> >                 to_tail = buddy+_merge_likely(pfn, buddy_pfn, page, order);
> 
> Okay. Looks fine.
> 
> > > 	if (to_tail)
> > > 		add_to_free_area_tail(page, area, migratetype);
> > > 	else
> > > 		add_to_free_area(page, area, migratetype);
> > > 
> > > > +		add_to_free_area_tail(page, area, migratetype);
> > > >  	else
> > > > -		add_to_free_area(page, &zone->free_area[order], migratetype);
> > > > -
> > > > +		add_to_free_area(page, area, migratetype);
> > > >  }
> > > >  
> > > >  /*
> > > > diff --git a/mm/shuffle.c b/mm/shuffle.c
> > > > index 9ba542ecf335..345cb4347455 100644
> > > > --- a/mm/shuffle.c
> > > > +++ b/mm/shuffle.c
> > > > @@ -4,7 +4,6 @@
> > > >  #include <linux/mm.h>
> > > >  #include <linux/init.h>
> > > >  #include <linux/mmzone.h>
> > > > -#include <linux/random.h>
> > > >  #include <linux/moduleparam.h>
> > > >  #include "internal.h"
> > > >  #include "shuffle.h"
> > > 
> > > Why do you move #include <linux/random.h> from .c to .h?
> > > It's not obvious to me.
> > 
> > Because I had originally put the shuffle logic in an inline function. I
> > can undo that now as I when back to doing the randomness in the .c
> > sometime v5 I believe.
> 
> Yes, please. It's needless change now.
> 
> > > > @@ -190,8 +189,7 @@ struct batched_bit_entropy {
> > > >  
> > > >  static DEFINE_PER_CPU(struct batched_bit_entropy, batched_entropy_bool);
> > > >  
> > > > -void add_to_free_area_random(struct page *page, struct free_area *area,
> > > > -		int migratetype)
> > > > +bool __shuffle_pick_tail(void)
> > > >  {
> > > >  	struct batched_bit_entropy *batch;
> > > >  	unsigned long entropy;
> > > > @@ -213,8 +211,5 @@ void add_to_free_area_random(struct page *page, struct free_area *area,
> > > >  	batch->position = position;
> > > >  	entropy = batch->entropy_bool;
> > > >  
> > > > -	if (1ul & (entropy >> position))
> > > > -		add_to_free_area(page, area, migratetype);
> > > > -	else
> > > > -		add_to_free_area_tail(page, area, migratetype);
> > > > +	return 1ul & (entropy >> position);
> > > >  }
> > > > diff --git a/mm/shuffle.h b/mm/shuffle.h
> > > > index 777a257a0d2f..0723eb97f22f 100644
> > > > --- a/mm/shuffle.h
> > > > +++ b/mm/shuffle.h
> > > > @@ -3,6 +3,7 @@
> > > >  #ifndef _MM_SHUFFLE_H
> > > >  #define _MM_SHUFFLE_H
> > > >  #include <linux/jump_label.h>
> > > > +#include <linux/random.h>
> > > >  
> > > >  /*
> > > >   * SHUFFLE_ENABLE is called from the command line enabling path, or by
> > > > @@ -22,6 +23,7 @@ enum mm_shuffle_ctl {
> > > >  DECLARE_STATIC_KEY_FALSE(page_alloc_shuffle_key);
> > > >  extern void page_alloc_shuffle(enum mm_shuffle_ctl ctl);
> > > >  extern void __shuffle_free_memory(pg_data_t *pgdat);
> > > > +extern bool __shuffle_pick_tail(void);
> > > >  static inline void shuffle_free_memory(pg_data_t *pgdat)
> > > >  {
> > > >  	if (!static_branch_unlikely(&page_alloc_shuffle_key))
> > > > @@ -43,6 +45,11 @@ static inline bool is_shuffle_order(int order)
> > > >  		return false;
> > > >  	return order >= SHUFFLE_ORDER;
> > > >  }
> > > > +
> > > > +static inline bool shuffle_pick_tail(void)
> > > > +{
> > > > +	return __shuffle_pick_tail();
> > > > +}
> > > 
> > > I don't see a reason in __shuffle_pick_tail() existing if you call it
> > > unconditionally.
> > 
> > That is for compilation purposes. The function is not used in the
> > shuffle_pick_tail below that always returns false.
> 
> Wouldn't it be the same if you rename __shuffle_pick_tail() to
> shuffle_pick_tail() and put its declaration under the same #ifdef?
> 

Yeah I guess I can do that. I'll update that for v10.

Thanks.

- Alex


^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: [PATCH v9 6/8] mm: Introduce Reported pages
  2019-09-09 14:42   ` Kirill A. Shutemov
@ 2019-09-09 16:25     ` Alexander Duyck
  2019-09-09 16:33       ` Kirill A. Shutemov
  0 siblings, 1 reply; 82+ messages in thread
From: Alexander Duyck @ 2019-09-09 16:25 UTC (permalink / raw)
  To: Kirill A. Shutemov, Alexander Duyck
  Cc: virtio-dev, kvm, mst, catalin.marinas, david, dave.hansen,
	linux-kernel, willy, mhocko, linux-mm, akpm, will,
	linux-arm-kernel, osalvador, yang.zhang.wz, pagupta, konrad.wilk,
	nitesh, riel, lcapitulino, wei.w.wang, aarcange, ying.huang,
	pbonzini, dan.j.williams, fengguang.wu, kirill.shutemov

On Mon, 2019-09-09 at 17:42 +0300, Kirill A. Shutemov wrote:
> On Sat, Sep 07, 2019 at 10:25:53AM -0700, Alexander Duyck wrote:
> > From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> > 
> > In order to pave the way for free page reporting in virtualized
> > environments we will need a way to get pages out of the free lists and
> > identify those pages after they have been returned. To accomplish this,
> > this patch adds the concept of a Reported Buddy, which is essentially
> > meant to just be the Uptodate flag used in conjunction with the Buddy
> > page type.
> > 
> > It adds a set of pointers we shall call "boundary" which represents the
> > upper boundary between the unreported and reported pages. The general idea
> > is that in order for a page to cross from one side of the boundary to the
> > other it will need to go through the reporting process. Ultimately a
> > free_list has been fully processed when the boundary has been moved from
> > the tail all they way up to occupying the first entry in the list.
> > 
> > Doing this we should be able to make certain that we keep the reported
> > pages as one contiguous block in each free list. This will allow us to
> > efficiently manipulate the free lists whenever we need to go in and start
> > sending reports to the hypervisor that there are new pages that have been
> > freed and are no longer in use.
> > 
> > An added advantage to this approach is that we should be reducing the
> > overall memory footprint of the guest as it will be more likely to recycle
> > warm pages versus trying to allocate the reported pages that were likely
> > evicted from the guest memory.
> > 
> > Since we will only be reporting one zone at a time we keep the boundary
> > limited to being defined for just the zone we are currently reporting pages
> > from. Doing this we can keep the number of additional pointers needed quite
> > small. To flag that the boundaries are in place we use a single bit
> > in the zone to indicate that reporting and the boundaries are active.
> > 
> > The determination of when to start reporting is based on the tracking of
> > the number of free pages in a given area versus the number of reported
> > pages in that area. We keep track of the number of reported pages per
> > free_area in a separate zone specific area. We do this to avoid modifying
> > the free_area structure as this can lead to false sharing for the highest
> > order with the zone lock which leads to a noticeable performance
> > degradation.
> > 
> > Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> > ---
> >  include/linux/mmzone.h         |   52 +++++-
> >  include/linux/page-flags.h     |   11 +
> >  include/linux/page_reporting.h |  178 ++++++++++++++++++++
> >  mm/Kconfig                     |    5 +
> >  mm/Makefile                    |    1 
> >  mm/memory_hotplug.c            |    1 
> >  mm/page_alloc.c                |  115 ++++++++++++-
> >  mm/page_reporting.c            |  358 ++++++++++++++++++++++++++++++++++++++++
> >  8 files changed, 711 insertions(+), 10 deletions(-)
> >  create mode 100644 include/linux/page_reporting.h
> >  create mode 100644 mm/page_reporting.c
> > 
> > diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
> > index 2ddf1f1971c0..4b2c44d7e266 100644
> > --- a/include/linux/mmzone.h
> > +++ b/include/linux/mmzone.h
> > @@ -463,6 +463,14 @@ struct zone {
> >  	seqlock_t		span_seqlock;
> >  #endif
> >  
> > +#ifdef CONFIG_PAGE_REPORTING
> > +	/*
> > +	 * Pointer to reported page tracking statistics array. The size of
> > +	 * the array is MAX_ORDER - PAGE_REPORTING_MIN_ORDER. NULL when
> > +	 * unused page reporting is not present.
> > +	 */
> > +	unsigned long		*reported_pages;
> > +#endif
> >  	int initialized;
> >  
> >  	/* Write-intensive fields used from the page allocator */
> > @@ -538,6 +546,14 @@ enum zone_flags {
> >  	ZONE_BOOSTED_WATERMARK,		/* zone recently boosted watermarks.
> >  					 * Cleared when kswapd is woken.
> >  					 */
> > +	ZONE_PAGE_REPORTING_REQUESTED,	/* zone enabled page reporting and has
> > +					 * requested flushing the data out of
> > +					 * higher order pages.
> > +					 */
> > +	ZONE_PAGE_REPORTING_ACTIVE,	/* zone enabled page reporting and is
> > +					 * activly flushing the data out of
> > +					 * higher order pages.
> > +					 */
> >  };
> >  
> >  static inline unsigned long zone_managed_pages(struct zone *zone)
> > @@ -764,6 +780,8 @@ static inline bool pgdat_is_empty(pg_data_t *pgdat)
> >  	return !pgdat->node_start_pfn && !pgdat->node_spanned_pages;
> >  }
> >  
> > +#include <linux/page_reporting.h>
> > +
> >  /* Used for pages not on another list */
> >  static inline void add_to_free_list(struct page *page, struct zone *zone,
> >  				    unsigned int order, int migratetype)
> > @@ -778,24 +796,48 @@ static inline void add_to_free_list(struct page *page, struct zone *zone,
> >  static inline void add_to_free_list_tail(struct page *page, struct zone *zone,
> >  					 unsigned int order, int migratetype)
> >  {
> > -	struct free_area *area = &zone->free_area[order];
> > +	struct list_head *tail = get_unreported_tail(zone, order, migratetype);
> >  
> > -	list_add_tail(&page->lru, &area->free_list[migratetype]);
> > -	area->nr_free++;
> > +	/*
> > +	 * To prevent the unreported pages from being interleaved with the
> > +	 * reported ones while we are actively processing pages we will use
> > +	 * the head of the reported pages to determine the tail of the free
> > +	 * list.
> > +	 */
> > +	list_add_tail(&page->lru, tail);
> > +	zone->free_area[order].nr_free++;
> >  }
> >  
> >  /* Used for pages which are on another list */
> >  static inline void move_to_free_list(struct page *page, struct zone *zone,
> >  				     unsigned int order, int migratetype)
> >  {
> > -	struct free_area *area = &zone->free_area[order];
> > +	struct list_head *tail = get_unreported_tail(zone, order, migratetype);
> > +
> > +	/*
> > +	 * We must get the tail for our target list before moving the page on
> > +	 * the reported list as we will possibly be replacing the tail page of
> > +	 * the list with our current page if it is reported.
> > +	 */
> > +	if (unlikely(PageReported(page)))
> > +		move_page_to_reported_list(page, zone, migratetype);
> >  
> > -	list_move(&page->lru, &area->free_list[migratetype]);
> > +	/*
> > +	 * To prevent unreported pages from being mixed with the reported
> > +	 * ones we add pages to the tail of the list. By doing this the function
> > +	 * above can either label them as included in the reported list or not
> > +	 * and the result will be consistent.
> > +	 */
> > +	list_move_tail(&page->lru, tail);
> >  }
> >  
> >  static inline void del_page_from_free_list(struct page *page, struct zone *zone,
> >  					   unsigned int order)
> >  {
> > +	/* remove page from reported list, and clear reported state */
> > +	if (unlikely(PageReported(page)))
> > +		del_page_from_reported_list(page, zone);
> > +
> >  	list_del(&page->lru);
> >  	__ClearPageBuddy(page);
> >  	set_page_private(page, 0);
> > diff --git a/include/linux/page-flags.h b/include/linux/page-flags.h
> > index f91cb8898ff0..759a3b3956f2 100644
> > --- a/include/linux/page-flags.h
> > +++ b/include/linux/page-flags.h
> > @@ -163,6 +163,9 @@ enum pageflags {
> >  
> >  	/* non-lru isolated movable page */
> >  	PG_isolated = PG_reclaim,
> > +
> > +	/* Buddy pages. Used to track which pages have been reported */
> > +	PG_reported = PG_uptodate,
> >  };
> >  
> >  #ifndef __GENERATING_BOUNDS_H
> > @@ -432,6 +435,14 @@ static inline bool set_hwpoison_free_buddy_page(struct page *page)
> >  #endif
> >  
> >  /*
> > + * PageReported() is used to track reported free pages within the Buddy
> > + * allocator. We can use the non-atomic version of the test and set
> > + * operations as both should be shielded with the zone lock to prevent
> > + * any possible races on the setting or clearing of the bit.
> > + */
> > +__PAGEFLAG(Reported, reported, PF_NO_COMPOUND)
> > +
> > +/*
> >   * On an anonymous page mapped into a user virtual memory area,
> >   * page->mapping points to its anon_vma, not to a struct address_space;
> >   * with the PAGE_MAPPING_ANON bit set to distinguish it.  See rmap.h.
> > diff --git a/include/linux/page_reporting.h b/include/linux/page_reporting.h
> > new file mode 100644
> > index 000000000000..836033ca237b
> > --- /dev/null
> > +++ b/include/linux/page_reporting.h
> > @@ -0,0 +1,178 @@
> > +/* SPDX-License-Identifier: GPL-2.0 */
> > +#ifndef _LINUX_PAGE_REPORTING_H
> > +#define _LINUX_PAGE_REPORTING_H
> > +
> > +#include <linux/mmzone.h>
> > +#include <linux/jump_label.h>
> > +#include <linux/pageblock-flags.h>
> > +
> > +#define PAGE_REPORTING_MIN_ORDER	pageblock_order
> > +#define PAGE_REPORTING_HWM		32
> > +
> > +#ifdef CONFIG_PAGE_REPORTING
> > +struct page_reporting_dev_info {
> > +	/* function that alters pages to make them "reported" */
> > +	void (*report)(struct page_reporting_dev_info *phdev,
> > +		       unsigned int nents);
> > +
> > +	/* scatterlist containing pages to be processed */
> > +	struct scatterlist *sg;
> > +
> > +	/*
> > +	 * Upper limit on the number of pages that the react function
> > +	 * expects to be placed into the batch list to be processed.
> > +	 */
> > +	unsigned long capacity;
> > +
> > +	/* work struct for processing reports */
> > +	struct delayed_work work;
> > +
> > +	/*
> > +	 * The number of zones requesting reporting, plus one additional if
> > +	 * processing thread is active.
> > +	 */
> > +	atomic_t refcnt;
> > +};
> > +
> > +/* Boundary functions */
> > +struct list_head *__page_reporting_get_boundary(unsigned int order,
> > +						int migratetype);
> > +void page_reporting_del_from_boundary(struct page *page);
> > +void page_reporting_add_to_boundary(struct page *page, int migratetype);
> > +void page_reporting_move_to_boundary(struct page *page, struct zone *zone,
> > +				     int migratetype);
> > +
> > +/* Reported page accessors, defined in page_alloc.c */
> > +struct page *get_unreported_page(struct zone *zone, unsigned int order,
> > +				 int migratetype);
> > +void free_reported_page(struct page *page, unsigned int order);
> > +
> > +/* Tear-down and bring-up for page reporting devices */
> > +void page_reporting_shutdown(struct page_reporting_dev_info *phdev);
> > +int page_reporting_startup(struct page_reporting_dev_info *phdev);
> > +
> > +void __page_reporting_free_stats(struct zone *zone);
> > +void __page_reporting_request(struct zone *zone);
> > +
> > +static inline void __del_page_from_reported_list(struct page *page,
> > +						 struct zone *zone)
> > +{
> > +	/* page_private will contain the page order, so just use it directly */
> > +	zone->reported_pages[page_private(page) - PAGE_REPORTING_MIN_ORDER]--;
> > +
> > +	/* clear the flag so we can report on it when it returns */
> > +	__ClearPageReported(page);
> > +}
> > +#endif /* CONFIG_PAGE_REPORTING */
> > +
> > +/*
> > + * Method for obtaining the tail of the free list. Using this allows for
> > + * tail insertions of unreported pages into the region that is currently
> > + * being scanned so as to avoid interleaving reported and unreported pages.
> > + */
> > +static inline struct list_head *
> > +get_unreported_tail(struct zone *zone, unsigned int order, int migratetype)
> > +{
> > +#ifdef CONFIG_PAGE_REPORTING
> > +	if (order >= PAGE_REPORTING_MIN_ORDER &&
> > +	    test_bit(ZONE_PAGE_REPORTING_ACTIVE, &zone->flags))
> > +		return __page_reporting_get_boundary(order, migratetype);
> > +#endif
> > +	return &zone->free_area[order].free_list[migratetype];
> > +}
> > +
> > +/*
> > + * Functions for adding/removing pages from reported end of list.
> > + * All of them expect the zone lock to be held to maintain
> > + * consistency of the reported list as a subset of the free list.
> > + */
> > +static inline void add_page_to_reported_list(struct page *page,
> > +					     struct zone *zone,
> > +					     int order,
> > +					     int migratetype)
> > +{
> > +#ifdef CONFIG_PAGE_REPORTING
> 
> Instead of ifdefing full body of the helpers, can we have two sets of
> these helpres defined for CONFIG_PAGE_REPORTING and for
> !CONFIG_PAGE_REPORTING cases?
> 
> Or can we get all this working with IS_ENABLED() instead of #ifdef?

I can probably split the helpers and just duplicate them with the ifdef
content stripped.

The problem with IS_ENABLED() is that we are calling functions that don't
exist if page reporting isn't enabled so that would cause build issues.

> > +	/* flag page as reported */
> > +	__SetPageReported(page);
> > +
> > +	/* update areated page accounting */
> > +	zone->reported_pages[order - PAGE_REPORTING_MIN_ORDER]++;
> > +
> > +	/* update boundary of new migratetype and record it */
> > +	page_reporting_add_to_boundary(page, migratetype);
> > +#endif
> > +}
> > +
> > +static inline void del_page_from_reported_list(struct page *page,
> > +					       struct zone *zone)
> > +{
> > +#ifdef CONFIG_PAGE_REPORTING
> > +	/* push boundary back if we removed the upper boundary */
> > +	if (test_bit(ZONE_PAGE_REPORTING_ACTIVE, &zone->flags))
> > +		page_reporting_del_from_boundary(page);
> > +
> > +	__del_page_from_reported_list(page, zone);
> > +#endif
> > +}
> > +
> > +static inline void move_page_to_reported_list(struct page *page,
> > +					      struct zone *zone,
> > +					      int migratetype)
> > +{
> > +#ifdef CONFIG_PAGE_REPORTING
> > +	page_reporting_move_to_boundary(page, zone, migratetype);
> > +#endif
> > +}
> > +
> > +/* Free reported_pages and reset reported page tracking count to 0 */
> > +static inline void page_reporting_reset(struct zone *zone)
> > +{
> > +#ifdef CONFIG_PAGE_REPORTING
> > +	if (zone->reported_pages)
> > +		__page_reporting_free_stats(zone);
> > +#endif
> > +}
> > +
> > +DECLARE_STATIC_KEY_FALSE(page_reporting_notify_enabled);
> > +/**
> > + * page_reporting_notify_free - Free page notification to start page processing
> > + * @zone: Pointer to current zone of last page processed
> > + * @order: Order of last page added to zone
> > + *
> > + * This function is meant to act as a screener for __page_reporting_request
> > + * which will determine if a give zone has crossed over the high-water mark
> > + * that will justify us beginning page treatment. If we have crossed that
> > + * threshold then it will start the process of pulling some pages and
> > + * placing them in the batch list for treatment.
> > + */
> > +static inline void page_reporting_notify_free(struct zone *zone, int order)
> > +{
> > +#ifdef CONFIG_PAGE_REPORTING
> > +	unsigned long nr_reported;
> > +
> > +	/* Called from hot path in __free_one_page() */
> > +	if (!static_branch_unlikely(&page_reporting_notify_enabled))
> > +		return;
> > +
> > +	/* Limit notifications only to higher order pages */
> > +	if (order < PAGE_REPORTING_MIN_ORDER)
> > +		return;
> > +
> > +	/* Do not bother with tests if we have already requested reporting */
> > +	if (test_bit(ZONE_PAGE_REPORTING_REQUESTED, &zone->flags))
> > +		return;
> 
> How is it not racy wrt page_reporting_fill()? Do we hold zone->lock or
> something?

Yes. This is called at the end of __free_one_page with the zone->lock
held.

> > +
> > +	/* If reported_pages is not populated, assume 0 */
> > +	nr_reported = zone->reported_pages ?
> > +		    zone->reported_pages[order - PAGE_REPORTING_MIN_ORDER] : 0;
> > +
> > +	/* Only request it if we have enough to begin the page reporting */
> > +	if (zone->free_area[order].nr_free < nr_reported + PAGE_REPORTING_HWM)
> > +		return;
> > +
> > +	/* This is slow, but should be called very rarely */
> > +	__page_reporting_request(zone);
> > +#endif
> > +}
> > +#endif /*_LINUX_PAGE_REPORTING_H */
> > diff --git a/mm/Kconfig b/mm/Kconfig
> > index a5dae9a7eb51..be1a5db50df5 100644
> > --- a/mm/Kconfig
> > +++ b/mm/Kconfig
> > @@ -237,6 +237,11 @@ config COMPACTION
> >            linux-mm@kvack.org.
> >  
> >  #
> > +# support for unused page reporting
> > +config PAGE_REPORTING
> > +	bool
> > +
> > +#
> 
> Proper description for the config option?

I can add one. However the feature doesn't do anything without a caller
that makes use of it. I guess it would make sense to enable this for
something such as an out-of-tree module to later use.

> >  # support for page migration
> >  #
> >  config MIGRATION
> > diff --git a/mm/Makefile b/mm/Makefile
> > index d996846697ef..fc4fa17b6c83 100644
> > --- a/mm/Makefile
> > +++ b/mm/Makefile
> > @@ -107,3 +107,4 @@ obj-$(CONFIG_PERCPU_STATS) += percpu-stats.o
> >  obj-$(CONFIG_ZONE_DEVICE) += memremap.o
> >  obj-$(CONFIG_HMM_MIRROR) += hmm.o
> >  obj-$(CONFIG_MEMFD_CREATE) += memfd.o
> > +obj-$(CONFIG_PAGE_REPORTING) += page_reporting.o
> > diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> > index 49f7bf91c25a..cb71a7190682 100644
> > --- a/mm/memory_hotplug.c
> > +++ b/mm/memory_hotplug.c
> > @@ -1613,6 +1613,7 @@ static int __ref __offline_pages(unsigned long start_pfn,
> >  	if (!populated_zone(zone)) {
> >  		zone_pcp_reset(zone);
> >  		build_all_zonelists(NULL);
> > +		page_reporting_reset(zone);
> >  	} else
> >  		zone_pcp_update(zone);
> >  
> > diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> > index f85dc1561b85..615aea24c082 100644
> > --- a/mm/page_alloc.c
> > +++ b/mm/page_alloc.c
> > @@ -68,6 +68,7 @@
> >  #include <linux/lockdep.h>
> >  #include <linux/nmi.h>
> >  #include <linux/psi.h>
> > +#include <linux/page_reporting.h>
> >  
> >  #include <asm/sections.h>
> >  #include <asm/tlbflush.h>
> > @@ -916,7 +917,7 @@ static inline struct capture_control *task_capc(struct zone *zone)
> >  static inline void __free_one_page(struct page *page,
> >  		unsigned long pfn,
> >  		struct zone *zone, unsigned int order,
> > -		int migratetype)
> > +		int migratetype, bool reported)
> >  {
> >  	struct capture_control *capc = task_capc(zone);
> >  	unsigned long uninitialized_var(buddy_pfn);
> > @@ -991,11 +992,20 @@ static inline void __free_one_page(struct page *page,
> >  done_merging:
> >  	set_page_order(page, order);
> >  
> > -	if (is_shuffle_order(order) ? shuffle_pick_tail() :
> > -	    buddy_merge_likely(pfn, buddy_pfn, page, order))
> > +	if (reported ||
> > +	    (is_shuffle_order(order) ? shuffle_pick_tail() :
> > +	     buddy_merge_likely(pfn, buddy_pfn, page, order)))
> >  		add_to_free_list_tail(page, zone, order, migratetype);
> >  	else
> >  		add_to_free_list(page, zone, order, migratetype);
> > +
> > +	/*
> > +	 * No need to notify on a reported page as the total count of
> > +	 * unreported pages will not have increased since we have essentially
> > +	 * merged the reported page with one or more unreported pages.
> > +	 */
> > +	if (!reported)
> > +		page_reporting_notify_free(zone, order);
> >  }
> >  
> >  /*
> > @@ -1306,7 +1316,7 @@ static void free_pcppages_bulk(struct zone *zone, int count,
> >  		if (unlikely(isolated_pageblocks))
> >  			mt = get_pageblock_migratetype(page);
> >  
> > -		__free_one_page(page, page_to_pfn(page), zone, 0, mt);
> > +		__free_one_page(page, page_to_pfn(page), zone, 0, mt, false);
> >  		trace_mm_page_pcpu_drain(page, 0, mt);
> >  	}
> >  	spin_unlock(&zone->lock);
> > @@ -1322,7 +1332,7 @@ static void free_one_page(struct zone *zone,
> >  		is_migrate_isolate(migratetype))) {
> >  		migratetype = get_pfnblock_migratetype(page, pfn);
> >  	}
> > -	__free_one_page(page, pfn, zone, order, migratetype);
> > +	__free_one_page(page, pfn, zone, order, migratetype, false);
> >  	spin_unlock(&zone->lock);
> >  }
> >  
> > @@ -2184,6 +2194,101 @@ struct page *__rmqueue_smallest(struct zone *zone, unsigned int order,
> >  	return NULL;
> >  }
> >  
> > +#ifdef CONFIG_PAGE_REPORTING
> > +/**
> > + * free_reported_page - Return a now-reported page back where we got it
> > + * @page: Page that was reported
> > + * @order: Order of the reported page
> > + *
> > + * This function will pull the migratetype and order information out
> > + * of the page and attempt to return it where it found it. If the page
> > + * is added to the free list without changes we will mark it as being
> > + * reported.
> > + */
> > +void free_reported_page(struct page *page, unsigned int order)
> > +{
> > +	struct zone *zone = page_zone(page);
> > +	unsigned long pfn;
> > +	unsigned int mt;
> > +
> > +	/* zone lock should be held when this function is called */
> > +	lockdep_assert_held(&zone->lock);
> > +
> > +	pfn = page_to_pfn(page);
> > +	mt = get_pfnblock_migratetype(page, pfn);
> > +	__free_one_page(page, pfn, zone, order, mt, true);
> > +
> > +	/*
> > +	 * If page was not comingled with another page we can consider
> > +	 * the result to be "reported" since part of the page hasn't been
> > +	 * modified, otherwise we would need to report on the new larger
> > +	 * page.
> > +	 */
> > +	if (PageBuddy(page) && page_order(page) == order)
> > +		add_page_to_reported_list(page, zone, order, mt);
> > +}
> > +
> > +/**
> > + * get_unreported_page - Pull an unreported page from the free_list
> > + * @zone: Zone to draw pages from
> > + * @order: Order to draw pages from
> > + * @mt: Migratetype to draw pages from
> > + *
> > + * This function will obtain a page from the free list. It will start by
> > + * attempting to pull from the tail of the free list and if that is already
> > + * reported on it will instead pull the head if that is unreported.
> > + *
> > + * The page will have the migrate type and order stored in the page
> > + * metadata. While being processed the page will not be avaialble for
> > + * allocation.
> > + *
> > + * Return: page pointer if raw page found, otherwise NULL
> > + */
> > +struct page *get_unreported_page(struct zone *zone, unsigned int order, int mt)
> > +{
> > +	struct list_head *tail = get_unreported_tail(zone, order, mt);
> > +	struct free_area *area = &(zone->free_area[order]);
> > +	struct list_head *list = &area->free_list[mt];
> > +	struct page *page;
> > +
> > +	/* zone lock should be held when this function is called */
> > +	lockdep_assert_held(&zone->lock);
> > +
> > +	/* Find a page of the appropriate size in the preferred list */
> > +	page = list_last_entry(tail, struct page, lru);
> > +	list_for_each_entry_from_reverse(page, list, lru) {
> > +		/* If we entered this loop then the "raw" list isn't empty */
> > +
> > +		/* If the page is reported try the head of the list */
> > +		if (PageReported(page)) {
> > +			page = list_first_entry(list, struct page, lru);
> > +
> > +			/*
> > +			 * If both the head and tail are reported then reset
> > +			 * the boundary so that we read as an empty list
> > +			 * next time and bail out.
> > +			 */
> > +			if (PageReported(page)) {
> > +				page_reporting_add_to_boundary(page, mt);
> > +				break;
> > +			}
> > +		}
> > +
> > +		del_page_from_free_list(page, zone, order);
> > +
> > +		/*
> > +		 * Page will not be available for allocation while we are
> > +		 * processing it so update the freepage state.
> > +		 */
> > +		__mod_zone_freepage_state(zone, -(1 << order), mt);
> > +
> > +		return page;
> > +	}
> > +
> > +	return NULL;
> > +}
> > +#endif /* CONFIG_PAGE_REPORTING */
> > +
> >  /*
> >   * This array describes the order lists are fallen back to when
> >   * the free lists for the desirable migrate type are depleted
> > diff --git a/mm/page_reporting.c b/mm/page_reporting.c
> > new file mode 100644
> > index 000000000000..a59ef53eb0b8
> > --- /dev/null
> > +++ b/mm/page_reporting.c
> > @@ -0,0 +1,358 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +#include <linux/mm.h>
> > +#include <linux/mmzone.h>
> > +#include <linux/page-isolation.h>
> > +#include <linux/gfp.h>
> > +#include <linux/export.h>
> > +#include <linux/delay.h>
> > +#include <linux/slab.h>
> > +#include <linux/scatterlist.h>
> > +#include "internal.h"
> > +
> > +static struct page_reporting_dev_info __rcu *ph_dev_info __read_mostly;
> > +struct list_head **boundary __read_mostly;
> > +
> > +static inline struct list_head **get_boundary_ptr(unsigned int order,
> > +						  unsigned int migratetype)
> > +{
> > +	return boundary +
> > +	       (order - PAGE_REPORTING_MIN_ORDER) * MIGRATE_TYPES + migratetype;
> > +}
> > +
> > +static void page_reporting_reset_boundary(struct zone *zone, unsigned int order,
> > +					  unsigned int migratetype)
> > +{
> > +	struct list_head **tail = get_boundary_ptr(order, migratetype);
> > +
> > +	*tail = &zone->free_area[order].free_list[migratetype];
> > +}
> > +
> > +#define for_each_reporting_migratetype_order(_order, _type) \
> > +	for (_order = MAX_ORDER; _order-- != PAGE_REPORTING_MIN_ORDER;) \
> > +		for (_type = MIGRATE_TYPES; _type--;) \
> > +			if (!is_migrate_isolate(_type))
> > +
> > +static int page_reporting_populate_metadata(struct zone *zone)
> > +{
> > +	unsigned int order, mt;
> > +
> > +	/*
> > +	 * We need to make sure we have somewhere to store the tracking
> > +	 * data for how many reported pages are in the zone. To do that
> > +	 * we need to make certain zone->reported_pages is populated.
> > +	 */
> > +	if (!zone->reported_pages) {
> > +		zone->reported_pages =
> > +			kcalloc(MAX_ORDER - PAGE_REPORTING_MIN_ORDER,
> > +				sizeof(unsigned long),
> > +				GFP_KERNEL);
> > +		if (!zone->reported_pages)
> > +			return -ENOMEM;
> > +	}
> > +
> > +	/* Update boundary data to reflect the zone we are currently working */
> > +	for_each_reporting_migratetype_order(order, mt)
> > +		page_reporting_reset_boundary(zone, order, mt);
> > +
> > +	return 0;
> > +}
> > +
> > +struct list_head *__page_reporting_get_boundary(unsigned int order,
> > +						int migratetype)
> > +{
> > +	return *get_boundary_ptr(order, migratetype);
> > +}
> > +
> > +void page_reporting_del_from_boundary(struct page *page)
> > +{
> > +	unsigned int order = page_private(page);
> > +	int mt = get_pcppage_migratetype(page);
> > +	struct list_head **tail = get_boundary_ptr(order, mt);
> > +
> > +	if (*tail == &page->lru)
> > +		*tail = page->lru.next;
> > +}
> > +
> > +void page_reporting_add_to_boundary(struct page *page, int migratetype)
> > +{
> > +	unsigned int order = page_private(page);
> > +	struct list_head **tail = get_boundary_ptr(order, migratetype);
> > +
> > +	*tail = &page->lru;
> > +	set_pcppage_migratetype(page, migratetype);
> > +}
> > +
> > +void page_reporting_move_to_boundary(struct page *page, struct zone *zone,
> > +				     int dest_mt)
> > +{
> > +	/*
> > +	 * We essentially have two options available to us. The first is to
> > +	 * move the page from the boundary list on one migratetype to the
> > +	 * list for the new migratetype assuming reporting is still active.
> > +	 *
> > +	 * The other option is to clear the reported state of the page as
> > +	 * we will not be adding it to the group of pages that were already
> > +	 * reported. It is cheaper to just rereport such pages then go
> > +	 * through and do a special search to skip over them. If the page
> > +	 * is being moved into isolation we can defer this until the page
> > +	 * comes out of isolation since we do not scan the isolated
> > +	 * migratetype.
> > +	 */
> > +	if (test_bit(ZONE_PAGE_REPORTING_ACTIVE, &zone->flags)) {
> > +		page_reporting_del_from_boundary(page);
> > +		page_reporting_add_to_boundary(page, dest_mt);
> > +	} else if (!is_migrate_isolate(dest_mt)) {
> > +		__del_page_from_reported_list(page, zone);
> > +	}
> > +}
> > +
> > +static unsigned int page_reporting_fill(struct zone *zone,
> > +					struct page_reporting_dev_info *phdev)
> > +{
> > +	struct scatterlist *sg = phdev->sg;
> > +	unsigned int order, mt, count = 0;
> > +
> > +	sg_init_table(phdev->sg, phdev->capacity);
> > +
> > +	for_each_reporting_migratetype_order(order, mt) {
> > +		struct page *page;
> > +
> > +		/*
> > +		 * Pull pages from free list until we have drained
> > +		 * it or we have reached capacity.
> > +		 */
> > +		while ((page = get_unreported_page(zone, order, mt))) {
> > +			sg_set_page(&sg[count], page, PAGE_SIZE << order, 0);
> > +
> > +			if (++count == phdev->capacity)
> > +				return count;
> > +		}
> > +	}
> > +
> > +	/* mark end of scatterlist due to underflow */
> > +	if (count)
> > +		sg_mark_end(&sg[count - 1]);
> > +
> > +	/*
> > +	 * If there are no longer enough free pages to fully populate
> > +	 * the scatterlist, then we can just shut it down for this zone.
> > +	 */
> > +	__clear_bit(ZONE_PAGE_REPORTING_REQUESTED, &zone->flags);
> > +	atomic_dec(&phdev->refcnt);
> > +
> > +	return count;
> > +}
> > +
> > +static void page_reporting_drain(struct page_reporting_dev_info *phdev)
> > +{
> > +	struct scatterlist *sg = phdev->sg;
> > +
> > +	/*
> > +	 * Drain the now reported pages back into their respective
> > +	 * free lists/areas. We assume at least one page is populated.
> > +	 */
> > +	do {
> > +		free_reported_page(sg_page(sg), get_order(sg->length));
> > +	} while (!sg_is_last(sg++));
> > +}
> > +
> > +/*
> > + * The page reporting cycle consists of 4 stages, fill, report, drain, and idle.
> > + * We will cycle through the first 3 stages until we fail to obtain any
> > + * pages, in that case we will switch to idle.
> > + */
> > +static void page_reporting_cycle(struct zone *zone,
> > +				 struct page_reporting_dev_info *phdev)
> > +{
> > +	/*
> > +	 * Guarantee boundaries and stats are populated before we
> > +	 * start placing reported pages in the zone.
> > +	 */
> > +	if (page_reporting_populate_metadata(zone))
> > +		return;
> > +
> > +	spin_lock_irq(&zone->lock);
> > +
> > +	/* set bit indicating boundaries are present */
> > +	__set_bit(ZONE_PAGE_REPORTING_ACTIVE, &zone->flags);
> > +
> > +	do {
> > +		/* Pull pages out of allocator into a scaterlist */
> > +		unsigned int nents = page_reporting_fill(zone, phdev);
> > +
> > +		/* no pages were acquired, give up */
> > +		if (!nents)
> > +			break;
> > +
> > +		spin_unlock_irq(&zone->lock);
> > +
> > +		/* begin processing pages in local list */
> > +		phdev->report(phdev, nents);
> > +
> > +		spin_lock_irq(&zone->lock);
> > +
> > +		/*
> > +		 * We should have a scatterlist of pages that have been
> > +		 * processed. Return them to their original free lists.
> > +		 */
> > +		page_reporting_drain(phdev);
> > +
> > +		/* keep pulling pages till there are none to pull */
> > +	} while (test_bit(ZONE_PAGE_REPORTING_REQUESTED, &zone->flags));
> > +
> > +	/* processing of the zone is complete, we can disable boundaries */
> > +	__clear_bit(ZONE_PAGE_REPORTING_ACTIVE, &zone->flags);
> > +
> > +	spin_unlock_irq(&zone->lock);
> > +}
> > +
> > +static void page_reporting_process(struct work_struct *work)
> > +{
> > +	struct delayed_work *d_work = to_delayed_work(work);
> > +	struct page_reporting_dev_info *phdev =
> > +		container_of(d_work, struct page_reporting_dev_info, work);
> > +	struct zone *zone = first_online_pgdat()->node_zones;
> > +
> > +	do {
> > +		if (test_bit(ZONE_PAGE_REPORTING_REQUESTED, &zone->flags))
> > +			page_reporting_cycle(zone, phdev);
> > +
> > +		/* Move to next zone, if at end of list start over */
> > +		zone = next_zone(zone) ? : first_online_pgdat()->node_zones;
> > +
> > +		/*
> > +		 * As long as refcnt has not reached zero there are still
> > +		 * zones to be processed.
> > +		 */
> > +	} while (atomic_read(&phdev->refcnt));
> > +}
> > +
> > +/* request page reporting on this zone */
> > +void __page_reporting_request(struct zone *zone)
> > +{
> > +	struct page_reporting_dev_info *phdev;
> > +
> > +	rcu_read_lock();
> > +
> > +	/*
> > +	 * We use RCU to protect the ph_dev_info pointer. In almost all
> > +	 * cases this should be present, however in the unlikely case of
> > +	 * a shutdown this will be NULL and we should exit.
> > +	 */
> > +	phdev = rcu_dereference(ph_dev_info);
> > +	if (unlikely(!phdev))
> > +		goto out;
> > +
> > +	/*
> > +	 * We can use separate test and set operations here as there
> > +	 * is nothing else that can set or clear this bit while we are
> > +	 * holding the zone lock. The advantage to doing it this way is
> > +	 * that we don't have to dirty the cacheline unless we are
> > +	 * changing the value.
> > +	 */
> > +	__set_bit(ZONE_PAGE_REPORTING_REQUESTED, &zone->flags);
> > +
> > +	/*
> > +	 * Delay the start of work to allow a sizable queue to
> > +	 * build. For now we are limiting this to running no more
> > +	 * than 10 times per second.
> > +	 */
> > +	if (!atomic_fetch_inc(&phdev->refcnt))
> > +		schedule_delayed_work(&phdev->work, HZ / 10);
> > +out:
> > +	rcu_read_unlock();
> > +}
> > +
> > +void __page_reporting_free_stats(struct zone *zone)
> > +{
> > +	/* free reported_page statisitics */
> > +	kfree(zone->reported_pages);
> > +	zone->reported_pages = NULL;
> > +}
> > +
> > +static DEFINE_MUTEX(page_reporting_mutex);
> > +DEFINE_STATIC_KEY_FALSE(page_reporting_notify_enabled);
> > +
> > +void page_reporting_shutdown(struct page_reporting_dev_info *phdev)
> > +{
> > +	mutex_lock(&page_reporting_mutex);
> > +
> > +	if (rcu_access_pointer(ph_dev_info) == phdev) {
> > +		/* Disable page reporting notification */
> > +		static_branch_disable(&page_reporting_notify_enabled);
> > +		RCU_INIT_POINTER(ph_dev_info, NULL);
> > +		synchronize_rcu();
> > +
> > +		/* Flush any existing work, and lock it out */
> > +		cancel_delayed_work_sync(&phdev->work);
> > +
> > +		/* Free scatterlist */
> > +		kfree(phdev->sg);
> > +		phdev->sg = NULL;
> > +
> > +		/* Free boundaries */
> > +		kfree(boundary);
> > +		boundary = NULL;
> > +	}
> > +
> > +	mutex_unlock(&page_reporting_mutex);
> > +}
> > +EXPORT_SYMBOL_GPL(page_reporting_shutdown);
> > +
> > +int page_reporting_startup(struct page_reporting_dev_info *phdev)
> > +{
> > +	struct zone *zone;
> > +	int err = 0;
> > +
> > +	/* No point in enabling this if it cannot handle any pages */
> > +	if (!phdev->capacity)
> > +		return -EINVAL;
> 
> Looks like a usage error. Maybe WARN_ON()?

I can do that. We shouldn't really be accessing this with that setup
anyway.

> > +
> > +	mutex_lock(&page_reporting_mutex);
> > +
> > +	/* nothing to do if already in use */
> > +	if (rcu_access_pointer(ph_dev_info)) {
> > +		err = -EBUSY;
> > +		goto err_out;
> > +	}
> 
> Again, it's from "something went horribly wrong" category.
> Maybe WARN_ON()?

That one I am not so sure about. Right now we only have one user for the
page reporting interface. My concern is if we ever have more than one we
may experience collisions. The device driver requesting this should
display an error message if it is not able tor register the interface.

> > +
> > +	boundary = kcalloc(MAX_ORDER - PAGE_REPORTING_MIN_ORDER,
> > +			   sizeof(struct list_head *) * MIGRATE_TYPES,
> > +			   GFP_KERNEL);
> 
> Could you comment here on why this size of array is allocated?
> The calculation is not obvious to a reader.

Would something like the following work for you?
        /*
         * Allocate space to store the boundaries for the zone we are
         * actively reporting on. We will need to store one boundary
         * pointer per migratetype, and then we need to have one of these
         * arrays per order for orders greater than or equal to
         * PAGE_REPORTING_MIN_ORDER.
         */


> > +	if (!boundary) {
> > +		err = -ENOMEM;
> > +		goto err_out;
> > +	}
> > +
> > +	/* allocate scatterlist to store pages being reported on */
> > +	phdev->sg = kcalloc(phdev->capacity, sizeof(*phdev->sg), GFP_KERNEL);
> > +	if (!phdev->sg) {
> > +		err = -ENOMEM;
> > +
> > +		kfree(boundary);
> > +		boundary = NULL;
> > +
> > +		goto err_out;
> > +	}
> > +
> > +
> > +	/* initialize refcnt and work structures */
> > +	atomic_set(&phdev->refcnt, 0);
> > +	INIT_DELAYED_WORK(&phdev->work, &page_reporting_process);
> > +
> > +	/* assign device, and begin initial flush of populated zones */
> > +	rcu_assign_pointer(ph_dev_info, phdev);
> > +	for_each_populated_zone(zone) {
> > +		spin_lock_irq(&zone->lock);
> > +		__page_reporting_request(zone);
> > +		spin_unlock_irq(&zone->lock);
> > +	}
> > +
> > +	/* enable page reporting notification */
> > +	static_branch_enable(&page_reporting_notify_enabled);
> > +err_out:
> > +	mutex_unlock(&page_reporting_mutex);
> > +
> > +	return err;
> > +}
> > +EXPORT_SYMBOL_GPL(page_reporting_startup);
> > 
> > 



^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: [PATCH v9 6/8] mm: Introduce Reported pages
  2019-09-09 16:25     ` Alexander Duyck
@ 2019-09-09 16:33       ` Kirill A. Shutemov
  0 siblings, 0 replies; 82+ messages in thread
From: Kirill A. Shutemov @ 2019-09-09 16:33 UTC (permalink / raw)
  To: Alexander Duyck
  Cc: Alexander Duyck, virtio-dev, kvm, mst, catalin.marinas, david,
	dave.hansen, linux-kernel, willy, mhocko, linux-mm, akpm, will,
	linux-arm-kernel, osalvador, yang.zhang.wz, pagupta, konrad.wilk,
	nitesh, riel, lcapitulino, wei.w.wang, aarcange, ying.huang,
	pbonzini, dan.j.williams, fengguang.wu, kirill.shutemov

On Mon, Sep 09, 2019 at 09:25:04AM -0700, Alexander Duyck wrote:
> > Proper description for the config option?
> 
> I can add one. However the feature doesn't do anything without a caller
> that makes use of it. I guess it would make sense to enable this for
> something such as an out-of-tree module to later use.

Description under 'help' section will not make the option user selectable
if you leave 'bool' without description.

> > > +	mutex_lock(&page_reporting_mutex);
> > > +
> > > +	/* nothing to do if already in use */
> > > +	if (rcu_access_pointer(ph_dev_info)) {
> > > +		err = -EBUSY;
> > > +		goto err_out;
> > > +	}
> > 
> > Again, it's from "something went horribly wrong" category.
> > Maybe WARN_ON()?
> 
> That one I am not so sure about. Right now we only have one user for the
> page reporting interface. My concern is if we ever have more than one we
> may experience collisions. The device driver requesting this should
> display an error message if it is not able tor register the interface.

Fair enough.

> > > +	boundary = kcalloc(MAX_ORDER - PAGE_REPORTING_MIN_ORDER,
> > > +			   sizeof(struct list_head *) * MIGRATE_TYPES,
> > > +			   GFP_KERNEL);
> > 
> > Could you comment here on why this size of array is allocated?
> > The calculation is not obvious to a reader.
> 
> Would something like the following work for you?
>         /*
>          * Allocate space to store the boundaries for the zone we are
>          * actively reporting on. We will need to store one boundary
>          * pointer per migratetype, and then we need to have one of these
>          * arrays per order for orders greater than or equal to
>          * PAGE_REPORTING_MIN_ORDER.
>          */

Ack.

-- 
 Kirill A. Shutemov

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: [PATCH v9 2/8] mm: Adjust shuffle code to allow for future coalescing
  2019-09-09  9:47   ` Kirill A. Shutemov
  2019-09-09 15:22     ` Alexander Duyck
@ 2019-09-09 16:43     ` Alexander Duyck
  2019-09-09 17:00       ` Kirill A. Shutemov
  1 sibling, 1 reply; 82+ messages in thread
From: Alexander Duyck @ 2019-09-09 16:43 UTC (permalink / raw)
  To: Kirill A. Shutemov, Alexander Duyck
  Cc: virtio-dev, kvm, mst, catalin.marinas, david, dave.hansen,
	linux-kernel, willy, mhocko, linux-mm, akpm, will,
	linux-arm-kernel, osalvador, yang.zhang.wz, pagupta, konrad.wilk,
	nitesh, riel, lcapitulino, wei.w.wang, aarcange, ying.huang,
	pbonzini, dan.j.williams, fengguang.wu, kirill.shutemov

On Mon, 2019-09-09 at 12:47 +0300, Kirill A. Shutemov wrote:
> On Sat, Sep 07, 2019 at 10:25:20AM -0700, Alexander Duyck wrote:
> > From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> > 
> > Move the head/tail adding logic out of the shuffle code and into the
> > __free_one_page function since ultimately that is where it is really
> > needed anyway. By doing this we should be able to reduce the overhead
> > and can consolidate all of the list addition bits in one spot.
> > 
> > Reviewed-by: Dan Williams <dan.j.williams@intel.com>
> > Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> > ---
> >   include/linux/mmzone.h |   12 --------
> >   mm/page_alloc.c        |   70 +++++++++++++++++++++++++++---------------------
> >   mm/shuffle.c           |    9 +-----
> >   mm/shuffle.h           |   12 ++++++++
> >   4 files changed, 53 insertions(+), 50 deletions(-)
> > 
> > diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
> > index bda20282746b..125f300981c6 100644
> > --- a/include/linux/mmzone.h
> > +++ b/include/linux/mmzone.h
> > @@ -116,18 +116,6 @@ static inline void add_to_free_area_tail(struct page *page, struct free_area *ar
> >        area->nr_free++;
> >   }
> >   
> > -#ifdef CONFIG_SHUFFLE_PAGE_ALLOCATOR
> > -/* Used to preserve page allocation order entropy */
> > -void add_to_free_area_random(struct page *page, struct free_area *area,
> > -             int migratetype);
> > -#else
> > -static inline void add_to_free_area_random(struct page *page,
> > -             struct free_area *area, int migratetype)
> > -{
> > -     add_to_free_area(page, area, migratetype);
> > -}
> > -#endif
> > -
> >   /* Used for pages which are on another list */
> >   static inline void move_to_free_area(struct page *page, struct free_area *area,
> >                             int migratetype)
> 
> Looks like add_to_free_area() and add_to_free_area_tail() can be moved to
> mm/page_alloc.c as all users are there now. And the same for struct
> free_area definition (but not declaration).

This can probably be worked into patch 4 instead of doing it here. I could
pull all the functions that are renamed to _free_list from _free_area into
page_alloc.c and leave behind the ones that remained as _free_area such as
get_page_from_free_area. That should make it easier for me to avoid having
to include page_reporting.h in mmzone.h.

I'm not sure I follow what you are saying about the free_area definition.
It looks like it is a part of the zone structure so I would think it still
needs to be defined in the header.


^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: [PATCH v9 2/8] mm: Adjust shuffle code to allow for future coalescing
  2019-09-09 16:43     ` Alexander Duyck
@ 2019-09-09 17:00       ` Kirill A. Shutemov
  0 siblings, 0 replies; 82+ messages in thread
From: Kirill A. Shutemov @ 2019-09-09 17:00 UTC (permalink / raw)
  To: Alexander Duyck
  Cc: Alexander Duyck, virtio-dev, kvm, mst, catalin.marinas, david,
	dave.hansen, linux-kernel, willy, mhocko, linux-mm, akpm, will,
	linux-arm-kernel, osalvador, yang.zhang.wz, pagupta, konrad.wilk,
	nitesh, riel, lcapitulino, wei.w.wang, aarcange, ying.huang,
	pbonzini, dan.j.williams, fengguang.wu, kirill.shutemov

On Mon, Sep 09, 2019 at 09:43:00AM -0700, Alexander Duyck wrote:
> I'm not sure I follow what you are saying about the free_area definition.
> It looks like it is a part of the zone structure so I would think it still
> needs to be defined in the header.

Yeah, you are right. I didn't noticed this.

-- 
 Kirill A. Shutemov

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: [PATCH v9 3/8] mm: Move set/get_pcppage_migratetype to mmzone.h
  2019-09-09  9:56   ` Kirill A. Shutemov
@ 2019-09-09 18:01     ` Alexander Duyck
  2019-09-09 18:12       ` Alexander Duyck
  0 siblings, 1 reply; 82+ messages in thread
From: Alexander Duyck @ 2019-09-09 18:01 UTC (permalink / raw)
  To: Kirill A. Shutemov, Alexander Duyck
  Cc: virtio-dev, kvm, mst, catalin.marinas, david, dave.hansen,
	linux-kernel, willy, mhocko, linux-mm, akpm, will,
	linux-arm-kernel, osalvador, yang.zhang.wz, pagupta, konrad.wilk,
	nitesh, riel, lcapitulino, wei.w.wang, aarcange, ying.huang,
	pbonzini, dan.j.williams, fengguang.wu, kirill.shutemov

On Mon, 2019-09-09 at 12:56 +0300, Kirill A. Shutemov wrote:
> On Sat, Sep 07, 2019 at 10:25:28AM -0700, Alexander Duyck wrote:
> > From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> > 
> > In order to support page reporting it will be necessary to store and
> > retrieve the migratetype of a page. To enable that I am moving the set and
> > get operations for pcppage_migratetype into the mm/internal.h header so
> > that they can be used outside of the page_alloc.c file.
> > 
> > Reviewed-by: Dan Williams <dan.j.williams@intel.com>
> > Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> 
> I'm not sure that it's great idea to export this functionality beyond
> mm/page_alloc.c without any additional safeguards. How would we avoid to
> messing with ->index when the page is not in the right state of its
> life-cycle. Can we add some VM_BUG_ON()s here?

I am not sure what we would need to check on though. There are essentially
2 cases where we are using this. The first is the percpu page lists so the
value is set either as a result of __rmqueue_smallest or
free_unref_page_prepare. The second one which hasn't been added yet is for
the Reported pages case which I add with patch 6.

When I use it for page reporting I am essentially using the Reported flag
to identify what pages in the buddy list will have this value set versus
those that may not. I didn't explicitly define it that way, but that is
how I am using it so that the value cannot be trusted unless the Reported
flag is set.


^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: [PATCH v9 3/8] mm: Move set/get_pcppage_migratetype to mmzone.h
  2019-09-09 18:01     ` Alexander Duyck
@ 2019-09-09 18:12       ` Alexander Duyck
  0 siblings, 0 replies; 82+ messages in thread
From: Alexander Duyck @ 2019-09-09 18:12 UTC (permalink / raw)
  To: Kirill A. Shutemov, Alexander Duyck
  Cc: virtio-dev, kvm, mst, catalin.marinas, david, dave.hansen,
	linux-kernel, willy, mhocko, linux-mm, akpm, will,
	linux-arm-kernel, osalvador, yang.zhang.wz, pagupta, konrad.wilk,
	nitesh, riel, lcapitulino, wei.w.wang, aarcange, ying.huang,
	pbonzini, dan.j.williams, fengguang.wu, kirill.shutemov

On Mon, 2019-09-09 at 11:01 -0700, Alexander Duyck wrote:
> On Mon, 2019-09-09 at 12:56 +0300, Kirill A. Shutemov wrote:
> > On Sat, Sep 07, 2019 at 10:25:28AM -0700, Alexander Duyck wrote:
> > > From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> > > 
> > > In order to support page reporting it will be necessary to store and
> > > retrieve the migratetype of a page. To enable that I am moving the set and
> > > get operations for pcppage_migratetype into the mm/internal.h header so
> > > that they can be used outside of the page_alloc.c file.
> > > 
> > > Reviewed-by: Dan Williams <dan.j.williams@intel.com>
> > > Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> > 
> > I'm not sure that it's great idea to export this functionality beyond
> > mm/page_alloc.c without any additional safeguards. How would we avoid to
> > messing with ->index when the page is not in the right state of its
> > life-cycle. Can we add some VM_BUG_ON()s here?
> 
> I am not sure what we would need to check on though. There are essentially
> 2 cases where we are using this. The first is the percpu page lists so the
> value is set either as a result of __rmqueue_smallest or
> free_unref_page_prepare. The second one which hasn't been added yet is for
> the Reported pages case which I add with patch 6.
> 
> When I use it for page reporting I am essentially using the Reported flag
> to identify what pages in the buddy list will have this value set versus
> those that may not. I didn't explicitly define it that way, but that is
> how I am using it so that the value cannot be trusted unless the Reported
> flag is set.

I guess the alternative would be to just treat the ->index value as the
index within the boundary array, and not use the per-cpu list functions.
Doing that might make things a bit more clear since all we are really
doing is storing the index into the boundary list the page is contained
in. I could probably combine the value of order and migratetype and save
myself a few cycles in the process by just saving the index into the array
directly.


^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: [PATCH v9 1/8] mm: Add per-cpu logic to page shuffling
  2019-09-09 15:11     ` Alexander Duyck
@ 2019-09-10 12:11       ` Michal Hocko
  2019-09-10 22:14         ` Alexander Duyck
  0 siblings, 1 reply; 82+ messages in thread
From: Michal Hocko @ 2019-09-10 12:11 UTC (permalink / raw)
  To: Alexander Duyck
  Cc: David Hildenbrand, Alexander Duyck, virtio-dev, kvm, mst,
	catalin.marinas, dave.hansen, linux-kernel, willy, linux-mm,
	akpm, will, linux-arm-kernel, osalvador, yang.zhang.wz, pagupta,
	konrad.wilk, nitesh, riel, lcapitulino, wei.w.wang, aarcange,
	ying.huang, pbonzini, dan.j.williams, fengguang.wu,
	kirill.shutemov

On Mon 09-09-19 08:11:36, Alexander Duyck wrote:
> On Mon, 2019-09-09 at 10:14 +0200, David Hildenbrand wrote:
> > On 07.09.19 19:25, Alexander Duyck wrote:
> > > From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> > > 
> > > Change the logic used to generate randomness in the suffle path so that we
> > > can avoid cache line bouncing. The previous logic was sharing the offset
> > > and entropy word between all CPUs. As such this can result in cache line
> > > bouncing and will ultimately hurt performance when enabled.
> > 
> > So, usually we perform such changes if there is real evidence. Do you
> > have any such performance numbers to back your claims?
> 
> I'll have to go rerun the test to get the exact numbers. The reason this
> came up is that my original test was spanning NUMA nodes and that made
> this more expensive as a result since the memory was both not local to the
> CPU and was being updated by multiple sockets.

What was the pattern of page freeing in your testing? I am wondering
because order 0 pages should be prevailing and those usually go via pcp
lists so they do not get shuffled unless the batch is full IIRC.
-- 
Michal Hocko
SUSE Labs

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: [PATCH v9 2/8] mm: Adjust shuffle code to allow for future coalescing
  2019-09-07 17:25 ` [PATCH v9 2/8] mm: Adjust shuffle code to allow for future coalescing Alexander Duyck
  2019-09-09  8:19   ` David Hildenbrand
  2019-09-09  9:47   ` Kirill A. Shutemov
@ 2019-09-10 12:20   ` Michal Hocko
  2019-09-10 14:48     ` Alexander Duyck
  2 siblings, 1 reply; 82+ messages in thread
From: Michal Hocko @ 2019-09-10 12:20 UTC (permalink / raw)
  To: Alexander Duyck
  Cc: virtio-dev, kvm, mst, catalin.marinas, david, dave.hansen,
	linux-kernel, willy, linux-mm, akpm, will, linux-arm-kernel,
	osalvador, yang.zhang.wz, pagupta, konrad.wilk, nitesh, riel,
	lcapitulino, wei.w.wang, aarcange, ying.huang, pbonzini,
	dan.j.williams, fengguang.wu, alexander.h.duyck, kirill.shutemov

On Sat 07-09-19 10:25:20, Alexander Duyck wrote:
> From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> 
> Move the head/tail adding logic out of the shuffle code and into the
> __free_one_page function since ultimately that is where it is really
> needed anyway. By doing this we should be able to reduce the overhead
> and can consolidate all of the list addition bits in one spot.

This changelog doesn't really explain why we want this. You are
reshuffling the code, allright, but why do we want to reshuffle? Is the
result readability a better code reuse or something else? Where
does the claimed reduced overhead coming from?

From a quick look buddy_merge_likely looks nicer than the code splat
we have. Good.

But then

> Reviewed-by: Dan Williams <dan.j.williams@intel.com>
> Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>

[...]

> -	if (is_shuffle_order(order))
> -		add_to_free_area_random(page, &zone->free_area[order],
> -				migratetype);
> +	area = &zone->free_area[order];
> +	if (is_shuffle_order(order) ? shuffle_pick_tail() :
> +	    buddy_merge_likely(pfn, buddy_pfn, page, order))

Ouch this is just awful don't you think?
-- 
Michal Hocko
SUSE Labs

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: [PATCH v9 3/8] mm: Move set/get_pcppage_migratetype to mmzone.h
  2019-09-07 17:25 ` [PATCH v9 3/8] mm: Move set/get_pcppage_migratetype to mmzone.h Alexander Duyck
  2019-09-09  8:22   ` David Hildenbrand
  2019-09-09  9:56   ` Kirill A. Shutemov
@ 2019-09-10 12:23   ` Michal Hocko
  2019-09-10 14:46     ` Alexander Duyck
  2 siblings, 1 reply; 82+ messages in thread
From: Michal Hocko @ 2019-09-10 12:23 UTC (permalink / raw)
  To: Alexander Duyck
  Cc: virtio-dev, kvm, mst, catalin.marinas, david, dave.hansen,
	linux-kernel, willy, linux-mm, akpm, will, linux-arm-kernel,
	osalvador, yang.zhang.wz, pagupta, konrad.wilk, nitesh, riel,
	lcapitulino, wei.w.wang, aarcange, ying.huang, pbonzini,
	dan.j.williams, fengguang.wu, alexander.h.duyck, kirill.shutemov

On Sat 07-09-19 10:25:28, Alexander Duyck wrote:
> From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> 
> In order to support page reporting it will be necessary to store and
> retrieve the migratetype of a page. To enable that I am moving the set and
> get operations for pcppage_migratetype into the mm/internal.h header so
> that they can be used outside of the page_alloc.c file.

Please describe who is the user and why does it needs this interface.
This is really important because migratetype is an MM internal thing and
external users shouldn't really care about it at all. We really do not
want a random code to call those, especially the set_pcppage_migratetype.

> Reviewed-by: Dan Williams <dan.j.williams@intel.com>
> Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> ---
>  mm/internal.h   |   18 ++++++++++++++++++
>  mm/page_alloc.c |   18 ------------------
>  2 files changed, 18 insertions(+), 18 deletions(-)
> 
> diff --git a/mm/internal.h b/mm/internal.h
> index 0d5f720c75ab..e4a1a57bbd40 100644
> --- a/mm/internal.h
> +++ b/mm/internal.h
> @@ -549,6 +549,24 @@ static inline bool is_migrate_highatomic_page(struct page *page)
>  	return get_pageblock_migratetype(page) == MIGRATE_HIGHATOMIC;
>  }
>  
> +/*
> + * A cached value of the page's pageblock's migratetype, used when the page is
> + * put on a pcplist. Used to avoid the pageblock migratetype lookup when
> + * freeing from pcplists in most cases, at the cost of possibly becoming stale.
> + * Also the migratetype set in the page does not necessarily match the pcplist
> + * index, e.g. page might have MIGRATE_CMA set but be on a pcplist with any
> + * other index - this ensures that it will be put on the correct CMA freelist.
> + */
> +static inline int get_pcppage_migratetype(struct page *page)
> +{
> +	return page->index;
> +}
> +
> +static inline void set_pcppage_migratetype(struct page *page, int migratetype)
> +{
> +	page->index = migratetype;
> +}
> +
>  void setup_zone_pageset(struct zone *zone);
>  extern struct page *alloc_new_node_page(struct page *page, unsigned long node);
>  #endif	/* __MM_INTERNAL_H */
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 4e4356ba66c7..a791f2baeeeb 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -185,24 +185,6 @@ static int __init early_init_on_free(char *buf)
>  }
>  early_param("init_on_free", early_init_on_free);
>  
> -/*
> - * A cached value of the page's pageblock's migratetype, used when the page is
> - * put on a pcplist. Used to avoid the pageblock migratetype lookup when
> - * freeing from pcplists in most cases, at the cost of possibly becoming stale.
> - * Also the migratetype set in the page does not necessarily match the pcplist
> - * index, e.g. page might have MIGRATE_CMA set but be on a pcplist with any
> - * other index - this ensures that it will be put on the correct CMA freelist.
> - */
> -static inline int get_pcppage_migratetype(struct page *page)
> -{
> -	return page->index;
> -}
> -
> -static inline void set_pcppage_migratetype(struct page *page, int migratetype)
> -{
> -	page->index = migratetype;
> -}
> -
>  #ifdef CONFIG_PM_SLEEP
>  /*
>   * The following functions are used by the suspend/hibernate code to temporarily

-- 
Michal Hocko
SUSE Labs

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: [PATCH v9 4/8] mm: Use zone and order instead of free area in free_list manipulators
  2019-09-07 17:25 ` [PATCH v9 4/8] mm: Use zone and order instead of free area in free_list manipulators Alexander Duyck
@ 2019-09-10 12:27   ` Michal Hocko
  0 siblings, 0 replies; 82+ messages in thread
From: Michal Hocko @ 2019-09-10 12:27 UTC (permalink / raw)
  To: Alexander Duyck
  Cc: virtio-dev, kvm, mst, catalin.marinas, david, dave.hansen,
	linux-kernel, willy, linux-mm, akpm, will, linux-arm-kernel,
	osalvador, yang.zhang.wz, pagupta, konrad.wilk, nitesh, riel,
	lcapitulino, wei.w.wang, aarcange, ying.huang, pbonzini,
	dan.j.williams, fengguang.wu, alexander.h.duyck, kirill.shutemov

On Sat 07-09-19 10:25:36, Alexander Duyck wrote:
> From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> 
> In order to enable the use of the zone from the list manipulator functions
> I will need access to the zone pointer. As it turns out most of the
> accessors were always just being directly passed &zone->free_area[order]
> anyway so it would make sense to just fold that into the function itself
> and pass the zone and order as arguments instead of the free area.

Yes this makes the interface better.

> In order to be able to reference the zone we need to move the declaration
> of the functions down so that we have the zone defined before we define the
> list manipulation functions.
> 
> Reviewed-by: Dan Williams <dan.j.williams@intel.com>
> Reviewed-by: David Hildenbrand <david@redhat.com>
> Reviewed-by: Pankaj Gupta <pagupta@redhat.com>
> Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>

Acked-by: Michal Hocko <mhocko@suse.com>

> ---
>  include/linux/mmzone.h |   70 ++++++++++++++++++++++++++----------------------
>  mm/page_alloc.c        |   30 ++++++++-------------
>  2 files changed, 49 insertions(+), 51 deletions(-)
> 
> diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
> index 125f300981c6..2ddf1f1971c0 100644
> --- a/include/linux/mmzone.h
> +++ b/include/linux/mmzone.h
> @@ -100,29 +100,6 @@ struct free_area {
>  	unsigned long		nr_free;
>  };
>  
> -/* Used for pages not on another list */
> -static inline void add_to_free_area(struct page *page, struct free_area *area,
> -			     int migratetype)
> -{
> -	list_add(&page->lru, &area->free_list[migratetype]);
> -	area->nr_free++;
> -}
> -
> -/* Used for pages not on another list */
> -static inline void add_to_free_area_tail(struct page *page, struct free_area *area,
> -				  int migratetype)
> -{
> -	list_add_tail(&page->lru, &area->free_list[migratetype]);
> -	area->nr_free++;
> -}
> -
> -/* Used for pages which are on another list */
> -static inline void move_to_free_area(struct page *page, struct free_area *area,
> -			     int migratetype)
> -{
> -	list_move(&page->lru, &area->free_list[migratetype]);
> -}
> -
>  static inline struct page *get_page_from_free_area(struct free_area *area,
>  					    int migratetype)
>  {
> @@ -130,15 +107,6 @@ static inline struct page *get_page_from_free_area(struct free_area *area,
>  					struct page, lru);
>  }
>  
> -static inline void del_page_from_free_area(struct page *page,
> -		struct free_area *area)
> -{
> -	list_del(&page->lru);
> -	__ClearPageBuddy(page);
> -	set_page_private(page, 0);
> -	area->nr_free--;
> -}
> -
>  static inline bool free_area_empty(struct free_area *area, int migratetype)
>  {
>  	return list_empty(&area->free_list[migratetype]);
> @@ -796,6 +764,44 @@ static inline bool pgdat_is_empty(pg_data_t *pgdat)
>  	return !pgdat->node_start_pfn && !pgdat->node_spanned_pages;
>  }
>  
> +/* Used for pages not on another list */
> +static inline void add_to_free_list(struct page *page, struct zone *zone,
> +				    unsigned int order, int migratetype)
> +{
> +	struct free_area *area = &zone->free_area[order];
> +
> +	list_add(&page->lru, &area->free_list[migratetype]);
> +	area->nr_free++;
> +}
> +
> +/* Used for pages not on another list */
> +static inline void add_to_free_list_tail(struct page *page, struct zone *zone,
> +					 unsigned int order, int migratetype)
> +{
> +	struct free_area *area = &zone->free_area[order];
> +
> +	list_add_tail(&page->lru, &area->free_list[migratetype]);
> +	area->nr_free++;
> +}
> +
> +/* Used for pages which are on another list */
> +static inline void move_to_free_list(struct page *page, struct zone *zone,
> +				     unsigned int order, int migratetype)
> +{
> +	struct free_area *area = &zone->free_area[order];
> +
> +	list_move(&page->lru, &area->free_list[migratetype]);
> +}
> +
> +static inline void del_page_from_free_list(struct page *page, struct zone *zone,
> +					   unsigned int order)
> +{
> +	list_del(&page->lru);
> +	__ClearPageBuddy(page);
> +	set_page_private(page, 0);
> +	zone->free_area[order].nr_free--;
> +}
> +
>  #include <linux/memory_hotplug.h>
>  
>  void build_all_zonelists(pg_data_t *pgdat);
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index a791f2baeeeb..f85dc1561b85 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -921,7 +921,6 @@ static inline void __free_one_page(struct page *page,
>  	struct capture_control *capc = task_capc(zone);
>  	unsigned long uninitialized_var(buddy_pfn);
>  	unsigned long combined_pfn;
> -	struct free_area *area;
>  	unsigned int max_order;
>  	struct page *buddy;
>  
> @@ -958,7 +957,7 @@ static inline void __free_one_page(struct page *page,
>  		if (page_is_guard(buddy))
>  			clear_page_guard(zone, buddy, order, migratetype);
>  		else
> -			del_page_from_free_area(buddy, &zone->free_area[order]);
> +			del_page_from_free_list(buddy, zone, order);
>  		combined_pfn = buddy_pfn & pfn;
>  		page = page + (combined_pfn - pfn);
>  		pfn = combined_pfn;
> @@ -992,12 +991,11 @@ static inline void __free_one_page(struct page *page,
>  done_merging:
>  	set_page_order(page, order);
>  
> -	area = &zone->free_area[order];
>  	if (is_shuffle_order(order) ? shuffle_pick_tail() :
>  	    buddy_merge_likely(pfn, buddy_pfn, page, order))
> -		add_to_free_area_tail(page, area, migratetype);
> +		add_to_free_list_tail(page, zone, order, migratetype);
>  	else
> -		add_to_free_area(page, area, migratetype);
> +		add_to_free_list(page, zone, order, migratetype);
>  }
>  
>  /*
> @@ -2001,13 +1999,11 @@ void __init init_cma_reserved_pageblock(struct page *page)
>   * -- nyc
>   */
>  static inline void expand(struct zone *zone, struct page *page,
> -	int low, int high, struct free_area *area,
> -	int migratetype)
> +	int low, int high, int migratetype)
>  {
>  	unsigned long size = 1 << high;
>  
>  	while (high > low) {
> -		area--;
>  		high--;
>  		size >>= 1;
>  		VM_BUG_ON_PAGE(bad_range(zone, &page[size]), &page[size]);
> @@ -2021,7 +2017,7 @@ static inline void expand(struct zone *zone, struct page *page,
>  		if (set_page_guard(zone, &page[size], high, migratetype))
>  			continue;
>  
> -		add_to_free_area(&page[size], area, migratetype);
> +		add_to_free_list(&page[size], zone, high, migratetype);
>  		set_page_order(&page[size], high);
>  	}
>  }
> @@ -2179,8 +2175,8 @@ struct page *__rmqueue_smallest(struct zone *zone, unsigned int order,
>  		page = get_page_from_free_area(area, migratetype);
>  		if (!page)
>  			continue;
> -		del_page_from_free_area(page, area);
> -		expand(zone, page, order, current_order, area, migratetype);
> +		del_page_from_free_list(page, zone, current_order);
> +		expand(zone, page, order, current_order, migratetype);
>  		set_pcppage_migratetype(page, migratetype);
>  		return page;
>  	}
> @@ -2188,7 +2184,6 @@ struct page *__rmqueue_smallest(struct zone *zone, unsigned int order,
>  	return NULL;
>  }
>  
> -
>  /*
>   * This array describes the order lists are fallen back to when
>   * the free lists for the desirable migrate type are depleted
> @@ -2254,7 +2249,7 @@ static int move_freepages(struct zone *zone,
>  		VM_BUG_ON_PAGE(page_zone(page) != zone, page);
>  
>  		order = page_order(page);
> -		move_to_free_area(page, &zone->free_area[order], migratetype);
> +		move_to_free_list(page, zone, order, migratetype);
>  		page += 1 << order;
>  		pages_moved += 1 << order;
>  	}
> @@ -2370,7 +2365,6 @@ static void steal_suitable_fallback(struct zone *zone, struct page *page,
>  		unsigned int alloc_flags, int start_type, bool whole_block)
>  {
>  	unsigned int current_order = page_order(page);
> -	struct free_area *area;
>  	int free_pages, movable_pages, alike_pages;
>  	int old_block_type;
>  
> @@ -2441,8 +2435,7 @@ static void steal_suitable_fallback(struct zone *zone, struct page *page,
>  	return;
>  
>  single_page:
> -	area = &zone->free_area[current_order];
> -	move_to_free_area(page, area, start_type);
> +	move_to_free_list(page, zone, current_order, start_type);
>  }
>  
>  /*
> @@ -3113,7 +3106,6 @@ void split_page(struct page *page, unsigned int order)
>  
>  int __isolate_free_page(struct page *page, unsigned int order)
>  {
> -	struct free_area *area = &page_zone(page)->free_area[order];
>  	unsigned long watermark;
>  	struct zone *zone;
>  	int mt;
> @@ -3139,7 +3131,7 @@ int __isolate_free_page(struct page *page, unsigned int order)
>  
>  	/* Remove page from free list */
>  
> -	del_page_from_free_area(page, area);
> +	del_page_from_free_list(page, zone, order);
>  
>  	/*
>  	 * Set the pageblock if the isolated page is at least half of a
> @@ -8560,7 +8552,7 @@ void zone_pcp_reset(struct zone *zone)
>  		pr_info("remove from free list %lx %d %lx\n",
>  			pfn, 1 << order, end_pfn);
>  #endif
> -		del_page_from_free_area(page, &zone->free_area[order]);
> +		del_page_from_free_list(page, zone, order);
>  		for (i = 0; i < (1 << order); i++)
>  			SetPageReserved((page+i));
>  		pfn += (1 << order);

-- 
Michal Hocko
SUSE Labs

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: [PATCH v9 0/8] stg mail -e --version=v9 \
  2019-09-07 17:25 [PATCH v9 0/8] stg mail -e --version=v9 \ Alexander Duyck
                   ` (8 preceding siblings ...)
  2019-09-07 17:34 ` [PATCH v9 0/8] mm / virtio: Provide support for unused page reporting Alexander Duyck
@ 2019-09-10 12:42 ` Michal Hocko
  2019-09-10 14:42   ` Alexander Duyck
  9 siblings, 1 reply; 82+ messages in thread
From: Michal Hocko @ 2019-09-10 12:42 UTC (permalink / raw)
  To: Alexander Duyck
  Cc: virtio-dev, kvm, mst, catalin.marinas, david, dave.hansen,
	linux-kernel, willy, linux-mm, akpm, will, linux-arm-kernel,
	osalvador, yang.zhang.wz, pagupta, konrad.wilk, nitesh, riel,
	lcapitulino, wei.w.wang, aarcange, ying.huang, pbonzini,
	dan.j.williams, fengguang.wu, alexander.h.duyck, kirill.shutemov

I wanted to review "mm: Introduce Reported pages" just realize that I
have no clue on what is going on so returned to the cover and it didn't
really help much. I am completely unfamiliar with virtio so please bear
with me.

On Sat 07-09-19 10:25:03, Alexander Duyck wrote:
[...]
> This series provides an asynchronous means of reporting to a hypervisor
> that a guest page is no longer in use and can have the data associated
> with it dropped. To do this I have implemented functionality that allows
> for what I am referring to as unused page reporting
> 
> The functionality for this is fairly simple. When enabled it will allocate
> statistics to track the number of reported pages in a given free area.
> When the number of free pages exceeds this value plus a high water value,
> currently 32, it will begin performing page reporting which consists of
> pulling pages off of free list and placing them into a scatter list. The
> scatterlist is then given to the page reporting device and it will perform
> the required action to make the pages "reported", in the case of
> virtio-balloon this results in the pages being madvised as MADV_DONTNEED
> and as such they are forced out of the guest. After this they are placed
> back on the free list,

And here I am reallly lost because "forced out of the guest" makes me
feel that those pages are no longer usable by the guest. So how come you
can add them back to the free list. I suspect understanding this part
will allow me to understand why we have to mark those pages and prevent
merging.

> and an additional bit is added if they are not
> merged indicating that they are a reported buddy page instead of a
> standard buddy page. The cycle then repeats with additional non-reported
> pages being pulled until the free areas all consist of reported pages.


-- 
Michal Hocko
SUSE Labs

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: [PATCH v9 0/8] stg mail -e --version=v9 \
  2019-09-10 12:42 ` [PATCH v9 0/8] stg mail -e --version=v9 \ Michal Hocko
@ 2019-09-10 14:42   ` Alexander Duyck
  2019-09-10 14:47     ` Michal Hocko
  0 siblings, 1 reply; 82+ messages in thread
From: Alexander Duyck @ 2019-09-10 14:42 UTC (permalink / raw)
  To: Michal Hocko
  Cc: virtio-dev, kvm list, Michael S. Tsirkin, Catalin Marinas,
	David Hildenbrand, Dave Hansen, LKML, Matthew Wilcox, linux-mm,
	Andrew Morton, will, linux-arm-kernel, Oscar Salvador,
	Yang Zhang, Pankaj Gupta, Konrad Rzeszutek Wilk,
	Nitesh Narayan Lal, Rik van Riel, lcapitulino, Wang, Wei W,
	Andrea Arcangeli, ying.huang, Paolo Bonzini, Dan Williams,
	Fengguang Wu, Alexander Duyck, Kirill A. Shutemov

On Tue, Sep 10, 2019 at 5:42 AM Michal Hocko <mhocko@kernel.org> wrote:
>
> I wanted to review "mm: Introduce Reported pages" just realize that I
> have no clue on what is going on so returned to the cover and it didn't
> really help much. I am completely unfamiliar with virtio so please bear
> with me.
>
> On Sat 07-09-19 10:25:03, Alexander Duyck wrote:
> [...]
> > This series provides an asynchronous means of reporting to a hypervisor
> > that a guest page is no longer in use and can have the data associated
> > with it dropped. To do this I have implemented functionality that allows
> > for what I am referring to as unused page reporting
> >
> > The functionality for this is fairly simple. When enabled it will allocate
> > statistics to track the number of reported pages in a given free area.
> > When the number of free pages exceeds this value plus a high water value,
> > currently 32, it will begin performing page reporting which consists of
> > pulling pages off of free list and placing them into a scatter list. The
> > scatterlist is then given to the page reporting device and it will perform
> > the required action to make the pages "reported", in the case of
> > virtio-balloon this results in the pages being madvised as MADV_DONTNEED
> > and as such they are forced out of the guest. After this they are placed
> > back on the free list,
>
> And here I am reallly lost because "forced out of the guest" makes me
> feel that those pages are no longer usable by the guest. So how come you
> can add them back to the free list. I suspect understanding this part
> will allow me to understand why we have to mark those pages and prevent
> merging.

Basically as the paragraph above mentions "forced out of the guest"
really is just the hypervisor calling MADV_DONTNEED on the page in
question. So the behavior is the same as any userspace application
that calls MADV_DONTNEED where the contents are no longer accessible
from userspace and attempting to access them will result in a fault
and the page being populated with a zero fill on-demand page, or a
copy of the file contents if the memory is file backed.

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: [PATCH v9 3/8] mm: Move set/get_pcppage_migratetype to mmzone.h
  2019-09-10 12:23   ` Michal Hocko
@ 2019-09-10 14:46     ` Alexander Duyck
  2019-09-10 17:45       ` Michal Hocko
  0 siblings, 1 reply; 82+ messages in thread
From: Alexander Duyck @ 2019-09-10 14:46 UTC (permalink / raw)
  To: Michal Hocko
  Cc: virtio-dev, kvm list, Michael S. Tsirkin, Catalin Marinas,
	David Hildenbrand, Dave Hansen, LKML, Matthew Wilcox, linux-mm,
	Andrew Morton, will, linux-arm-kernel, Oscar Salvador,
	Yang Zhang, Pankaj Gupta, Konrad Rzeszutek Wilk,
	Nitesh Narayan Lal, Rik van Riel, lcapitulino, Wang, Wei W,
	Andrea Arcangeli, ying.huang, Paolo Bonzini, Dan Williams,
	Fengguang Wu, Alexander Duyck, Kirill A. Shutemov

On Tue, Sep 10, 2019 at 5:23 AM Michal Hocko <mhocko@kernel.org> wrote:
>
> On Sat 07-09-19 10:25:28, Alexander Duyck wrote:
> > From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> >
> > In order to support page reporting it will be necessary to store and
> > retrieve the migratetype of a page. To enable that I am moving the set and
> > get operations for pcppage_migratetype into the mm/internal.h header so
> > that they can be used outside of the page_alloc.c file.
>
> Please describe who is the user and why does it needs this interface.
> This is really important because migratetype is an MM internal thing and
> external users shouldn't really care about it at all. We really do not
> want a random code to call those, especially the set_pcppage_migratetype.

I was using it to store the migratetype of the page so that I could
find the boundary list that contained the reported page as the array
is indexed based on page order and migratetype. However on further
discussion I am thinking I may just use page->index directly to index
into the boundary array. Doing that I should be able to get a very
slight improvement in lookup time since I am not having to pull order
and migratetype and then compute the index based on that. In addition
it becomes much more clear as to what is going on, and if needed I
could add debug checks to verify the page is "Reported" and that the
"Buddy" page type is set.

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: [PATCH v9 0/8] stg mail -e --version=v9 \
  2019-09-10 14:42   ` Alexander Duyck
@ 2019-09-10 14:47     ` Michal Hocko
  2019-09-10 16:05       ` Alexander Duyck
  0 siblings, 1 reply; 82+ messages in thread
From: Michal Hocko @ 2019-09-10 14:47 UTC (permalink / raw)
  To: Alexander Duyck
  Cc: virtio-dev, kvm list, Michael S. Tsirkin, Catalin Marinas,
	David Hildenbrand, Dave Hansen, LKML, Matthew Wilcox, linux-mm,
	Andrew Morton, will, linux-arm-kernel, Oscar Salvador,
	Yang Zhang, Pankaj Gupta, Konrad Rzeszutek Wilk,
	Nitesh Narayan Lal, Rik van Riel, lcapitulino, Wang, Wei W,
	Andrea Arcangeli, ying.huang, Paolo Bonzini, Dan Williams,
	Fengguang Wu, Alexander Duyck, Kirill A. Shutemov

On Tue 10-09-19 07:42:43, Alexander Duyck wrote:
> On Tue, Sep 10, 2019 at 5:42 AM Michal Hocko <mhocko@kernel.org> wrote:
> >
> > I wanted to review "mm: Introduce Reported pages" just realize that I
> > have no clue on what is going on so returned to the cover and it didn't
> > really help much. I am completely unfamiliar with virtio so please bear
> > with me.
> >
> > On Sat 07-09-19 10:25:03, Alexander Duyck wrote:
> > [...]
> > > This series provides an asynchronous means of reporting to a hypervisor
> > > that a guest page is no longer in use and can have the data associated
> > > with it dropped. To do this I have implemented functionality that allows
> > > for what I am referring to as unused page reporting
> > >
> > > The functionality for this is fairly simple. When enabled it will allocate
> > > statistics to track the number of reported pages in a given free area.
> > > When the number of free pages exceeds this value plus a high water value,
> > > currently 32, it will begin performing page reporting which consists of
> > > pulling pages off of free list and placing them into a scatter list. The
> > > scatterlist is then given to the page reporting device and it will perform
> > > the required action to make the pages "reported", in the case of
> > > virtio-balloon this results in the pages being madvised as MADV_DONTNEED
> > > and as such they are forced out of the guest. After this they are placed
> > > back on the free list,
> >
> > And here I am reallly lost because "forced out of the guest" makes me
> > feel that those pages are no longer usable by the guest. So how come you
> > can add them back to the free list. I suspect understanding this part
> > will allow me to understand why we have to mark those pages and prevent
> > merging.
> 
> Basically as the paragraph above mentions "forced out of the guest"
> really is just the hypervisor calling MADV_DONTNEED on the page in
> question. So the behavior is the same as any userspace application
> that calls MADV_DONTNEED where the contents are no longer accessible
> from userspace and attempting to access them will result in a fault
> and the page being populated with a zero fill on-demand page, or a
> copy of the file contents if the memory is file backed.

As I've said I have no idea about virt so this doesn't really tell me
much. Does that mean that if somebody allocates such a page and tries to
access it then virt will handle a fault and bring it back?

-- 
Michal Hocko
SUSE Labs

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: [PATCH v9 2/8] mm: Adjust shuffle code to allow for future coalescing
  2019-09-10 12:20   ` Michal Hocko
@ 2019-09-10 14:48     ` Alexander Duyck
  0 siblings, 0 replies; 82+ messages in thread
From: Alexander Duyck @ 2019-09-10 14:48 UTC (permalink / raw)
  To: Michal Hocko
  Cc: virtio-dev, kvm list, Michael S. Tsirkin, Catalin Marinas,
	David Hildenbrand, Dave Hansen, LKML, Matthew Wilcox, linux-mm,
	Andrew Morton, will, linux-arm-kernel, Oscar Salvador,
	Yang Zhang, Pankaj Gupta, Konrad Rzeszutek Wilk,
	Nitesh Narayan Lal, Rik van Riel, lcapitulino, Wang, Wei W,
	Andrea Arcangeli, ying.huang, Paolo Bonzini, Dan Williams,
	Fengguang Wu, Alexander Duyck, Kirill A. Shutemov

On Tue, Sep 10, 2019 at 5:20 AM Michal Hocko <mhocko@kernel.org> wrote:
>
> On Sat 07-09-19 10:25:20, Alexander Duyck wrote:
> > From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> >
> > Move the head/tail adding logic out of the shuffle code and into the
> > __free_one_page function since ultimately that is where it is really
> > needed anyway. By doing this we should be able to reduce the overhead
> > and can consolidate all of the list addition bits in one spot.
>
> This changelog doesn't really explain why we want this. You are
> reshuffling the code, allright, but why do we want to reshuffle? Is the
> result readability a better code reuse or something else? Where
> does the claimed reduced overhead coming from?
>
> From a quick look buddy_merge_likely looks nicer than the code splat
> we have. Good.
>
> But then
>
> > Reviewed-by: Dan Williams <dan.j.williams@intel.com>
> > Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
>
> [...]
>
> > -     if (is_shuffle_order(order))
> > -             add_to_free_area_random(page, &zone->free_area[order],
> > -                             migratetype);
> > +     area = &zone->free_area[order];
> > +     if (is_shuffle_order(order) ? shuffle_pick_tail() :
> > +         buddy_merge_likely(pfn, buddy_pfn, page, order))
>
> Ouch this is just awful don't you think?

Yeah. I am going to go with Kirill's suggestion and probably do
something more along the lines of:
       bool to_tail;
        ...
        if (is_shuffle_order(order))
                to_tail = shuffle_pick_tail();
       else
                to_tail = buddy_merge_likely(pfn, buddy_pfn, page, order);

        if (to_tail)
                add_to_free_area_tail(page, area, migratetype);
        else
                add_to_free_area(page, area, migratetype);

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: [PATCH v9 0/8] stg mail -e --version=v9 \
  2019-09-10 14:47     ` Michal Hocko
@ 2019-09-10 16:05       ` Alexander Duyck
  2019-09-10 16:18         ` [virtio-dev] " Dr. David Alan Gilbert
  2019-09-10 17:52         ` Michal Hocko
  0 siblings, 2 replies; 82+ messages in thread
From: Alexander Duyck @ 2019-09-10 16:05 UTC (permalink / raw)
  To: Michal Hocko
  Cc: virtio-dev, kvm list, Michael S. Tsirkin, Catalin Marinas,
	David Hildenbrand, Dave Hansen, LKML, Matthew Wilcox, linux-mm,
	Andrew Morton, will, linux-arm-kernel, Oscar Salvador,
	Yang Zhang, Pankaj Gupta, Konrad Rzeszutek Wilk,
	Nitesh Narayan Lal, Rik van Riel, lcapitulino, Wang, Wei W,
	Andrea Arcangeli, ying.huang, Paolo Bonzini, Dan Williams,
	Fengguang Wu, Alexander Duyck, Kirill A. Shutemov

On Tue, Sep 10, 2019 at 7:47 AM Michal Hocko <mhocko@kernel.org> wrote:
>
> On Tue 10-09-19 07:42:43, Alexander Duyck wrote:
> > On Tue, Sep 10, 2019 at 5:42 AM Michal Hocko <mhocko@kernel.org> wrote:
> > >
> > > I wanted to review "mm: Introduce Reported pages" just realize that I
> > > have no clue on what is going on so returned to the cover and it didn't
> > > really help much. I am completely unfamiliar with virtio so please bear
> > > with me.
> > >
> > > On Sat 07-09-19 10:25:03, Alexander Duyck wrote:
> > > [...]
> > > > This series provides an asynchronous means of reporting to a hypervisor
> > > > that a guest page is no longer in use and can have the data associated
> > > > with it dropped. To do this I have implemented functionality that allows
> > > > for what I am referring to as unused page reporting
> > > >
> > > > The functionality for this is fairly simple. When enabled it will allocate
> > > > statistics to track the number of reported pages in a given free area.
> > > > When the number of free pages exceeds this value plus a high water value,
> > > > currently 32, it will begin performing page reporting which consists of
> > > > pulling pages off of free list and placing them into a scatter list. The
> > > > scatterlist is then given to the page reporting device and it will perform
> > > > the required action to make the pages "reported", in the case of
> > > > virtio-balloon this results in the pages being madvised as MADV_DONTNEED
> > > > and as such they are forced out of the guest. After this they are placed
> > > > back on the free list,
> > >
> > > And here I am reallly lost because "forced out of the guest" makes me
> > > feel that those pages are no longer usable by the guest. So how come you
> > > can add them back to the free list. I suspect understanding this part
> > > will allow me to understand why we have to mark those pages and prevent
> > > merging.
> >
> > Basically as the paragraph above mentions "forced out of the guest"
> > really is just the hypervisor calling MADV_DONTNEED on the page in
> > question. So the behavior is the same as any userspace application
> > that calls MADV_DONTNEED where the contents are no longer accessible
> > from userspace and attempting to access them will result in a fault
> > and the page being populated with a zero fill on-demand page, or a
> > copy of the file contents if the memory is file backed.
>
> As I've said I have no idea about virt so this doesn't really tell me
> much. Does that mean that if somebody allocates such a page and tries to
> access it then virt will handle a fault and bring it back?

Actually I am probably describing too much as the MADV_DONTNEED is the
hypervisor behavior in response to the virtio-balloon notification. A
more thorough explanation of it can be found by just running "man
madvise", probably best just to leave it at that since I am probably
confusing things by describing hypervisor behavior in a kernel patch
set.

For the most part all the page reporting really does is provide a way
to incrementally identify unused regions of memory in the buddy
allocator. That in turn is used by virtio-balloon in a polling thread
to report to the hypervisor what pages are not in use so that it can
make a decision on what to do with the pages now that it knows they
are unused.

All this is providing is just a report and it is optional if the
hypervisor will act on it or not. If the hypervisor takes some sort of
action on the page, then the expectation is that the hypervisor will
use some sort of mechanism such as a page fault to discover when the
page is used again.

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: [virtio-dev] Re: [PATCH v9 0/8] stg mail -e --version=v9 \
  2019-09-10 16:05       ` Alexander Duyck
@ 2019-09-10 16:18         ` Dr. David Alan Gilbert
  2019-09-10 16:22           ` David Hildenbrand
  2019-09-10 17:52         ` Michal Hocko
  1 sibling, 1 reply; 82+ messages in thread
From: Dr. David Alan Gilbert @ 2019-09-10 16:18 UTC (permalink / raw)
  To: Alexander Duyck
  Cc: Michal Hocko, virtio-dev, kvm list, Michael S. Tsirkin,
	Catalin Marinas, David Hildenbrand, Dave Hansen, LKML,
	Matthew Wilcox, linux-mm, Andrew Morton, will, linux-arm-kernel,
	Oscar Salvador, Yang Zhang, Pankaj Gupta, Konrad Rzeszutek Wilk,
	Nitesh Narayan Lal, Rik van Riel, lcapitulino, Wang, Wei W,
	Andrea Arcangeli, ying.huang, Paolo Bonzini, Dan Williams,
	Fengguang Wu, Alexander Duyck, Kirill A. Shutemov

* Alexander Duyck (alexander.duyck@gmail.com) wrote:
> On Tue, Sep 10, 2019 at 7:47 AM Michal Hocko <mhocko@kernel.org> wrote:
> >
> > On Tue 10-09-19 07:42:43, Alexander Duyck wrote:
> > > On Tue, Sep 10, 2019 at 5:42 AM Michal Hocko <mhocko@kernel.org> wrote:
> > > >
> > > > I wanted to review "mm: Introduce Reported pages" just realize that I
> > > > have no clue on what is going on so returned to the cover and it didn't
> > > > really help much. I am completely unfamiliar with virtio so please bear
> > > > with me.
> > > >
> > > > On Sat 07-09-19 10:25:03, Alexander Duyck wrote:
> > > > [...]
> > > > > This series provides an asynchronous means of reporting to a hypervisor
> > > > > that a guest page is no longer in use and can have the data associated
> > > > > with it dropped. To do this I have implemented functionality that allows
> > > > > for what I am referring to as unused page reporting
> > > > >
> > > > > The functionality for this is fairly simple. When enabled it will allocate
> > > > > statistics to track the number of reported pages in a given free area.
> > > > > When the number of free pages exceeds this value plus a high water value,
> > > > > currently 32, it will begin performing page reporting which consists of
> > > > > pulling pages off of free list and placing them into a scatter list. The
> > > > > scatterlist is then given to the page reporting device and it will perform
> > > > > the required action to make the pages "reported", in the case of
> > > > > virtio-balloon this results in the pages being madvised as MADV_DONTNEED
> > > > > and as such they are forced out of the guest. After this they are placed
> > > > > back on the free list,
> > > >
> > > > And here I am reallly lost because "forced out of the guest" makes me
> > > > feel that those pages are no longer usable by the guest. So how come you
> > > > can add them back to the free list. I suspect understanding this part
> > > > will allow me to understand why we have to mark those pages and prevent
> > > > merging.
> > >
> > > Basically as the paragraph above mentions "forced out of the guest"
> > > really is just the hypervisor calling MADV_DONTNEED on the page in
> > > question. So the behavior is the same as any userspace application
> > > that calls MADV_DONTNEED where the contents are no longer accessible
> > > from userspace and attempting to access them will result in a fault
> > > and the page being populated with a zero fill on-demand page, or a
> > > copy of the file contents if the memory is file backed.
> >
> > As I've said I have no idea about virt so this doesn't really tell me
> > much. Does that mean that if somebody allocates such a page and tries to
> > access it then virt will handle a fault and bring it back?
> 
> Actually I am probably describing too much as the MADV_DONTNEED is the
> hypervisor behavior in response to the virtio-balloon notification. A
> more thorough explanation of it can be found by just running "man
> madvise", probably best just to leave it at that since I am probably
> confusing things by describing hypervisor behavior in a kernel patch
> set.
> 
> For the most part all the page reporting really does is provide a way
> to incrementally identify unused regions of memory in the buddy
> allocator. That in turn is used by virtio-balloon in a polling thread
> to report to the hypervisor what pages are not in use so that it can
> make a decision on what to do with the pages now that it knows they
> are unused.
> 
> All this is providing is just a report and it is optional if the
> hypervisor will act on it or not. If the hypervisor takes some sort of
> action on the page, then the expectation is that the hypervisor will
> use some sort of mechanism such as a page fault to discover when the
> page is used again.

OK, that's interestingly different (but OK) from some other schemes that
hav ebeen described which *require* the guest to somehow indicate the
page is in use before starting to use the page again.

Dave

> ---------------------------------------------------------------------
> To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
> 
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: [virtio-dev] Re: [PATCH v9 0/8] stg mail -e --version=v9 \
  2019-09-10 16:18         ` [virtio-dev] " Dr. David Alan Gilbert
@ 2019-09-10 16:22           ` David Hildenbrand
  2019-09-11  9:23             ` Michael S. Tsirkin
  0 siblings, 1 reply; 82+ messages in thread
From: David Hildenbrand @ 2019-09-10 16:22 UTC (permalink / raw)
  To: Dr. David Alan Gilbert, Alexander Duyck
  Cc: Michal Hocko, virtio-dev, kvm list, Michael S. Tsirkin,
	Catalin Marinas, Dave Hansen, LKML, Matthew Wilcox, linux-mm,
	Andrew Morton, will, linux-arm-kernel, Oscar Salvador,
	Yang Zhang, Pankaj Gupta, Konrad Rzeszutek Wilk,
	Nitesh Narayan Lal, Rik van Riel, lcapitulino, Wang, Wei W,
	Andrea Arcangeli, ying.huang, Paolo Bonzini, Dan Williams,
	Fengguang Wu, Alexander Duyck, Kirill A. Shutemov

On 10.09.19 18:18, Dr. David Alan Gilbert wrote:
> * Alexander Duyck (alexander.duyck@gmail.com) wrote:
>> On Tue, Sep 10, 2019 at 7:47 AM Michal Hocko <mhocko@kernel.org> wrote:
>>>
>>> On Tue 10-09-19 07:42:43, Alexander Duyck wrote:
>>>> On Tue, Sep 10, 2019 at 5:42 AM Michal Hocko <mhocko@kernel.org> wrote:
>>>>>
>>>>> I wanted to review "mm: Introduce Reported pages" just realize that I
>>>>> have no clue on what is going on so returned to the cover and it didn't
>>>>> really help much. I am completely unfamiliar with virtio so please bear
>>>>> with me.
>>>>>
>>>>> On Sat 07-09-19 10:25:03, Alexander Duyck wrote:
>>>>> [...]
>>>>>> This series provides an asynchronous means of reporting to a hypervisor
>>>>>> that a guest page is no longer in use and can have the data associated
>>>>>> with it dropped. To do this I have implemented functionality that allows
>>>>>> for what I am referring to as unused page reporting
>>>>>>
>>>>>> The functionality for this is fairly simple. When enabled it will allocate
>>>>>> statistics to track the number of reported pages in a given free area.
>>>>>> When the number of free pages exceeds this value plus a high water value,
>>>>>> currently 32, it will begin performing page reporting which consists of
>>>>>> pulling pages off of free list and placing them into a scatter list. The
>>>>>> scatterlist is then given to the page reporting device and it will perform
>>>>>> the required action to make the pages "reported", in the case of
>>>>>> virtio-balloon this results in the pages being madvised as MADV_DONTNEED
>>>>>> and as such they are forced out of the guest. After this they are placed
>>>>>> back on the free list,
>>>>>
>>>>> And here I am reallly lost because "forced out of the guest" makes me
>>>>> feel that those pages are no longer usable by the guest. So how come you
>>>>> can add them back to the free list. I suspect understanding this part
>>>>> will allow me to understand why we have to mark those pages and prevent
>>>>> merging.
>>>>
>>>> Basically as the paragraph above mentions "forced out of the guest"
>>>> really is just the hypervisor calling MADV_DONTNEED on the page in
>>>> question. So the behavior is the same as any userspace application
>>>> that calls MADV_DONTNEED where the contents are no longer accessible
>>>> from userspace and attempting to access them will result in a fault
>>>> and the page being populated with a zero fill on-demand page, or a
>>>> copy of the file contents if the memory is file backed.
>>>
>>> As I've said I have no idea about virt so this doesn't really tell me
>>> much. Does that mean that if somebody allocates such a page and tries to
>>> access it then virt will handle a fault and bring it back?
>>
>> Actually I am probably describing too much as the MADV_DONTNEED is the
>> hypervisor behavior in response to the virtio-balloon notification. A
>> more thorough explanation of it can be found by just running "man
>> madvise", probably best just to leave it at that since I am probably
>> confusing things by describing hypervisor behavior in a kernel patch
>> set.
>>
>> For the most part all the page reporting really does is provide a way
>> to incrementally identify unused regions of memory in the buddy
>> allocator. That in turn is used by virtio-balloon in a polling thread
>> to report to the hypervisor what pages are not in use so that it can
>> make a decision on what to do with the pages now that it knows they
>> are unused.
>>
>> All this is providing is just a report and it is optional if the
>> hypervisor will act on it or not. If the hypervisor takes some sort of
>> action on the page, then the expectation is that the hypervisor will
>> use some sort of mechanism such as a page fault to discover when the
>> page is used again.
> 
> OK, that's interestingly different (but OK) from some other schemes that
> hav ebeen described which *require* the guest to somehow indicate the
> page is in use before starting to use the page again.
> 

virtio-balloon also has a mode where the guest would not have to
indicate to the host before re-using a page. Only
VIRTIO_BALLOON_F_MUST_TELL_HOST enforces this. So it's not completely new.

> Dave


-- 

Thanks,

David / dhildenb

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: [PATCH v9 3/8] mm: Move set/get_pcppage_migratetype to mmzone.h
  2019-09-10 14:46     ` Alexander Duyck
@ 2019-09-10 17:45       ` Michal Hocko
  2019-09-10 20:26         ` Alexander Duyck
  0 siblings, 1 reply; 82+ messages in thread
From: Michal Hocko @ 2019-09-10 17:45 UTC (permalink / raw)
  To: Alexander Duyck
  Cc: virtio-dev, kvm list, Michael S. Tsirkin, Catalin Marinas,
	David Hildenbrand, Dave Hansen, LKML, Matthew Wilcox, linux-mm,
	Andrew Morton, will, linux-arm-kernel, Oscar Salvador,
	Yang Zhang, Pankaj Gupta, Konrad Rzeszutek Wilk,
	Nitesh Narayan Lal, Rik van Riel, lcapitulino, Wang, Wei W,
	Andrea Arcangeli, ying.huang, Paolo Bonzini, Dan Williams,
	Fengguang Wu, Alexander Duyck, Kirill A. Shutemov

On Tue 10-09-19 07:46:50, Alexander Duyck wrote:
> On Tue, Sep 10, 2019 at 5:23 AM Michal Hocko <mhocko@kernel.org> wrote:
> >
> > On Sat 07-09-19 10:25:28, Alexander Duyck wrote:
> > > From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> > >
> > > In order to support page reporting it will be necessary to store and
> > > retrieve the migratetype of a page. To enable that I am moving the set and
> > > get operations for pcppage_migratetype into the mm/internal.h header so
> > > that they can be used outside of the page_alloc.c file.
> >
> > Please describe who is the user and why does it needs this interface.
> > This is really important because migratetype is an MM internal thing and
> > external users shouldn't really care about it at all. We really do not
> > want a random code to call those, especially the set_pcppage_migratetype.
> 
> I was using it to store the migratetype of the page so that I could
> find the boundary list that contained the reported page as the array
> is indexed based on page order and migratetype. However on further
> discussion I am thinking I may just use page->index directly to index
> into the boundary array. Doing that I should be able to get a very
> slight improvement in lookup time since I am not having to pull order
> and migratetype and then compute the index based on that. In addition
> it becomes much more clear as to what is going on, and if needed I
> could add debug checks to verify the page is "Reported" and that the
> "Buddy" page type is set.

Be careful though. A free page belongs to the page allocator and it is
free to reuse any fields for its purpose so using any of them nilly
willy is no go. If you need to stuff something like that then there
better be an api the allocator is aware of. My main objection is the
abuse migrate type. There might be other ways to express what you need.
Please make sure you clearly define that though.

-- 
Michal Hocko
SUSE Labs

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: [PATCH v9 0/8] stg mail -e --version=v9 \
  2019-09-10 16:05       ` Alexander Duyck
  2019-09-10 16:18         ` [virtio-dev] " Dr. David Alan Gilbert
@ 2019-09-10 17:52         ` Michal Hocko
  2019-09-10 18:00           ` Michal Hocko
  2019-09-10 21:23           ` Alexander Duyck
  1 sibling, 2 replies; 82+ messages in thread
From: Michal Hocko @ 2019-09-10 17:52 UTC (permalink / raw)
  To: Alexander Duyck
  Cc: virtio-dev, kvm list, Michael S. Tsirkin, Catalin Marinas,
	David Hildenbrand, Dave Hansen, LKML, Matthew Wilcox, linux-mm,
	Andrew Morton, will, linux-arm-kernel, Oscar Salvador,
	Yang Zhang, Pankaj Gupta, Konrad Rzeszutek Wilk,
	Nitesh Narayan Lal, Rik van Riel, lcapitulino, Wang, Wei W,
	Andrea Arcangeli, ying.huang, Paolo Bonzini, Dan Williams,
	Fengguang Wu, Alexander Duyck, Kirill A. Shutemov

On Tue 10-09-19 09:05:43, Alexander Duyck wrote:
> On Tue, Sep 10, 2019 at 7:47 AM Michal Hocko <mhocko@kernel.org> wrote:
> >
> > On Tue 10-09-19 07:42:43, Alexander Duyck wrote:
> > > On Tue, Sep 10, 2019 at 5:42 AM Michal Hocko <mhocko@kernel.org> wrote:
> > > >
> > > > I wanted to review "mm: Introduce Reported pages" just realize that I
> > > > have no clue on what is going on so returned to the cover and it didn't
> > > > really help much. I am completely unfamiliar with virtio so please bear
> > > > with me.
> > > >
> > > > On Sat 07-09-19 10:25:03, Alexander Duyck wrote:
> > > > [...]
> > > > > This series provides an asynchronous means of reporting to a hypervisor
> > > > > that a guest page is no longer in use and can have the data associated
> > > > > with it dropped. To do this I have implemented functionality that allows
> > > > > for what I am referring to as unused page reporting
> > > > >
> > > > > The functionality for this is fairly simple. When enabled it will allocate
> > > > > statistics to track the number of reported pages in a given free area.
> > > > > When the number of free pages exceeds this value plus a high water value,
> > > > > currently 32, it will begin performing page reporting which consists of
> > > > > pulling pages off of free list and placing them into a scatter list. The
> > > > > scatterlist is then given to the page reporting device and it will perform
> > > > > the required action to make the pages "reported", in the case of
> > > > > virtio-balloon this results in the pages being madvised as MADV_DONTNEED
> > > > > and as such they are forced out of the guest. After this they are placed
> > > > > back on the free list,
> > > >
> > > > And here I am reallly lost because "forced out of the guest" makes me
> > > > feel that those pages are no longer usable by the guest. So how come you
> > > > can add them back to the free list. I suspect understanding this part
> > > > will allow me to understand why we have to mark those pages and prevent
> > > > merging.
> > >
> > > Basically as the paragraph above mentions "forced out of the guest"
> > > really is just the hypervisor calling MADV_DONTNEED on the page in
> > > question. So the behavior is the same as any userspace application
> > > that calls MADV_DONTNEED where the contents are no longer accessible
> > > from userspace and attempting to access them will result in a fault
> > > and the page being populated with a zero fill on-demand page, or a
> > > copy of the file contents if the memory is file backed.
> >
> > As I've said I have no idea about virt so this doesn't really tell me
> > much. Does that mean that if somebody allocates such a page and tries to
> > access it then virt will handle a fault and bring it back?
> 
> Actually I am probably describing too much as the MADV_DONTNEED is the
> hypervisor behavior in response to the virtio-balloon notification. A
> more thorough explanation of it can be found by just running "man
> madvise", probably best just to leave it at that since I am probably
> confusing things by describing hypervisor behavior in a kernel patch
> set.

This analogy is indeed confusing and doesn't help to build a picture.

> For the most part all the page reporting really does is provide a way
> to incrementally identify unused regions of memory in the buddy
> allocator. That in turn is used by virtio-balloon in a polling thread
> to report to the hypervisor what pages are not in use so that it can
> make a decision on what to do with the pages now that it knows they
> are unused.

So essentially you want to store metadata into free pages and control
what the allocator can do with them? Namely buddy merging if the type
doesn't match?

> All this is providing is just a report and it is optional if the
> hypervisor will act on it or not. If the hypervisor takes some sort of
> action on the page, then the expectation is that the hypervisor will
> use some sort of mechanism such as a page fault to discover when the
> page is used again.

OK so the baloon driver is in charge of this metadata and the allocator
has to live with that. Isn't that a layer violation?

-- 
Michal Hocko
SUSE Labs

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: [PATCH v9 0/8] stg mail -e --version=v9 \
  2019-09-10 17:52         ` Michal Hocko
@ 2019-09-10 18:00           ` Michal Hocko
  2019-09-10 20:37             ` Alexander Duyck
  2019-09-10 21:23           ` Alexander Duyck
  1 sibling, 1 reply; 82+ messages in thread
From: Michal Hocko @ 2019-09-10 18:00 UTC (permalink / raw)
  To: Alexander Duyck
  Cc: virtio-dev, kvm list, Michael S. Tsirkin, Catalin Marinas,
	David Hildenbrand, Dave Hansen, LKML, Matthew Wilcox, linux-mm,
	Andrew Morton, will, linux-arm-kernel, Oscar Salvador,
	Yang Zhang, Pankaj Gupta, Konrad Rzeszutek Wilk,
	Nitesh Narayan Lal, Rik van Riel, lcapitulino, Wang, Wei W,
	Andrea Arcangeli, ying.huang, Paolo Bonzini, Dan Williams,
	Fengguang Wu, Alexander Duyck, Kirill A. Shutemov

On Tue 10-09-19 19:52:13, Michal Hocko wrote:
> On Tue 10-09-19 09:05:43, Alexander Duyck wrote:
[...]
> > All this is providing is just a report and it is optional if the
> > hypervisor will act on it or not. If the hypervisor takes some sort of
> > action on the page, then the expectation is that the hypervisor will
> > use some sort of mechanism such as a page fault to discover when the
> > page is used again.
> 
> OK so the baloon driver is in charge of this metadata and the allocator
> has to live with that. Isn't that a layer violation?

Another thing that is not clear to me is how these marked pages are
different from any other free pages. All of them are unused and you are
losing your metadata as soon as the page gets allocated because the page
changes its owner and the struct page belongs to it.
-- 
Michal Hocko
SUSE Labs

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: [PATCH v9 3/8] mm: Move set/get_pcppage_migratetype to mmzone.h
  2019-09-10 17:45       ` Michal Hocko
@ 2019-09-10 20:26         ` Alexander Duyck
  0 siblings, 0 replies; 82+ messages in thread
From: Alexander Duyck @ 2019-09-10 20:26 UTC (permalink / raw)
  To: Michal Hocko, Alexander Duyck
  Cc: virtio-dev, kvm list, Michael S. Tsirkin, Catalin Marinas,
	David Hildenbrand, Dave Hansen, LKML, Matthew Wilcox, linux-mm,
	Andrew Morton, will, linux-arm-kernel, Oscar Salvador,
	Yang Zhang, Pankaj Gupta, Konrad Rzeszutek Wilk,
	Nitesh Narayan Lal, Rik van Riel, lcapitulino, Wang, Wei W,
	Andrea Arcangeli, ying.huang, Paolo Bonzini, Dan Williams,
	Fengguang Wu, Kirill A. Shutemov

On Tue, 2019-09-10 at 19:45 +0200, Michal Hocko wrote:
> On Tue 10-09-19 07:46:50, Alexander Duyck wrote:
> > On Tue, Sep 10, 2019 at 5:23 AM Michal Hocko <mhocko@kernel.org> wrote:
> > > On Sat 07-09-19 10:25:28, Alexander Duyck wrote:
> > > > From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> > > > 
> > > > In order to support page reporting it will be necessary to store and
> > > > retrieve the migratetype of a page. To enable that I am moving the set and
> > > > get operations for pcppage_migratetype into the mm/internal.h header so
> > > > that they can be used outside of the page_alloc.c file.
> > > 
> > > Please describe who is the user and why does it needs this interface.
> > > This is really important because migratetype is an MM internal thing and
> > > external users shouldn't really care about it at all. We really do not
> > > want a random code to call those, especially the set_pcppage_migratetype.
> > 
> > I was using it to store the migratetype of the page so that I could
> > find the boundary list that contained the reported page as the array
> > is indexed based on page order and migratetype. However on further
> > discussion I am thinking I may just use page->index directly to index
> > into the boundary array. Doing that I should be able to get a very
> > slight improvement in lookup time since I am not having to pull order
> > and migratetype and then compute the index based on that. In addition
> > it becomes much more clear as to what is going on, and if needed I
> > could add debug checks to verify the page is "Reported" and that the
> > "Buddy" page type is set.
> 
> Be careful though. A free page belongs to the page allocator and it is
> free to reuse any fields for its purpose so using any of them nilly
> willy is no go. If you need to stuff something like that then there
> better be an api the allocator is aware of. My main objection is the
> abuse migrate type. There might be other ways to express what you need.
> Please make sure you clearly define that though.

I will. Basically if the Reported is set then it will mean that the index
value is in use and provides the index into the boundary array. The
Reported flag will be cleared when the page is pulled from the buddy list
and in the case of the page being allocated it is already overwritten by
__rmqueue_smallest calling set_pcppage_migratetype which is what gave me
the idea to just use that in the first place.


^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: [PATCH v9 0/8] stg mail -e --version=v9 \
  2019-09-10 18:00           ` Michal Hocko
@ 2019-09-10 20:37             ` Alexander Duyck
  0 siblings, 0 replies; 82+ messages in thread
From: Alexander Duyck @ 2019-09-10 20:37 UTC (permalink / raw)
  To: Michal Hocko, Alexander Duyck
  Cc: virtio-dev, kvm list, Michael S. Tsirkin, Catalin Marinas,
	David Hildenbrand, Dave Hansen, LKML, Matthew Wilcox, linux-mm,
	Andrew Morton, will, linux-arm-kernel, Oscar Salvador,
	Yang Zhang, Pankaj Gupta, Konrad Rzeszutek Wilk,
	Nitesh Narayan Lal, Rik van Riel, lcapitulino, Wang, Wei W,
	Andrea Arcangeli, ying.huang, Paolo Bonzini, Dan Williams,
	Fengguang Wu, Kirill A. Shutemov

On Tue, 2019-09-10 at 20:00 +0200, Michal Hocko wrote:
> On Tue 10-09-19 19:52:13, Michal Hocko wrote:
> > On Tue 10-09-19 09:05:43, Alexander Duyck wrote:
> [...]
> > > All this is providing is just a report and it is optional if the
> > > hypervisor will act on it or not. If the hypervisor takes some sort of
> > > action on the page, then the expectation is that the hypervisor will
> > > use some sort of mechanism such as a page fault to discover when the
> > > page is used again.
> > 
> > OK so the baloon driver is in charge of this metadata and the allocator
> > has to live with that. Isn't that a layer violation?
> 
> Another thing that is not clear to me is how these marked pages are
> different from any other free pages. All of them are unused and you are
> losing your metadata as soon as the page gets allocated because the page
> changes its owner and the struct page belongs to it.

Really they aren't any different then other free pages other than they are
marked. Us losing the metadata as soon as the page is allocated is fine as
we will need to re-report it when it is returned so we no longer need the
metadata once it is allocated.


^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: [PATCH v9 0/8] stg mail -e --version=v9 \
  2019-09-10 17:52         ` Michal Hocko
  2019-09-10 18:00           ` Michal Hocko
@ 2019-09-10 21:23           ` Alexander Duyck
  2019-09-11 11:36             ` Michal Hocko
  1 sibling, 1 reply; 82+ messages in thread
From: Alexander Duyck @ 2019-09-10 21:23 UTC (permalink / raw)
  To: Michal Hocko, Alexander Duyck
  Cc: virtio-dev, kvm list, Michael S. Tsirkin, Catalin Marinas,
	David Hildenbrand, Dave Hansen, LKML, Matthew Wilcox, linux-mm,
	Andrew Morton, will, linux-arm-kernel, Oscar Salvador,
	Yang Zhang, Pankaj Gupta, Konrad Rzeszutek Wilk,
	Nitesh Narayan Lal, Rik van Riel, lcapitulino, Wang, Wei W,
	Andrea Arcangeli, ying.huang, Paolo Bonzini, Dan Williams,
	Fengguang Wu, Kirill A. Shutemov

On Tue, 2019-09-10 at 19:52 +0200, Michal Hocko wrote:
> On Tue 10-09-19 09:05:43, Alexander Duyck wrote:
> > On Tue, Sep 10, 2019 at 7:47 AM Michal Hocko <mhocko@kernel.org> wrote:
> > > On Tue 10-09-19 07:42:43, Alexander Duyck wrote:
> > > > On Tue, Sep 10, 2019 at 5:42 AM Michal Hocko <mhocko@kernel.org> wrote:
> > > > > I wanted to review "mm: Introduce Reported pages" just realize that I
> > > > > have no clue on what is going on so returned to the cover and it didn't
> > > > > really help much. I am completely unfamiliar with virtio so please bear
> > > > > with me.
> > > > > 
> > > > > On Sat 07-09-19 10:25:03, Alexander Duyck wrote:
> > > > > [...]
> > > > > > This series provides an asynchronous means of reporting to a hypervisor
> > > > > > that a guest page is no longer in use and can have the data associated
> > > > > > with it dropped. To do this I have implemented functionality that allows
> > > > > > for what I am referring to as unused page reporting
> > > > > > 
> > > > > > The functionality for this is fairly simple. When enabled it will allocate
> > > > > > statistics to track the number of reported pages in a given free area.
> > > > > > When the number of free pages exceeds this value plus a high water value,
> > > > > > currently 32, it will begin performing page reporting which consists of
> > > > > > pulling pages off of free list and placing them into a scatter list. The
> > > > > > scatterlist is then given to the page reporting device and it will perform
> > > > > > the required action to make the pages "reported", in the case of
> > > > > > virtio-balloon this results in the pages being madvised as MADV_DONTNEED
> > > > > > and as such they are forced out of the guest. After this they are placed
> > > > > > back on the free list,
> > > > > 
> > > > > And here I am reallly lost because "forced out of the guest" makes me
> > > > > feel that those pages are no longer usable by the guest. So how come you
> > > > > can add them back to the free list. I suspect understanding this part
> > > > > will allow me to understand why we have to mark those pages and prevent
> > > > > merging.
> > > > 
> > > > Basically as the paragraph above mentions "forced out of the guest"
> > > > really is just the hypervisor calling MADV_DONTNEED on the page in
> > > > question. So the behavior is the same as any userspace application
> > > > that calls MADV_DONTNEED where the contents are no longer accessible
> > > > from userspace and attempting to access them will result in a fault
> > > > and the page being populated with a zero fill on-demand page, or a
> > > > copy of the file contents if the memory is file backed.
> > > 
> > > As I've said I have no idea about virt so this doesn't really tell me
> > > much. Does that mean that if somebody allocates such a page and tries to
> > > access it then virt will handle a fault and bring it back?
> > 
> > Actually I am probably describing too much as the MADV_DONTNEED is the
> > hypervisor behavior in response to the virtio-balloon notification. A
> > more thorough explanation of it can be found by just running "man
> > madvise", probably best just to leave it at that since I am probably
> > confusing things by describing hypervisor behavior in a kernel patch
> > set.
> 
> This analogy is indeed confusing and doesn't help to build a picture.

All I am really doing is using a pointer per free_list, the page->index, 
and a page flag to provide a way to iterate over the list in such a way
that I will not repeat the operation on a page I have already reported. It
is taking advantage of the fact that we add pages to either the head or
the tail of the list, and can pull the pages from anywhere in the list, so
we have to work around those edges to avoid processing the already
reported pages in between.

Admittedly this is pretty complex. I've been at this for several months,
and have gone through several iterations.

If it helps I can try to draw it out as a bit of ASCII art. Basically what
I am trying to do is find a way to skip over the blob of reported pages
that would exist after we have not been reporting for a little while. Most
of this logic is in the get_reported_pages/free_reported_pages that should
be in patch 6.

So on our first iteration through the pages it is pretty straightforward.
We basically just keep pushing the boundary pointer up, we fetch the pages
immediately in front of it, and then when we return the now-reported pages
we push the boundary pointer up to those pages.

While we are actively reporting a given zone we prevent any pages from
being inserted behind the boundary. They are always inserted before the
boundary pointer. This is achieved by replacing the free_list tail pointer
value with the boundary pointer value in the case of add_to_tail calls.

Legend:
U Unused Page
R Reported Page
< Boundary Reported Page

     Head ....................................................... Tail
Start     UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU <
..        UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU<RRRRRRRRRRRRRRRRRRRRRRR
End       UU<RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR

After we completed the boundary pointer is discarded and we don't have to
update it when the zone->flag indicating reporting is active is no longer
set. What we then have happening is that pages are pulled out of the
free_list at random locations or from the head. This causes the list of
reported pages to slowly shrink, however the block of pages should remain
contiguous since new pages are only added to the head or the tail.

     Head ....................................................... Tail
Idle      UUUUUUUUUUUUUUUUURRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRUUUU

Once we have a large enough difference between the nr_free and
reported_pages we will then restart the reporting by resetting the
boundary to the tail and proceeding to pull the non-reported pages that
are in front of the boundary(fig1). Once those are exhasusted we will
start pulling the pages from the head of the list, reporting those, and
then placing them back at the boundary(fig2). When we finally hit the
point where there are no more pages to pull from the head that are not
reported we will update the boundary to the first reported page in the
list, return the reported pages there, and we should be done reporting
pages from this free list.

     Head ....................................................... Tail
Start     UUUUUUUUUUUUUUUUURRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRUUUU <
fig1      UUUUUUUUUUUUUUURRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRU<RRRR
fig2      UUURRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR<RRRRRRRRRRRRRRRRRRRR
End       UU<RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR

The goal with all this is to allow the boundary pointer to move, but to
guarantee forward progress as we work our way through the free_list(s).
Essentially the only requirements we are posing on the page allocator is
that if it pulls the page at the boundary it has to push it back, and if
it wants to add to the tail it has to use the boundary page as the tail
instead.

> > For the most part all the page reporting really does is provide a way
> > to incrementally identify unused regions of memory in the buddy
> > allocator. That in turn is used by virtio-balloon in a polling thread
> > to report to the hypervisor what pages are not in use so that it can
> > make a decision on what to do with the pages now that it knows they
> > are unused.
> 
> So essentially you want to store metadata into free pages and control
> what the allocator can do with them? Namely buddy merging if the type
> doesn't match?

We don't put any limitations on the allocator other then that it needs to
clean up the metadata on allocation, and that it cannot allocate a page
that is in the process of being reported since we pulled it from the
free_list. If the page is a "Reported" page then it decrements the
reported_pages count for the free_area and makes sure the page doesn't
exist in the "Boundary" array pointer value, if it does it moves the
"Boundary" since it is pulling the page.

> > All this is providing is just a report and it is optional if the
> > hypervisor will act on it or not. If the hypervisor takes some sort of
> > action on the page, then the expectation is that the hypervisor will
> > use some sort of mechanism such as a page fault to discover when the
> > page is used again.
> 
> OK so the baloon driver is in charge of this metadata and the allocator
> has to live with that. Isn't that a layer violation?

Really the metadata belongs to the page reporting. The virtio balloon
driver doesn't get to see any of it. It basically registers as a Reporting
interface and then we start sending it scatterlists to report. It doesn't
do anything with the actual pages themselves other then DMA map the
physical addresses for them.


^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: [PATCH v9 1/8] mm: Add per-cpu logic to page shuffling
  2019-09-09  8:14   ` David Hildenbrand
  2019-09-09 15:11     ` Alexander Duyck
@ 2019-09-10 22:11     ` Alexander Duyck
  1 sibling, 0 replies; 82+ messages in thread
From: Alexander Duyck @ 2019-09-10 22:11 UTC (permalink / raw)
  To: David Hildenbrand, Alexander Duyck, virtio-dev, kvm, mst,
	catalin.marinas, dave.hansen, linux-kernel, willy, mhocko,
	linux-mm, akpm, will, linux-arm-kernel, osalvador
  Cc: yang.zhang.wz, pagupta, konrad.wilk, nitesh, riel, lcapitulino,
	wei.w.wang, aarcange, ying.huang, pbonzini, dan.j.williams,
	fengguang.wu, kirill.shutemov

On Mon, 2019-09-09 at 10:14 +0200, David Hildenbrand wrote:
> On 07.09.19 19:25, Alexander Duyck wrote:
> > From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> > 
> > Change the logic used to generate randomness in the suffle path so that we
> > can avoid cache line bouncing. The previous logic was sharing the offset
> > and entropy word between all CPUs. As such this can result in cache line
> > bouncing and will ultimately hurt performance when enabled.
> 
> So, usually we perform such changes if there is real evidence. Do you
> have any such performance numbers to back your claims?

I don't have any numbers. From what I can tell the impact is small enough
that this doesn't really have much impact.

With that being the case I can probably just drop this patch. I will
instead just use "rand & 1" in the 2nd patch to generate the return value
which was what was previously done in add_to_free_area_random.


^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: [PATCH v9 1/8] mm: Add per-cpu logic to page shuffling
  2019-09-10 12:11       ` Michal Hocko
@ 2019-09-10 22:14         ` Alexander Duyck
  0 siblings, 0 replies; 82+ messages in thread
From: Alexander Duyck @ 2019-09-10 22:14 UTC (permalink / raw)
  To: Michal Hocko
  Cc: David Hildenbrand, Alexander Duyck, virtio-dev, kvm, mst,
	catalin.marinas, dave.hansen, linux-kernel, willy, linux-mm,
	akpm, will, linux-arm-kernel, osalvador, yang.zhang.wz, pagupta,
	konrad.wilk, nitesh, riel, lcapitulino, wei.w.wang, aarcange,
	ying.huang, pbonzini, dan.j.williams, fengguang.wu,
	kirill.shutemov

On Tue, 2019-09-10 at 14:11 +0200, Michal Hocko wrote:
> On Mon 09-09-19 08:11:36, Alexander Duyck wrote:
> > On Mon, 2019-09-09 at 10:14 +0200, David Hildenbrand wrote:
> > > On 07.09.19 19:25, Alexander Duyck wrote:
> > > > From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> > > > 
> > > > Change the logic used to generate randomness in the suffle path so that we
> > > > can avoid cache line bouncing. The previous logic was sharing the offset
> > > > and entropy word between all CPUs. As such this can result in cache line
> > > > bouncing and will ultimately hurt performance when enabled.
> > > 
> > > So, usually we perform such changes if there is real evidence. Do you
> > > have any such performance numbers to back your claims?
> > 
> > I'll have to go rerun the test to get the exact numbers. The reason this
> > came up is that my original test was spanning NUMA nodes and that made
> > this more expensive as a result since the memory was both not local to the
> > CPU and was being updated by multiple sockets.
> 
> What was the pattern of page freeing in your testing? I am wondering
> because order 0 pages should be prevailing and those usually go via pcp
> lists so they do not get shuffled unless the batch is full IIRC.

So I am pretty sure my previous data was faulty. One side effect of the
page reporting is that it was evicting pages out of the guest and when the
pages were faulted back in they were coming from local page pools. This
was throwing off my early numbers and making tests look better than they
should have for the reported case.

I had this patch previously merged with another one so I wasn't testing it
on its own, it was instead a part of a bigger set. Now that I have tried
testing it on its own I can see that it has no significant impact on
performance. With that being the case I will probably just drop it.


^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: [virtio-dev] Re: [PATCH v9 0/8] stg mail -e --version=v9 \
  2019-09-10 16:22           ` David Hildenbrand
@ 2019-09-11  9:23             ` Michael S. Tsirkin
  2019-09-11  9:50               ` David Hildenbrand
  0 siblings, 1 reply; 82+ messages in thread
From: Michael S. Tsirkin @ 2019-09-11  9:23 UTC (permalink / raw)
  To: David Hildenbrand
  Cc: Dr. David Alan Gilbert, Alexander Duyck, Michal Hocko,
	virtio-dev, kvm list, Catalin Marinas, Dave Hansen, LKML,
	Matthew Wilcox, linux-mm, Andrew Morton, will, linux-arm-kernel,
	Oscar Salvador, Yang Zhang, Pankaj Gupta, Konrad Rzeszutek Wilk,
	Nitesh Narayan Lal, Rik van Riel, lcapitulino, Wang, Wei W,
	Andrea Arcangeli, ying.huang, Paolo Bonzini, Dan Williams,
	Fengguang Wu, Alexander Duyck, Kirill A. Shutemov

On Tue, Sep 10, 2019 at 06:22:37PM +0200, David Hildenbrand wrote:
> On 10.09.19 18:18, Dr. David Alan Gilbert wrote:
> > * Alexander Duyck (alexander.duyck@gmail.com) wrote:
> >> On Tue, Sep 10, 2019 at 7:47 AM Michal Hocko <mhocko@kernel.org> wrote:
> >>>
> >>> On Tue 10-09-19 07:42:43, Alexander Duyck wrote:
> >>>> On Tue, Sep 10, 2019 at 5:42 AM Michal Hocko <mhocko@kernel.org> wrote:
> >>>>>
> >>>>> I wanted to review "mm: Introduce Reported pages" just realize that I
> >>>>> have no clue on what is going on so returned to the cover and it didn't
> >>>>> really help much. I am completely unfamiliar with virtio so please bear
> >>>>> with me.
> >>>>>
> >>>>> On Sat 07-09-19 10:25:03, Alexander Duyck wrote:
> >>>>> [...]
> >>>>>> This series provides an asynchronous means of reporting to a hypervisor
> >>>>>> that a guest page is no longer in use and can have the data associated
> >>>>>> with it dropped. To do this I have implemented functionality that allows
> >>>>>> for what I am referring to as unused page reporting
> >>>>>>
> >>>>>> The functionality for this is fairly simple. When enabled it will allocate
> >>>>>> statistics to track the number of reported pages in a given free area.
> >>>>>> When the number of free pages exceeds this value plus a high water value,
> >>>>>> currently 32, it will begin performing page reporting which consists of
> >>>>>> pulling pages off of free list and placing them into a scatter list. The
> >>>>>> scatterlist is then given to the page reporting device and it will perform
> >>>>>> the required action to make the pages "reported", in the case of
> >>>>>> virtio-balloon this results in the pages being madvised as MADV_DONTNEED
> >>>>>> and as such they are forced out of the guest. After this they are placed
> >>>>>> back on the free list,
> >>>>>
> >>>>> And here I am reallly lost because "forced out of the guest" makes me
> >>>>> feel that those pages are no longer usable by the guest. So how come you
> >>>>> can add them back to the free list. I suspect understanding this part
> >>>>> will allow me to understand why we have to mark those pages and prevent
> >>>>> merging.
> >>>>
> >>>> Basically as the paragraph above mentions "forced out of the guest"
> >>>> really is just the hypervisor calling MADV_DONTNEED on the page in
> >>>> question. So the behavior is the same as any userspace application
> >>>> that calls MADV_DONTNEED where the contents are no longer accessible
> >>>> from userspace and attempting to access them will result in a fault
> >>>> and the page being populated with a zero fill on-demand page, or a
> >>>> copy of the file contents if the memory is file backed.
> >>>
> >>> As I've said I have no idea about virt so this doesn't really tell me
> >>> much. Does that mean that if somebody allocates such a page and tries to
> >>> access it then virt will handle a fault and bring it back?
> >>
> >> Actually I am probably describing too much as the MADV_DONTNEED is the
> >> hypervisor behavior in response to the virtio-balloon notification. A
> >> more thorough explanation of it can be found by just running "man
> >> madvise", probably best just to leave it at that since I am probably
> >> confusing things by describing hypervisor behavior in a kernel patch
> >> set.
> >>
> >> For the most part all the page reporting really does is provide a way
> >> to incrementally identify unused regions of memory in the buddy
> >> allocator. That in turn is used by virtio-balloon in a polling thread
> >> to report to the hypervisor what pages are not in use so that it can
> >> make a decision on what to do with the pages now that it knows they
> >> are unused.
> >>
> >> All this is providing is just a report and it is optional if the
> >> hypervisor will act on it or not. If the hypervisor takes some sort of
> >> action on the page, then the expectation is that the hypervisor will
> >> use some sort of mechanism such as a page fault to discover when the
> >> page is used again.
> > 
> > OK, that's interestingly different (but OK) from some other schemes that
> > hav ebeen described which *require* the guest to somehow indicate the
> > page is in use before starting to use the page again.
> > 
> 
> virtio-balloon also has a mode where the guest would not have to
> indicate to the host before re-using a page. Only
> VIRTIO_BALLOON_F_MUST_TELL_HOST enforces this. So it's not completely new.

VIRTIO_BALLOON_F_MUST_TELL_HOST is a bit different.
When it's not set, guest still must tell host about
pages in use, it just can batch these notifications
sending them possibly after page has been used.
So even with VIRTIO_BALLOON_F_MUST_TELL_HOST off you don't
skip the notification.


From hypervisor point of view, this feature is very much like adding
page to the balloon and immediately taking it out of the balloon again,
just doing it in one operation.

The main difference is the contents of the page, which matters
with poisoning: in that case hypervisor is expected to hand
back page with the poisoning content. Not so with regular
deflate where page contents is undefined.

Well and also the new interface is optimized for large chunks
of memory since we'll likely be dealing with such.

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

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: [virtio-dev] Re: [PATCH v9 0/8] stg mail -e --version=v9 \
  2019-09-11  9:23             ` Michael S. Tsirkin
@ 2019-09-11  9:50               ` David Hildenbrand
  0 siblings, 0 replies; 82+ messages in thread
From: David Hildenbrand @ 2019-09-11  9:50 UTC (permalink / raw)
  To: Michael S. Tsirkin
  Cc: Dr. David Alan Gilbert, Alexander Duyck, Michal Hocko,
	virtio-dev, kvm list, Catalin Marinas, Dave Hansen, LKML,
	Matthew Wilcox, linux-mm, Andrew Morton, will, linux-arm-kernel,
	Oscar Salvador, Yang Zhang, Pankaj Gupta, Konrad Rzeszutek Wilk,
	Nitesh Narayan Lal, Rik van Riel, lcapitulino, Wang, Wei W,
	Andrea Arcangeli, ying.huang, Paolo Bonzini, Dan Williams,
	Fengguang Wu, Alexander Duyck, Kirill A. Shutemov

On 11.09.19 11:23, Michael S. Tsirkin wrote:
> On Tue, Sep 10, 2019 at 06:22:37PM +0200, David Hildenbrand wrote:
>> On 10.09.19 18:18, Dr. David Alan Gilbert wrote:
>>> * Alexander Duyck (alexander.duyck@gmail.com) wrote:
>>>> On Tue, Sep 10, 2019 at 7:47 AM Michal Hocko <mhocko@kernel.org> wrote:
>>>>>
>>>>> On Tue 10-09-19 07:42:43, Alexander Duyck wrote:
>>>>>> On Tue, Sep 10, 2019 at 5:42 AM Michal Hocko <mhocko@kernel.org> wrote:
>>>>>>>
>>>>>>> I wanted to review "mm: Introduce Reported pages" just realize that I
>>>>>>> have no clue on what is going on so returned to the cover and it didn't
>>>>>>> really help much. I am completely unfamiliar with virtio so please bear
>>>>>>> with me.
>>>>>>>
>>>>>>> On Sat 07-09-19 10:25:03, Alexander Duyck wrote:
>>>>>>> [...]
>>>>>>>> This series provides an asynchronous means of reporting to a hypervisor
>>>>>>>> that a guest page is no longer in use and can have the data associated
>>>>>>>> with it dropped. To do this I have implemented functionality that allows
>>>>>>>> for what I am referring to as unused page reporting
>>>>>>>>
>>>>>>>> The functionality for this is fairly simple. When enabled it will allocate
>>>>>>>> statistics to track the number of reported pages in a given free area.
>>>>>>>> When the number of free pages exceeds this value plus a high water value,
>>>>>>>> currently 32, it will begin performing page reporting which consists of
>>>>>>>> pulling pages off of free list and placing them into a scatter list. The
>>>>>>>> scatterlist is then given to the page reporting device and it will perform
>>>>>>>> the required action to make the pages "reported", in the case of
>>>>>>>> virtio-balloon this results in the pages being madvised as MADV_DONTNEED
>>>>>>>> and as such they are forced out of the guest. After this they are placed
>>>>>>>> back on the free list,
>>>>>>>
>>>>>>> And here I am reallly lost because "forced out of the guest" makes me
>>>>>>> feel that those pages are no longer usable by the guest. So how come you
>>>>>>> can add them back to the free list. I suspect understanding this part
>>>>>>> will allow me to understand why we have to mark those pages and prevent
>>>>>>> merging.
>>>>>>
>>>>>> Basically as the paragraph above mentions "forced out of the guest"
>>>>>> really is just the hypervisor calling MADV_DONTNEED on the page in
>>>>>> question. So the behavior is the same as any userspace application
>>>>>> that calls MADV_DONTNEED where the contents are no longer accessible
>>>>>> from userspace and attempting to access them will result in a fault
>>>>>> and the page being populated with a zero fill on-demand page, or a
>>>>>> copy of the file contents if the memory is file backed.
>>>>>
>>>>> As I've said I have no idea about virt so this doesn't really tell me
>>>>> much. Does that mean that if somebody allocates such a page and tries to
>>>>> access it then virt will handle a fault and bring it back?
>>>>
>>>> Actually I am probably describing too much as the MADV_DONTNEED is the
>>>> hypervisor behavior in response to the virtio-balloon notification. A
>>>> more thorough explanation of it can be found by just running "man
>>>> madvise", probably best just to leave it at that since I am probably
>>>> confusing things by describing hypervisor behavior in a kernel patch
>>>> set.
>>>>
>>>> For the most part all the page reporting really does is provide a way
>>>> to incrementally identify unused regions of memory in the buddy
>>>> allocator. That in turn is used by virtio-balloon in a polling thread
>>>> to report to the hypervisor what pages are not in use so that it can
>>>> make a decision on what to do with the pages now that it knows they
>>>> are unused.
>>>>
>>>> All this is providing is just a report and it is optional if the
>>>> hypervisor will act on it or not. If the hypervisor takes some sort of
>>>> action on the page, then the expectation is that the hypervisor will
>>>> use some sort of mechanism such as a page fault to discover when the
>>>> page is used again.
>>>
>>> OK, that's interestingly different (but OK) from some other schemes that
>>> hav ebeen described which *require* the guest to somehow indicate the
>>> page is in use before starting to use the page again.
>>>
>>
>> virtio-balloon also has a mode where the guest would not have to
>> indicate to the host before re-using a page. Only
>> VIRTIO_BALLOON_F_MUST_TELL_HOST enforces this. So it's not completely new.
> 
> VIRTIO_BALLOON_F_MUST_TELL_HOST is a bit different.
> When it's not set, guest still must tell host about
> pages in use, it just can batch these notifications
> sending them possibly after page has been used.
> So even with VIRTIO_BALLOON_F_MUST_TELL_HOST off you don't
> skip the notification.
> 

I don't think so

VIRTIO_BALLOON_F_MUST_TELL_HOST     0 /* Tell before reclaiming pages */

commit bf50e69f63d21091e525185c3ae761412be0ba72
Author: Dave Hansen <dave@linux.vnet.ibm.com>
Date:   Thu Apr 7 10:43:25 2011 -0700

    virtio balloon: kill tell-host-first logic

[...]

    But, if the bit is _not_ set, we are under no obligation to
    reverse the order; we're under no obligation to do _anything_.
    As of now, qemu-kvm defines the bit, but doesn't set it.


Old code simply told the hypervisor afterwards, but only for little
performance gain. It is not strictly necessary.

> From hypervisor point of view, this feature is very much like adding
> page to the balloon and immediately taking it out of the balloon again,
> just doing it in one operation.
> 
> The main difference is the contents of the page, which matters
> with poisoning: in that case hypervisor is expected to hand
> back page with the poisoning content. Not so with regular
> deflate where page contents is undefined.
> 
> Well and also the new interface is optimized for large chunks
> of memory since we'll likely be dealing with such.
> 
>>> Dave
>>
>>
>> -- 
>>
>> Thanks,
>>
>> David / dhildenb


-- 

Thanks,

David / dhildenb

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: [PATCH v9 0/8] stg mail -e --version=v9 \
  2019-09-10 21:23           ` Alexander Duyck
@ 2019-09-11 11:36             ` Michal Hocko
  2019-09-11 11:47               ` David Hildenbrand
                                 ` (2 more replies)
  0 siblings, 3 replies; 82+ messages in thread
From: Michal Hocko @ 2019-09-11 11:36 UTC (permalink / raw)
  To: Alexander Duyck
  Cc: Alexander Duyck, virtio-dev, kvm list, Michael S. Tsirkin,
	Catalin Marinas, David Hildenbrand, Dave Hansen, LKML,
	Matthew Wilcox, linux-mm, Andrew Morton, will, linux-arm-kernel,
	Oscar Salvador, Yang Zhang, Pankaj Gupta, Konrad Rzeszutek Wilk,
	Nitesh Narayan Lal, Rik van Riel, lcapitulino, Wang, Wei W,
	Andrea Arcangeli, ying.huang, Paolo Bonzini, Dan Williams,
	Fengguang Wu, Kirill A. Shutemov

On Tue 10-09-19 14:23:40, Alexander Duyck wrote:
[...]
> We don't put any limitations on the allocator other then that it needs to
> clean up the metadata on allocation, and that it cannot allocate a page
> that is in the process of being reported since we pulled it from the
> free_list. If the page is a "Reported" page then it decrements the
> reported_pages count for the free_area and makes sure the page doesn't
> exist in the "Boundary" array pointer value, if it does it moves the
> "Boundary" since it is pulling the page.

This is still a non-trivial limitation on the page allocation from an
external code IMHO. I cannot give any explicit reason why an ordering on
the free list might matter (well except for page shuffling which uses it
to make physical memory pattern allocation more random) but the
architecture seems hacky and dubious to be honest. It shoulds like the
whole interface has been developed around a very particular and single
purpose optimization.

I remember that there was an attempt to report free memory that provided
a callback mechanism [1], which was much less intrusive to the internals
of the allocator yet it should provide a similar functionality. Did you
see that approach? How does this compares to it? Or am I completely off
when comparing them?

[1] mostly likely not the latest version of the patchset
http://lkml.kernel.org/r/1502940416-42944-5-git-send-email-wei.w.wang@intel.com

-- 
Michal Hocko
SUSE Labs

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: [PATCH v9 0/8] stg mail -e --version=v9 \
  2019-09-11 11:36             ` Michal Hocko
@ 2019-09-11 11:47               ` David Hildenbrand
  2019-09-11 12:08               ` Michael S. Tsirkin
  2019-09-11 15:12               ` Alexander Duyck
  2 siblings, 0 replies; 82+ messages in thread
From: David Hildenbrand @ 2019-09-11 11:47 UTC (permalink / raw)
  To: Michal Hocko, Alexander Duyck
  Cc: Alexander Duyck, virtio-dev, kvm list, Michael S. Tsirkin,
	Catalin Marinas, Dave Hansen, LKML, Matthew Wilcox, linux-mm,
	Andrew Morton, will, linux-arm-kernel, Oscar Salvador,
	Yang Zhang, Pankaj Gupta, Konrad Rzeszutek Wilk,
	Nitesh Narayan Lal, Rik van Riel, lcapitulino, Wang, Wei W,
	Andrea Arcangeli, ying.huang, Paolo Bonzini, Dan Williams,
	Fengguang Wu, Kirill A. Shutemov

On 11.09.19 13:36, Michal Hocko wrote:
> On Tue 10-09-19 14:23:40, Alexander Duyck wrote:
> [...]
>> We don't put any limitations on the allocator other then that it needs to
>> clean up the metadata on allocation, and that it cannot allocate a page
>> that is in the process of being reported since we pulled it from the
>> free_list. If the page is a "Reported" page then it decrements the
>> reported_pages count for the free_area and makes sure the page doesn't
>> exist in the "Boundary" array pointer value, if it does it moves the
>> "Boundary" since it is pulling the page.
> 
> This is still a non-trivial limitation on the page allocation from an
> external code IMHO. I cannot give any explicit reason why an ordering on
> the free list might matter (well except for page shuffling which uses it
> to make physical memory pattern allocation more random) but the
> architecture seems hacky and dubious to be honest. It shoulds like the
> whole interface has been developed around a very particular and single
> purpose optimization.
> 
> I remember that there was an attempt to report free memory that provided
> a callback mechanism [1], which was much less intrusive to the internals
> of the allocator yet it should provide a similar functionality. Did you
> see that approach? How does this compares to it? Or am I completely off
> when comparing them?
> 
> [1] mostly likely not the latest version of the patchset
> http://lkml.kernel.org/r/1502940416-42944-5-git-send-email-wei.w.wang@intel.com
> 

FWIW, Nitesh was looking into another approach [1], whereby the metadata
is stored outside of the buddy (unreported pages are tracked in a
bitmap). There are some limitations to this approach (esp., sparse zones
might waste memory (1bit per 2MB), memory hot(un)plug not supported yet
completely, scanning of the bitmap necessary). OTOH, the core buddy
modifications are minimized.

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

-- 

Thanks,

David / dhildenb

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: [PATCH v9 0/8] stg mail -e --version=v9 \
  2019-09-11 11:36             ` Michal Hocko
  2019-09-11 11:47               ` David Hildenbrand
@ 2019-09-11 12:08               ` Michael S. Tsirkin
  2019-09-11 12:19                 ` Michal Hocko
  2019-09-11 15:12               ` Alexander Duyck
  2 siblings, 1 reply; 82+ messages in thread
From: Michael S. Tsirkin @ 2019-09-11 12:08 UTC (permalink / raw)
  To: Michal Hocko
  Cc: Alexander Duyck, Alexander Duyck, virtio-dev, kvm list,
	Catalin Marinas, David Hildenbrand, Dave Hansen, LKML,
	Matthew Wilcox, linux-mm, Andrew Morton, will, linux-arm-kernel,
	Oscar Salvador, Yang Zhang, Pankaj Gupta, Konrad Rzeszutek Wilk,
	Nitesh Narayan Lal, Rik van Riel, lcapitulino, Wang, Wei W,
	Andrea Arcangeli, ying.huang, Paolo Bonzini, Dan Williams,
	Fengguang Wu, Kirill A. Shutemov

On Wed, Sep 11, 2019 at 01:36:19PM +0200, Michal Hocko wrote:
> On Tue 10-09-19 14:23:40, Alexander Duyck wrote:
> [...]
> > We don't put any limitations on the allocator other then that it needs to
> > clean up the metadata on allocation, and that it cannot allocate a page
> > that is in the process of being reported since we pulled it from the
> > free_list. If the page is a "Reported" page then it decrements the
> > reported_pages count for the free_area and makes sure the page doesn't
> > exist in the "Boundary" array pointer value, if it does it moves the
> > "Boundary" since it is pulling the page.
> 
> This is still a non-trivial limitation on the page allocation from an
> external code IMHO. I cannot give any explicit reason why an ordering on
> the free list might matter (well except for page shuffling which uses it
> to make physical memory pattern allocation more random) but the
> architecture seems hacky and dubious to be honest. It shoulds like the
> whole interface has been developed around a very particular and single
> purpose optimization.
> 
> I remember that there was an attempt to report free memory that provided
> a callback mechanism [1], which was much less intrusive to the internals
> of the allocator yet it should provide a similar functionality. Did you
> see that approach? How does this compares to it? Or am I completely off
> when comparing them?
> 
> [1] mostly likely not the latest version of the patchset
> http://lkml.kernel.org/r/1502940416-42944-5-git-send-email-wei.w.wang@intel.com
> 
> -- 
> Michal Hocko
> SUSE Labs

Linus nacked that one. He thinks invoking callbacks with lots of
internal mm locks is too fragile.

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: [PATCH v9 0/8] stg mail -e --version=v9 \
  2019-09-11 12:08               ` Michael S. Tsirkin
@ 2019-09-11 12:19                 ` Michal Hocko
  2019-09-11 12:25                   ` Michal Hocko
  0 siblings, 1 reply; 82+ messages in thread
From: Michal Hocko @ 2019-09-11 12:19 UTC (permalink / raw)
  To: Michael S. Tsirkin
  Cc: Alexander Duyck, Alexander Duyck, virtio-dev, kvm list,
	Catalin Marinas, David Hildenbrand, Dave Hansen, LKML,
	Matthew Wilcox, linux-mm, Andrew Morton, will, linux-arm-kernel,
	Oscar Salvador, Yang Zhang, Pankaj Gupta, Konrad Rzeszutek Wilk,
	Nitesh Narayan Lal, Rik van Riel, lcapitulino, Wang, Wei W,
	Andrea Arcangeli, ying.huang, Paolo Bonzini, Dan Williams,
	Fengguang Wu, Kirill A. Shutemov

On Wed 11-09-19 08:08:38, Michael S. Tsirkin wrote:
> On Wed, Sep 11, 2019 at 01:36:19PM +0200, Michal Hocko wrote:
> > On Tue 10-09-19 14:23:40, Alexander Duyck wrote:
> > [...]
> > > We don't put any limitations on the allocator other then that it needs to
> > > clean up the metadata on allocation, and that it cannot allocate a page
> > > that is in the process of being reported since we pulled it from the
> > > free_list. If the page is a "Reported" page then it decrements the
> > > reported_pages count for the free_area and makes sure the page doesn't
> > > exist in the "Boundary" array pointer value, if it does it moves the
> > > "Boundary" since it is pulling the page.
> > 
> > This is still a non-trivial limitation on the page allocation from an
> > external code IMHO. I cannot give any explicit reason why an ordering on
> > the free list might matter (well except for page shuffling which uses it
> > to make physical memory pattern allocation more random) but the
> > architecture seems hacky and dubious to be honest. It shoulds like the
> > whole interface has been developed around a very particular and single
> > purpose optimization.
> > 
> > I remember that there was an attempt to report free memory that provided
> > a callback mechanism [1], which was much less intrusive to the internals
> > of the allocator yet it should provide a similar functionality. Did you
> > see that approach? How does this compares to it? Or am I completely off
> > when comparing them?
> > 
> > [1] mostly likely not the latest version of the patchset
> > http://lkml.kernel.org/r/1502940416-42944-5-git-send-email-wei.w.wang@intel.com
> 
> Linus nacked that one. He thinks invoking callbacks with lots of
> internal mm locks is too fragile.

I would be really curious how much he would be happy about injecting
other restrictions on the allocator like this patch proposes. This is
more intrusive as it has a higher maintenance cost longterm IMHO.
-- 
Michal Hocko
SUSE Labs

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: [PATCH v9 0/8] stg mail -e --version=v9 \
  2019-09-11 12:19                 ` Michal Hocko
@ 2019-09-11 12:25                   ` Michal Hocko
  2019-09-11 12:42                     ` David Hildenbrand
  0 siblings, 1 reply; 82+ messages in thread
From: Michal Hocko @ 2019-09-11 12:25 UTC (permalink / raw)
  To: Michael S. Tsirkin
  Cc: Alexander Duyck, Alexander Duyck, virtio-dev, kvm list,
	Catalin Marinas, David Hildenbrand, Dave Hansen, LKML,
	Matthew Wilcox, linux-mm, Andrew Morton, will, linux-arm-kernel,
	Oscar Salvador, Yang Zhang, Pankaj Gupta, Konrad Rzeszutek Wilk,
	Nitesh Narayan Lal, Rik van Riel, lcapitulino, Wang, Wei W,
	Andrea Arcangeli, ying.huang, Paolo Bonzini, Dan Williams,
	Fengguang Wu, Kirill A. Shutemov

On Wed 11-09-19 14:19:41, Michal Hocko wrote:
> On Wed 11-09-19 08:08:38, Michael S. Tsirkin wrote:
> > On Wed, Sep 11, 2019 at 01:36:19PM +0200, Michal Hocko wrote:
> > > On Tue 10-09-19 14:23:40, Alexander Duyck wrote:
> > > [...]
> > > > We don't put any limitations on the allocator other then that it needs to
> > > > clean up the metadata on allocation, and that it cannot allocate a page
> > > > that is in the process of being reported since we pulled it from the
> > > > free_list. If the page is a "Reported" page then it decrements the
> > > > reported_pages count for the free_area and makes sure the page doesn't
> > > > exist in the "Boundary" array pointer value, if it does it moves the
> > > > "Boundary" since it is pulling the page.
> > > 
> > > This is still a non-trivial limitation on the page allocation from an
> > > external code IMHO. I cannot give any explicit reason why an ordering on
> > > the free list might matter (well except for page shuffling which uses it
> > > to make physical memory pattern allocation more random) but the
> > > architecture seems hacky and dubious to be honest. It shoulds like the
> > > whole interface has been developed around a very particular and single
> > > purpose optimization.
> > > 
> > > I remember that there was an attempt to report free memory that provided
> > > a callback mechanism [1], which was much less intrusive to the internals
> > > of the allocator yet it should provide a similar functionality. Did you
> > > see that approach? How does this compares to it? Or am I completely off
> > > when comparing them?
> > > 
> > > [1] mostly likely not the latest version of the patchset
> > > http://lkml.kernel.org/r/1502940416-42944-5-git-send-email-wei.w.wang@intel.com
> > 
> > Linus nacked that one. He thinks invoking callbacks with lots of
> > internal mm locks is too fragile.
> 
> I would be really curious how much he would be happy about injecting
> other restrictions on the allocator like this patch proposes. This is
> more intrusive as it has a higher maintenance cost longterm IMHO.

Btw. I do agree that callbacks with internal mm locks are not great
either. We do have a model for that in mmu_notifiers and it is something
I do consider PITA, on the other hand it is mostly sleepable part of the
interface which makes it the real pain. The above callback mechanism was
explicitly documented with restrictions and that the context is
essentially atomic with no access to particular struct pages and no
expensive operations possible. So in the end I've considered it
acceptably painful. Not that I want to override Linus' nack but if
virtualization usecases really require some form of reporting and no
other way to do that push people to invent even more interesting
approaches then we should simply give them/you something reasonable
and least intrusive to our internals.
-- 
Michal Hocko
SUSE Labs

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: [PATCH v9 0/8] stg mail -e --version=v9 \
  2019-09-11 12:25                   ` Michal Hocko
@ 2019-09-11 12:42                     ` David Hildenbrand
  2019-09-11 12:54                       ` Michal Hocko
  2019-09-11 12:55                       ` Nitesh Narayan Lal
  0 siblings, 2 replies; 82+ messages in thread
From: David Hildenbrand @ 2019-09-11 12:42 UTC (permalink / raw)
  To: Michal Hocko, Michael S. Tsirkin
  Cc: Alexander Duyck, Alexander Duyck, virtio-dev, kvm list,
	Catalin Marinas, Dave Hansen, LKML, Matthew Wilcox, linux-mm,
	Andrew Morton, will, linux-arm-kernel, Oscar Salvador,
	Yang Zhang, Pankaj Gupta, Konrad Rzeszutek Wilk,
	Nitesh Narayan Lal, Rik van Riel, lcapitulino, Wang, Wei W,
	Andrea Arcangeli, ying.huang, Paolo Bonzini, Dan Williams,
	Fengguang Wu, Kirill A. Shutemov

On 11.09.19 14:25, Michal Hocko wrote:
> On Wed 11-09-19 14:19:41, Michal Hocko wrote:
>> On Wed 11-09-19 08:08:38, Michael S. Tsirkin wrote:
>>> On Wed, Sep 11, 2019 at 01:36:19PM +0200, Michal Hocko wrote:
>>>> On Tue 10-09-19 14:23:40, Alexander Duyck wrote:
>>>> [...]
>>>>> We don't put any limitations on the allocator other then that it needs to
>>>>> clean up the metadata on allocation, and that it cannot allocate a page
>>>>> that is in the process of being reported since we pulled it from the
>>>>> free_list. If the page is a "Reported" page then it decrements the
>>>>> reported_pages count for the free_area and makes sure the page doesn't
>>>>> exist in the "Boundary" array pointer value, if it does it moves the
>>>>> "Boundary" since it is pulling the page.
>>>>
>>>> This is still a non-trivial limitation on the page allocation from an
>>>> external code IMHO. I cannot give any explicit reason why an ordering on
>>>> the free list might matter (well except for page shuffling which uses it
>>>> to make physical memory pattern allocation more random) but the
>>>> architecture seems hacky and dubious to be honest. It shoulds like the
>>>> whole interface has been developed around a very particular and single
>>>> purpose optimization.
>>>>
>>>> I remember that there was an attempt to report free memory that provided
>>>> a callback mechanism [1], which was much less intrusive to the internals
>>>> of the allocator yet it should provide a similar functionality. Did you
>>>> see that approach? How does this compares to it? Or am I completely off
>>>> when comparing them?
>>>>
>>>> [1] mostly likely not the latest version of the patchset
>>>> http://lkml.kernel.org/r/1502940416-42944-5-git-send-email-wei.w.wang@intel.com
>>>
>>> Linus nacked that one. He thinks invoking callbacks with lots of
>>> internal mm locks is too fragile.
>>
>> I would be really curious how much he would be happy about injecting
>> other restrictions on the allocator like this patch proposes. This is
>> more intrusive as it has a higher maintenance cost longterm IMHO.
> 
> Btw. I do agree that callbacks with internal mm locks are not great
> either. We do have a model for that in mmu_notifiers and it is something
> I do consider PITA, on the other hand it is mostly sleepable part of the
> interface which makes it the real pain. The above callback mechanism was
> explicitly documented with restrictions and that the context is
> essentially atomic with no access to particular struct pages and no
> expensive operations possible. So in the end I've considered it
> acceptably painful. Not that I want to override Linus' nack but if
> virtualization usecases really require some form of reporting and no
> other way to do that push people to invent even more interesting
> approaches then we should simply give them/you something reasonable
> and least intrusive to our internals.
> 

The issue with "[PATCH v14 4/5] mm: support reporting free page blocks"
 is that it cannot really handle the use case we have here if I am not
wrong. While a page is getting processed by the hypervisor (e.g.
MADV_DONTNEED), it must not get reused.

"Some page blocks may
leave the free list after zone->lock is released, so it is the caller's
responsibility to either detect or prevent the use of such pages."

If I'm not wrong, this only made sense to speed up migration in the
hypervisor, where you can deal with false positives differently.

-- 

Thanks,

David / dhildenb

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: [PATCH v9 0/8] stg mail -e --version=v9 \
  2019-09-11 12:42                     ` David Hildenbrand
@ 2019-09-11 12:54                       ` Michal Hocko
  2019-09-11 13:03                         ` David Hildenbrand
  2019-09-11 13:19                         ` Nitesh Narayan Lal
  2019-09-11 12:55                       ` Nitesh Narayan Lal
  1 sibling, 2 replies; 82+ messages in thread
From: Michal Hocko @ 2019-09-11 12:54 UTC (permalink / raw)
  To: David Hildenbrand
  Cc: Michael S. Tsirkin, Alexander Duyck, Alexander Duyck, virtio-dev,
	kvm list, Catalin Marinas, Dave Hansen, LKML, Matthew Wilcox,
	linux-mm, Andrew Morton, will, linux-arm-kernel, Oscar Salvador,
	Yang Zhang, Pankaj Gupta, Konrad Rzeszutek Wilk,
	Nitesh Narayan Lal, Rik van Riel, lcapitulino, Wang, Wei W,
	Andrea Arcangeli, ying.huang, Paolo Bonzini, Dan Williams,
	Fengguang Wu, Kirill A. Shutemov

On Wed 11-09-19 14:42:41, David Hildenbrand wrote:
> On 11.09.19 14:25, Michal Hocko wrote:
> > On Wed 11-09-19 14:19:41, Michal Hocko wrote:
> >> On Wed 11-09-19 08:08:38, Michael S. Tsirkin wrote:
> >>> On Wed, Sep 11, 2019 at 01:36:19PM +0200, Michal Hocko wrote:
> >>>> On Tue 10-09-19 14:23:40, Alexander Duyck wrote:
> >>>> [...]
> >>>>> We don't put any limitations on the allocator other then that it needs to
> >>>>> clean up the metadata on allocation, and that it cannot allocate a page
> >>>>> that is in the process of being reported since we pulled it from the
> >>>>> free_list. If the page is a "Reported" page then it decrements the
> >>>>> reported_pages count for the free_area and makes sure the page doesn't
> >>>>> exist in the "Boundary" array pointer value, if it does it moves the
> >>>>> "Boundary" since it is pulling the page.
> >>>>
> >>>> This is still a non-trivial limitation on the page allocation from an
> >>>> external code IMHO. I cannot give any explicit reason why an ordering on
> >>>> the free list might matter (well except for page shuffling which uses it
> >>>> to make physical memory pattern allocation more random) but the
> >>>> architecture seems hacky and dubious to be honest. It shoulds like the
> >>>> whole interface has been developed around a very particular and single
> >>>> purpose optimization.
> >>>>
> >>>> I remember that there was an attempt to report free memory that provided
> >>>> a callback mechanism [1], which was much less intrusive to the internals
> >>>> of the allocator yet it should provide a similar functionality. Did you
> >>>> see that approach? How does this compares to it? Or am I completely off
> >>>> when comparing them?
> >>>>
> >>>> [1] mostly likely not the latest version of the patchset
> >>>> http://lkml.kernel.org/r/1502940416-42944-5-git-send-email-wei.w.wang@intel.com
> >>>
> >>> Linus nacked that one. He thinks invoking callbacks with lots of
> >>> internal mm locks is too fragile.
> >>
> >> I would be really curious how much he would be happy about injecting
> >> other restrictions on the allocator like this patch proposes. This is
> >> more intrusive as it has a higher maintenance cost longterm IMHO.
> > 
> > Btw. I do agree that callbacks with internal mm locks are not great
> > either. We do have a model for that in mmu_notifiers and it is something
> > I do consider PITA, on the other hand it is mostly sleepable part of the
> > interface which makes it the real pain. The above callback mechanism was
> > explicitly documented with restrictions and that the context is
> > essentially atomic with no access to particular struct pages and no
> > expensive operations possible. So in the end I've considered it
> > acceptably painful. Not that I want to override Linus' nack but if
> > virtualization usecases really require some form of reporting and no
> > other way to do that push people to invent even more interesting
> > approaches then we should simply give them/you something reasonable
> > and least intrusive to our internals.
> > 
> 
> The issue with "[PATCH v14 4/5] mm: support reporting free page blocks"
>  is that it cannot really handle the use case we have here if I am not
> wrong. While a page is getting processed by the hypervisor (e.g.
> MADV_DONTNEED), it must not get reused.

What prevents to use the callback to get a list of pfn ranges to work on
and then use something like start_isolate_page_range on the collected
pfn ranges to make sure nobody steals pages from under your feet, do
your thing and drop the isolated state afterwards.

I am saying somethig like because you wouldn't really want a generic
has_unmovable_pages but rather
                if (!page_ref_count(page)) {
                        if (PageBuddy(page))
                                iter += (1 << page_order(page)) - 1;
                        continue;
                }
subset of it.
-- 
Michal Hocko
SUSE Labs

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: [PATCH v9 0/8] stg mail -e --version=v9 \
  2019-09-11 12:42                     ` David Hildenbrand
  2019-09-11 12:54                       ` Michal Hocko
@ 2019-09-11 12:55                       ` Nitesh Narayan Lal
  1 sibling, 0 replies; 82+ messages in thread
From: Nitesh Narayan Lal @ 2019-09-11 12:55 UTC (permalink / raw)
  To: David Hildenbrand, Michal Hocko, Michael S. Tsirkin
  Cc: Alexander Duyck, Alexander Duyck, virtio-dev, kvm list,
	Catalin Marinas, Dave Hansen, LKML, Matthew Wilcox, linux-mm,
	Andrew Morton, will, linux-arm-kernel, Oscar Salvador,
	Yang Zhang, Pankaj Gupta, Konrad Rzeszutek Wilk, Rik van Riel,
	lcapitulino, Wang, Wei W, Andrea Arcangeli, ying.huang,
	Paolo Bonzini, Dan Williams, Fengguang Wu, Kirill A. Shutemov


On 9/11/19 8:42 AM, David Hildenbrand wrote:
> On 11.09.19 14:25, Michal Hocko wrote:
>> On Wed 11-09-19 14:19:41, Michal Hocko wrote:
>>> On Wed 11-09-19 08:08:38, Michael S. Tsirkin wrote:
>>>> On Wed, Sep 11, 2019 at 01:36:19PM +0200, Michal Hocko wrote:
>>>>> On Tue 10-09-19 14:23:40, Alexander Duyck wrote:
>>>>> [...]
>>>>>> We don't put any limitations on the allocator other then that it needs to
>>>>>> clean up the metadata on allocation, and that it cannot allocate a page
>>>>>> that is in the process of being reported since we pulled it from the
>>>>>> free_list. If the page is a "Reported" page then it decrements the
>>>>>> reported_pages count for the free_area and makes sure the page doesn't
>>>>>> exist in the "Boundary" array pointer value, if it does it moves the
>>>>>> "Boundary" since it is pulling the page.
>>>>> This is still a non-trivial limitation on the page allocation from an
>>>>> external code IMHO. I cannot give any explicit reason why an ordering on
>>>>> the free list might matter (well except for page shuffling which uses it
>>>>> to make physical memory pattern allocation more random) but the
>>>>> architecture seems hacky and dubious to be honest. It shoulds like the
>>>>> whole interface has been developed around a very particular and single
>>>>> purpose optimization.
>>>>>
>>>>> I remember that there was an attempt to report free memory that provided
>>>>> a callback mechanism [1], which was much less intrusive to the internals
>>>>> of the allocator yet it should provide a similar functionality. Did you
>>>>> see that approach? How does this compares to it? Or am I completely off
>>>>> when comparing them?
>>>>>
>>>>> [1] mostly likely not the latest version of the patchset
>>>>> http://lkml.kernel.org/r/1502940416-42944-5-git-send-email-wei.w.wang@intel.com
>>>> Linus nacked that one. He thinks invoking callbacks with lots of
>>>> internal mm locks is too fragile.
>>> I would be really curious how much he would be happy about injecting
>>> other restrictions on the allocator like this patch proposes. This is
>>> more intrusive as it has a higher maintenance cost longterm IMHO.
>> Btw. I do agree that callbacks with internal mm locks are not great
>> either. We do have a model for that in mmu_notifiers and it is something
>> I do consider PITA, on the other hand it is mostly sleepable part of the
>> interface which makes it the real pain. The above callback mechanism was
>> explicitly documented with restrictions and that the context is
>> essentially atomic with no access to particular struct pages and no
>> expensive operations possible. So in the end I've considered it
>> acceptably painful. Not that I want to override Linus' nack but if
>> virtualization usecases really require some form of reporting and no
>> other way to do that push people to invent even more interesting
>> approaches then we should simply give them/you something reasonable
>> and least intrusive to our internals.
>>
> The issue with "[PATCH v14 4/5] mm: support reporting free page blocks"
>  is that it cannot really handle the use case we have here if I am not
> wrong. While a page is getting processed by the hypervisor (e.g.
> MADV_DONTNEED), it must not get reused.
>
> "Some page blocks may
> leave the free list after zone->lock is released, so it is the caller's
> responsibility to either detect or prevent the use of such pages."
>
> If I'm not wrong, this only made sense to speed up migration in the
> hypervisor, where you can deal with false positives differently.

Another difference between the two approaches is the origin from where
the reporting request is getting generated. (If I remember correctly)
In Alexander's series or in my series [1], VM is able to report pages
dynamically without any requirement of host intervention.

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


-- 
Thanks
Nitesh


^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: [PATCH v9 0/8] stg mail -e --version=v9 \
  2019-09-11 12:54                       ` Michal Hocko
@ 2019-09-11 13:03                         ` David Hildenbrand
  2019-09-11 13:20                           ` Michal Hocko
  2019-09-11 13:19                         ` Nitesh Narayan Lal
  1 sibling, 1 reply; 82+ messages in thread
From: David Hildenbrand @ 2019-09-11 13:03 UTC (permalink / raw)
  To: Michal Hocko
  Cc: Michael S. Tsirkin, Alexander Duyck, Alexander Duyck, virtio-dev,
	kvm list, Catalin Marinas, Dave Hansen, LKML, Matthew Wilcox,
	linux-mm, Andrew Morton, will, linux-arm-kernel, Oscar Salvador,
	Yang Zhang, Pankaj Gupta, Konrad Rzeszutek Wilk,
	Nitesh Narayan Lal, Rik van Riel, lcapitulino, Wang, Wei W,
	Andrea Arcangeli, ying.huang, Paolo Bonzini, Dan Williams,
	Fengguang Wu, Kirill A. Shutemov

On 11.09.19 14:54, Michal Hocko wrote:
> On Wed 11-09-19 14:42:41, David Hildenbrand wrote:
>> On 11.09.19 14:25, Michal Hocko wrote:
>>> On Wed 11-09-19 14:19:41, Michal Hocko wrote:
>>>> On Wed 11-09-19 08:08:38, Michael S. Tsirkin wrote:
>>>>> On Wed, Sep 11, 2019 at 01:36:19PM +0200, Michal Hocko wrote:
>>>>>> On Tue 10-09-19 14:23:40, Alexander Duyck wrote:
>>>>>> [...]
>>>>>>> We don't put any limitations on the allocator other then that it needs to
>>>>>>> clean up the metadata on allocation, and that it cannot allocate a page
>>>>>>> that is in the process of being reported since we pulled it from the
>>>>>>> free_list. If the page is a "Reported" page then it decrements the
>>>>>>> reported_pages count for the free_area and makes sure the page doesn't
>>>>>>> exist in the "Boundary" array pointer value, if it does it moves the
>>>>>>> "Boundary" since it is pulling the page.
>>>>>>
>>>>>> This is still a non-trivial limitation on the page allocation from an
>>>>>> external code IMHO. I cannot give any explicit reason why an ordering on
>>>>>> the free list might matter (well except for page shuffling which uses it
>>>>>> to make physical memory pattern allocation more random) but the
>>>>>> architecture seems hacky and dubious to be honest. It shoulds like the
>>>>>> whole interface has been developed around a very particular and single
>>>>>> purpose optimization.
>>>>>>
>>>>>> I remember that there was an attempt to report free memory that provided
>>>>>> a callback mechanism [1], which was much less intrusive to the internals
>>>>>> of the allocator yet it should provide a similar functionality. Did you
>>>>>> see that approach? How does this compares to it? Or am I completely off
>>>>>> when comparing them?
>>>>>>
>>>>>> [1] mostly likely not the latest version of the patchset
>>>>>> http://lkml.kernel.org/r/1502940416-42944-5-git-send-email-wei.w.wang@intel.com
>>>>>
>>>>> Linus nacked that one. He thinks invoking callbacks with lots of
>>>>> internal mm locks is too fragile.
>>>>
>>>> I would be really curious how much he would be happy about injecting
>>>> other restrictions on the allocator like this patch proposes. This is
>>>> more intrusive as it has a higher maintenance cost longterm IMHO.
>>>
>>> Btw. I do agree that callbacks with internal mm locks are not great
>>> either. We do have a model for that in mmu_notifiers and it is something
>>> I do consider PITA, on the other hand it is mostly sleepable part of the
>>> interface which makes it the real pain. The above callback mechanism was
>>> explicitly documented with restrictions and that the context is
>>> essentially atomic with no access to particular struct pages and no
>>> expensive operations possible. So in the end I've considered it
>>> acceptably painful. Not that I want to override Linus' nack but if
>>> virtualization usecases really require some form of reporting and no
>>> other way to do that push people to invent even more interesting
>>> approaches then we should simply give them/you something reasonable
>>> and least intrusive to our internals.
>>>
>>
>> The issue with "[PATCH v14 4/5] mm: support reporting free page blocks"
>>  is that it cannot really handle the use case we have here if I am not
>> wrong. While a page is getting processed by the hypervisor (e.g.
>> MADV_DONTNEED), it must not get reused.
> 
> What prevents to use the callback to get a list of pfn ranges to work on
> and then use something like start_isolate_page_range on the collected
> pfn ranges to make sure nobody steals pages from under your feet, do
> your thing and drop the isolated state afterwards.
> 
> I am saying somethig like because you wouldn't really want a generic
> has_unmovable_pages but rather
>                 if (!page_ref_count(page)) {
>                         if (PageBuddy(page))
>                                 iter += (1 << page_order(page)) - 1;
>                         continue;
>                 }
> subset of it.
> 

Something slightly similar is being performed by Nitesh's patch set. On
every free of a certain granularity, he records it in the bitmap. These
bits are "hints of free pages".

A thread then walks over the bitmap and tries to allocate the "hints".
If the pages were already reused, the bit is silently cleared.

Instead of allocating/freeing, we could only try to isolate the
pageblock, then test if free. (One of the usual issues to work around is
MAX_ORDER-1 crossing pageblocks, that might need special care)

I think you should have a look at the rough idea of Nitesh's patch set
to see if something like that is going into a better direction. The
bitmap part is in place to do bulk reporting and avoid duplicate reports.

I think main points we want (and what I am missing from callback idea
being discussed) are
1. Do bulk reporting only when a certain threshold is reached
2. Report only bigger granularities (especially, avoid THP splits in the
hypervisor - >= 2MB proofed to be effective)
3. Avoid reporting what has just been reported.
4. Continuously report, not the "one time report everything" approach.

-- 

Thanks,

David / dhildenb

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: [PATCH v9 0/8] stg mail -e --version=v9 \
  2019-09-11 12:54                       ` Michal Hocko
  2019-09-11 13:03                         ` David Hildenbrand
@ 2019-09-11 13:19                         ` Nitesh Narayan Lal
  1 sibling, 0 replies; 82+ messages in thread
From: Nitesh Narayan Lal @ 2019-09-11 13:19 UTC (permalink / raw)
  To: Michal Hocko, David Hildenbrand
  Cc: Michael S. Tsirkin, Alexander Duyck, Alexander Duyck, virtio-dev,
	kvm list, Catalin Marinas, Dave Hansen, LKML, Matthew Wilcox,
	linux-mm, Andrew Morton, will, linux-arm-kernel, Oscar Salvador,
	Yang Zhang, Pankaj Gupta, Konrad Rzeszutek Wilk, Rik van Riel,
	lcapitulino, Wang, Wei W, Andrea Arcangeli, ying.huang,
	Paolo Bonzini, Dan Williams, Fengguang Wu, Kirill A. Shutemov


On 9/11/19 8:54 AM, Michal Hocko wrote:
> On Wed 11-09-19 14:42:41, David Hildenbrand wrote:
>> On 11.09.19 14:25, Michal Hocko wrote:
>>> On Wed 11-09-19 14:19:41, Michal Hocko wrote:
>>>> On Wed 11-09-19 08:08:38, Michael S. Tsirkin wrote:
>>>>> On Wed, Sep 11, 2019 at 01:36:19PM +0200, Michal Hocko wrote:
>>>>>> On Tue 10-09-19 14:23:40, Alexander Duyck wrote:
>>>>>> [...]
>>>>>>> We don't put any limitations on the allocator other then that it needs to
>>>>>>> clean up the metadata on allocation, and that it cannot allocate a page
>>>>>>> that is in the process of being reported since we pulled it from the
>>>>>>> free_list. If the page is a "Reported" page then it decrements the
>>>>>>> reported_pages count for the free_area and makes sure the page doesn't
>>>>>>> exist in the "Boundary" array pointer value, if it does it moves the
>>>>>>> "Boundary" since it is pulling the page.
>>>>>> This is still a non-trivial limitation on the page allocation from an
>>>>>> external code IMHO. I cannot give any explicit reason why an ordering on
>>>>>> the free list might matter (well except for page shuffling which uses it
>>>>>> to make physical memory pattern allocation more random) but the
>>>>>> architecture seems hacky and dubious to be honest. It shoulds like the
>>>>>> whole interface has been developed around a very particular and single
>>>>>> purpose optimization.
>>>>>>
>>>>>> I remember that there was an attempt to report free memory that provided
>>>>>> a callback mechanism [1], which was much less intrusive to the internals
>>>>>> of the allocator yet it should provide a similar functionality. Did you
>>>>>> see that approach? How does this compares to it? Or am I completely off
>>>>>> when comparing them?
>>>>>>
>>>>>> [1] mostly likely not the latest version of the patchset
>>>>>> http://lkml.kernel.org/r/1502940416-42944-5-git-send-email-wei.w.wang@intel.com
>>>>> Linus nacked that one. He thinks invoking callbacks with lots of
>>>>> internal mm locks is too fragile.
>>>> I would be really curious how much he would be happy about injecting
>>>> other restrictions on the allocator like this patch proposes. This is
>>>> more intrusive as it has a higher maintenance cost longterm IMHO.
>>> Btw. I do agree that callbacks with internal mm locks are not great
>>> either. We do have a model for that in mmu_notifiers and it is something
>>> I do consider PITA, on the other hand it is mostly sleepable part of the
>>> interface which makes it the real pain. The above callback mechanism was
>>> explicitly documented with restrictions and that the context is
>>> essentially atomic with no access to particular struct pages and no
>>> expensive operations possible. So in the end I've considered it
>>> acceptably painful. Not that I want to override Linus' nack but if
>>> virtualization usecases really require some form of reporting and no
>>> other way to do that push people to invent even more interesting
>>> approaches then we should simply give them/you something reasonable
>>> and least intrusive to our internals.
>>>
>> The issue with "[PATCH v14 4/5] mm: support reporting free page blocks"
>>  is that it cannot really handle the use case we have here if I am not
>> wrong. While a page is getting processed by the hypervisor (e.g.
>> MADV_DONTNEED), it must not get reused.
> What prevents to use the callback to get a list of pfn ranges to work on
> and then use something like start_isolate_page_range on the collected
> pfn ranges to make sure nobody steals pages from under your feet, do
> your thing and drop the isolated state afterwards.
>

In my series, I am doing something similar.
- Track (MAX_ORDER - 2) free pages in bitmap maintained on a per-zone
  basis.
- Use __isolate_free_page on the pages marked in the bitmap and are
  still free.
- Report chunks of 16 isolated pages to the hypervisor.
- Return them back to the buddy once the request is processed.

> I am saying somethig like because you wouldn't really want a generic
> has_unmovable_pages but rather
>                 if (!page_ref_count(page)) {
>                         if (PageBuddy(page))
>                                 iter += (1 << page_order(page)) - 1;
>                         continue;
>                 }
> subset of it.
-- 
Thanks
Nitesh


^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: [PATCH v9 0/8] stg mail -e --version=v9 \
  2019-09-11 13:03                         ` David Hildenbrand
@ 2019-09-11 13:20                           ` Michal Hocko
  2019-09-11 13:51                             ` Michal Hocko
                                               ` (2 more replies)
  0 siblings, 3 replies; 82+ messages in thread
From: Michal Hocko @ 2019-09-11 13:20 UTC (permalink / raw)
  To: David Hildenbrand
  Cc: Michael S. Tsirkin, Alexander Duyck, Alexander Duyck, virtio-dev,
	kvm list, Catalin Marinas, Dave Hansen, LKML, Matthew Wilcox,
	linux-mm, Andrew Morton, will, linux-arm-kernel, Oscar Salvador,
	Yang Zhang, Pankaj Gupta, Konrad Rzeszutek Wilk,
	Nitesh Narayan Lal, Rik van Riel, lcapitulino, Wang, Wei W,
	Andrea Arcangeli, ying.huang, Paolo Bonzini, Dan Williams,
	Fengguang Wu, Kirill A. Shutemov

On Wed 11-09-19 15:03:39, David Hildenbrand wrote:
> On 11.09.19 14:54, Michal Hocko wrote:
> > On Wed 11-09-19 14:42:41, David Hildenbrand wrote:
> >> On 11.09.19 14:25, Michal Hocko wrote:
> >>> On Wed 11-09-19 14:19:41, Michal Hocko wrote:
> >>>> On Wed 11-09-19 08:08:38, Michael S. Tsirkin wrote:
> >>>>> On Wed, Sep 11, 2019 at 01:36:19PM +0200, Michal Hocko wrote:
> >>>>>> On Tue 10-09-19 14:23:40, Alexander Duyck wrote:
> >>>>>> [...]
> >>>>>>> We don't put any limitations on the allocator other then that it needs to
> >>>>>>> clean up the metadata on allocation, and that it cannot allocate a page
> >>>>>>> that is in the process of being reported since we pulled it from the
> >>>>>>> free_list. If the page is a "Reported" page then it decrements the
> >>>>>>> reported_pages count for the free_area and makes sure the page doesn't
> >>>>>>> exist in the "Boundary" array pointer value, if it does it moves the
> >>>>>>> "Boundary" since it is pulling the page.
> >>>>>>
> >>>>>> This is still a non-trivial limitation on the page allocation from an
> >>>>>> external code IMHO. I cannot give any explicit reason why an ordering on
> >>>>>> the free list might matter (well except for page shuffling which uses it
> >>>>>> to make physical memory pattern allocation more random) but the
> >>>>>> architecture seems hacky and dubious to be honest. It shoulds like the
> >>>>>> whole interface has been developed around a very particular and single
> >>>>>> purpose optimization.
> >>>>>>
> >>>>>> I remember that there was an attempt to report free memory that provided
> >>>>>> a callback mechanism [1], which was much less intrusive to the internals
> >>>>>> of the allocator yet it should provide a similar functionality. Did you
> >>>>>> see that approach? How does this compares to it? Or am I completely off
> >>>>>> when comparing them?
> >>>>>>
> >>>>>> [1] mostly likely not the latest version of the patchset
> >>>>>> http://lkml.kernel.org/r/1502940416-42944-5-git-send-email-wei.w.wang@intel.com
> >>>>>
> >>>>> Linus nacked that one. He thinks invoking callbacks with lots of
> >>>>> internal mm locks is too fragile.
> >>>>
> >>>> I would be really curious how much he would be happy about injecting
> >>>> other restrictions on the allocator like this patch proposes. This is
> >>>> more intrusive as it has a higher maintenance cost longterm IMHO.
> >>>
> >>> Btw. I do agree that callbacks with internal mm locks are not great
> >>> either. We do have a model for that in mmu_notifiers and it is something
> >>> I do consider PITA, on the other hand it is mostly sleepable part of the
> >>> interface which makes it the real pain. The above callback mechanism was
> >>> explicitly documented with restrictions and that the context is
> >>> essentially atomic with no access to particular struct pages and no
> >>> expensive operations possible. So in the end I've considered it
> >>> acceptably painful. Not that I want to override Linus' nack but if
> >>> virtualization usecases really require some form of reporting and no
> >>> other way to do that push people to invent even more interesting
> >>> approaches then we should simply give them/you something reasonable
> >>> and least intrusive to our internals.
> >>>
> >>
> >> The issue with "[PATCH v14 4/5] mm: support reporting free page blocks"
> >>  is that it cannot really handle the use case we have here if I am not
> >> wrong. While a page is getting processed by the hypervisor (e.g.
> >> MADV_DONTNEED), it must not get reused.
> > 
> > What prevents to use the callback to get a list of pfn ranges to work on
> > and then use something like start_isolate_page_range on the collected
> > pfn ranges to make sure nobody steals pages from under your feet, do
> > your thing and drop the isolated state afterwards.
> > 
> > I am saying somethig like because you wouldn't really want a generic
> > has_unmovable_pages but rather
> >                 if (!page_ref_count(page)) {
> >                         if (PageBuddy(page))
> >                                 iter += (1 << page_order(page)) - 1;
> >                         continue;
> >                 }
> > subset of it.
> > 
> 
> Something slightly similar is being performed by Nitesh's patch set. On
> every free of a certain granularity, he records it in the bitmap. These
> bits are "hints of free pages".
> 
> A thread then walks over the bitmap and tries to allocate the "hints".
> If the pages were already reused, the bit is silently cleared.
> 
> Instead of allocating/freeing, we could only try to isolate the
> pageblock, then test if free. (One of the usual issues to work around is
> MAX_ORDER-1 crossing pageblocks, that might need special care)

OK, cool that I have reinvented the wheel ;). Allocation is indeed not
necessary as long as pages are isolated because nobody will allocate
them.
 
> I think you should have a look at the rough idea of Nitesh's patch set
> to see if something like that is going into a better direction. The
> bitmap part is in place to do bulk reporting and avoid duplicate reports.

Let's see how much time I can find for that in my endless inbox whack a mole.
 
> I think main points we want (and what I am missing from callback idea
> being discussed) are
> 1. Do bulk reporting only when a certain threshold is reached

Is a time based approach too coarse?

> 2. Report only bigger granularities (especially, avoid THP splits in the
> hypervisor - >= 2MB proofed to be effective)

the callback has supported order based scan in some of its iteration.

> 3. Avoid reporting what has just been reported.

Is the overhead of checking a pfn range in a bitmask that much of an
overhead to really care?

> 4. Continuously report, not the "one time report everything" approach.

So you mean the allocator reporting this rather than an external code to
poll right? I do not know, how much this is nice to have than must have?
-- 
Michal Hocko
SUSE Labs

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: [PATCH v9 0/8] stg mail -e --version=v9 \
  2019-09-11 13:20                           ` Michal Hocko
@ 2019-09-11 13:51                             ` Michal Hocko
  2019-09-11 16:09                               ` David Hildenbrand
  2019-09-11 14:03                             ` Nitesh Narayan Lal
  2019-09-11 16:02                             ` David Hildenbrand
  2 siblings, 1 reply; 82+ messages in thread
From: Michal Hocko @ 2019-09-11 13:51 UTC (permalink / raw)
  To: David Hildenbrand
  Cc: Michael S. Tsirkin, Alexander Duyck, Alexander Duyck, virtio-dev,
	kvm list, Catalin Marinas, Dave Hansen, LKML, Matthew Wilcox,
	linux-mm, Andrew Morton, will, linux-arm-kernel, Oscar Salvador,
	Yang Zhang, Pankaj Gupta, Konrad Rzeszutek Wilk,
	Nitesh Narayan Lal, Rik van Riel, lcapitulino, Wang, Wei W,
	Andrea Arcangeli, ying.huang, Paolo Bonzini, Dan Williams,
	Fengguang Wu, Kirill A. Shutemov

On Wed 11-09-19 15:20:02, Michal Hocko wrote:
[...]
> > 4. Continuously report, not the "one time report everything" approach.
> 
> So you mean the allocator reporting this rather than an external code to
> poll right? I do not know, how much this is nice to have than must have?

Another idea that I haven't really thought through so it might turned
out to be completely bogus but let's try anyway. Your "report everything"
just made me look and realize that free_pages_prepare already performs
stuff that actually does something similar yet unrelated.

We do report to special page poisoning, zeroying or
CONFIG_DEBUG_PAGEALLOC to unmap the address from the kernel address
space. This sounds like something fitting your model no?
-- 
Michal Hocko
SUSE Labs

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: [PATCH v9 0/8] stg mail -e --version=v9 \
  2019-09-11 13:20                           ` Michal Hocko
  2019-09-11 13:51                             ` Michal Hocko
@ 2019-09-11 14:03                             ` Nitesh Narayan Lal
  2019-09-11 16:02                             ` David Hildenbrand
  2 siblings, 0 replies; 82+ messages in thread
From: Nitesh Narayan Lal @ 2019-09-11 14:03 UTC (permalink / raw)
  To: Michal Hocko, David Hildenbrand
  Cc: Michael S. Tsirkin, Alexander Duyck, Alexander Duyck, virtio-dev,
	kvm list, Catalin Marinas, Dave Hansen, LKML, Matthew Wilcox,
	linux-mm, Andrew Morton, will, linux-arm-kernel, Oscar Salvador,
	Yang Zhang, Pankaj Gupta, Konrad Rzeszutek Wilk, Rik van Riel,
	lcapitulino, Wang, Wei W, Andrea Arcangeli, ying.huang,
	Paolo Bonzini, Dan Williams, Fengguang Wu, Kirill A. Shutemov


On 9/11/19 9:20 AM, Michal Hocko wrote:
> On Wed 11-09-19 15:03:39, David Hildenbrand wrote:
>> On 11.09.19 14:54, Michal Hocko wrote:
>>> On Wed 11-09-19 14:42:41, David Hildenbrand wrote:
>>>> On 11.09.19 14:25, Michal Hocko wrote:
>>>>> On Wed 11-09-19 14:19:41, Michal Hocko wrote:
>>>>>> On Wed 11-09-19 08:08:38, Michael S. Tsirkin wrote:
>>>>>>> On Wed, Sep 11, 2019 at 01:36:19PM +0200, Michal Hocko wrote:
>>>>>>>> On Tue 10-09-19 14:23:40, Alexander Duyck wrote:
>>>>>>>> [...]
>>>>>>>>> We don't put any limitations on the allocator other then that it needs to
>>>>>>>>> clean up the metadata on allocation, and that it cannot allocate a page
>>>>>>>>> that is in the process of being reported since we pulled it from the
>>>>>>>>> free_list. If the page is a "Reported" page then it decrements the
>>>>>>>>> reported_pages count for the free_area and makes sure the page doesn't
>>>>>>>>> exist in the "Boundary" array pointer value, if it does it moves the
>>>>>>>>> "Boundary" since it is pulling the page.
>>>>>>>> This is still a non-trivial limitation on the page allocation from an
>>>>>>>> external code IMHO. I cannot give any explicit reason why an ordering on
>>>>>>>> the free list might matter (well except for page shuffling which uses it
>>>>>>>> to make physical memory pattern allocation more random) but the
>>>>>>>> architecture seems hacky and dubious to be honest. It shoulds like the
>>>>>>>> whole interface has been developed around a very particular and single
>>>>>>>> purpose optimization.
>>>>>>>>
>>>>>>>> I remember that there was an attempt to report free memory that provided
>>>>>>>> a callback mechanism [1], which was much less intrusive to the internals
>>>>>>>> of the allocator yet it should provide a similar functionality. Did you
>>>>>>>> see that approach? How does this compares to it? Or am I completely off
>>>>>>>> when comparing them?
>>>>>>>>
>>>>>>>> [1] mostly likely not the latest version of the patchset
>>>>>>>> http://lkml.kernel.org/r/1502940416-42944-5-git-send-email-wei.w.wang@intel.com
>>>>>>> Linus nacked that one. He thinks invoking callbacks with lots of
>>>>>>> internal mm locks is too fragile.
>>>>>> I would be really curious how much he would be happy about injecting
>>>>>> other restrictions on the allocator like this patch proposes. This is
>>>>>> more intrusive as it has a higher maintenance cost longterm IMHO.
>>>>> Btw. I do agree that callbacks with internal mm locks are not great
>>>>> either. We do have a model for that in mmu_notifiers and it is something
>>>>> I do consider PITA, on the other hand it is mostly sleepable part of the
>>>>> interface which makes it the real pain. The above callback mechanism was
>>>>> explicitly documented with restrictions and that the context is
>>>>> essentially atomic with no access to particular struct pages and no
>>>>> expensive operations possible. So in the end I've considered it
>>>>> acceptably painful. Not that I want to override Linus' nack but if
>>>>> virtualization usecases really require some form of reporting and no
>>>>> other way to do that push people to invent even more interesting
>>>>> approaches then we should simply give them/you something reasonable
>>>>> and least intrusive to our internals.
>>>>>
>>>> The issue with "[PATCH v14 4/5] mm: support reporting free page blocks"
>>>>  is that it cannot really handle the use case we have here if I am not
>>>> wrong. While a page is getting processed by the hypervisor (e.g.
>>>> MADV_DONTNEED), it must not get reused.
>>> What prevents to use the callback to get a list of pfn ranges to work on
>>> and then use something like start_isolate_page_range on the collected
>>> pfn ranges to make sure nobody steals pages from under your feet, do
>>> your thing and drop the isolated state afterwards.
>>>
>>> I am saying somethig like because you wouldn't really want a generic
>>> has_unmovable_pages but rather
>>>                 if (!page_ref_count(page)) {
>>>                         if (PageBuddy(page))
>>>                                 iter += (1 << page_order(page)) - 1;
>>>                         continue;
>>>                 }
>>> subset of it.
>>>
>> Something slightly similar is being performed by Nitesh's patch set. On
>> every free of a certain granularity, he records it in the bitmap. These
>> bits are "hints of free pages".
>>
>> A thread then walks over the bitmap and tries to allocate the "hints".
>> If the pages were already reused, the bit is silently cleared.
>>
>> Instead of allocating/freeing, we could only try to isolate the
>> pageblock, then test if free. (One of the usual issues to work around is
>> MAX_ORDER-1 crossing pageblocks, that might need special care)
> OK, cool that I have reinvented the wheel ;). Allocation is indeed not
> necessary as long as pages are isolated because nobody will allocate
> them.
>  
>> I think you should have a look at the rough idea of Nitesh's patch set
>> to see if something like that is going into a better direction. The
>> bitmap part is in place to do bulk reporting and avoid duplicate reports.
> Let's see how much time I can find for that in my endless inbox whack a mole.
>  
>> I think main points we want (and what I am missing from callback idea
>> being discussed) are
>> 1. Do bulk reporting only when a certain threshold is reached
> Is a time based approach too coarse?

I haven't looked into it yet. One situation which I would definitely
want to avoid is to unnecessary invoke bitmap scans when there are not
sufficient free pages available in the zone.
I can take a look at it if required.


>
>> 2. Report only bigger granularities (especially, avoid THP splits in the
>> hypervisor - >= 2MB proofed to be effective)
> the callback has supported order based scan in some of its iteration.
>
>> 3. Avoid reporting what has just been reported.
> Is the overhead of checking a pfn range in a bitmask that much of an
> overhead to really care?

In most of the cases No. Similar to Alexander I was also running will-it-scale/
page_fault1 to analyze the performance impact of the patch series and haven't
noticed any significant degradation.
In some specific cases, we may see noticeable degradation due to the scanning
overhead.

>
>> 4. Continuously report, not the "one time report everything" approach.
> So you mean the allocator reporting this rather than an external code to
> poll right? I do not know, how much this is nice to have than must have?

Not sure if I understood the question completely.
But yes in my case any workload which is allocating and freeing pages will end
up initiating reporting requests based on the number of free pages in the zone.

-- 
Thanks
Nitesh


^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: [PATCH v9 0/8] stg mail -e --version=v9 \
  2019-09-11 11:36             ` Michal Hocko
  2019-09-11 11:47               ` David Hildenbrand
  2019-09-11 12:08               ` Michael S. Tsirkin
@ 2019-09-11 15:12               ` Alexander Duyck
  2019-09-12  9:19                 ` Michal Hocko
  2 siblings, 1 reply; 82+ messages in thread
From: Alexander Duyck @ 2019-09-11 15:12 UTC (permalink / raw)
  To: Michal Hocko
  Cc: Alexander Duyck, virtio-dev, kvm list, Michael S. Tsirkin,
	Catalin Marinas, David Hildenbrand, Dave Hansen, LKML,
	Matthew Wilcox, linux-mm, Andrew Morton, will, linux-arm-kernel,
	Oscar Salvador, Yang Zhang, Pankaj Gupta, Konrad Rzeszutek Wilk,
	Nitesh Narayan Lal, Rik van Riel, lcapitulino, Wang, Wei W,
	Andrea Arcangeli, ying.huang, Paolo Bonzini, Dan Williams,
	Fengguang Wu, Kirill A. Shutemov

On Wed, Sep 11, 2019 at 4:36 AM Michal Hocko <mhocko@kernel.org> wrote:
>
> On Tue 10-09-19 14:23:40, Alexander Duyck wrote:
> [...]
> > We don't put any limitations on the allocator other then that it needs to
> > clean up the metadata on allocation, and that it cannot allocate a page
> > that is in the process of being reported since we pulled it from the
> > free_list. If the page is a "Reported" page then it decrements the
> > reported_pages count for the free_area and makes sure the page doesn't
> > exist in the "Boundary" array pointer value, if it does it moves the
> > "Boundary" since it is pulling the page.
>
> This is still a non-trivial limitation on the page allocation from an
> external code IMHO. I cannot give any explicit reason why an ordering on
> the free list might matter (well except for page shuffling which uses it
> to make physical memory pattern allocation more random) but the
> architecture seems hacky and dubious to be honest. It shoulds like the
> whole interface has been developed around a very particular and single
> purpose optimization.

How is this any different then the code that moves a page that will
likely be merged to the tail though?

In our case the "Reported" page is likely going to be much more
expensive to allocate and use then a standard page because it will be
faulted back in. In such a case wouldn't it make sense for us to want
to keep the pages that don't require faults ahead of those pages in
the free_list so that they are more likely to be allocated? All we are
doing with the boundary list is preventing still resident pages from
being deferred behind pages that would require a page fault to get
access to.

> I remember that there was an attempt to report free memory that provided
> a callback mechanism [1], which was much less intrusive to the internals
> of the allocator yet it should provide a similar functionality. Did you
> see that approach? How does this compares to it? Or am I completely off
> when comparing them?
>
> [1] mostly likely not the latest version of the patchset
> http://lkml.kernel.org/r/1502940416-42944-5-git-send-email-wei.w.wang@intel.com

There have been a few comparisons between this patch set and the ones
from Wei Wang. In regards to the one you are pointing to the main
difference is that I am not permanently locking memory. Basically what
happens is that the iterator will take the lock, pull a few pages,
release the lock while reporting them, and then take the lock to
return those pages, grab some more, and repeat.

I was actually influenced somewhat by the suggestions that patchset
received, specifically I believe it resembles something like what was
suggested by Linus in response to v35 of that patch set:
https://lore.kernel.org/linux-mm/CA+55aFzqj8wxXnHAdUTiOomipgFONVbqKMjL_tfk7e5ar1FziQ@mail.gmail.com/

Basically where the feature Wei Wang was working on differs from this
patch set is that I need this to run continually, his only needed to
run periodically as he was just trying to identify free pages at a
fixed point in time. My goal is to identify pages that have been freed
since the last time I reported them. To do that I need a flag in the
page to identify those pages, and an iterator in the form of a
boundary pointer so that I can incrementally walk through the list
without losing track of freed pages.

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: [PATCH v9 0/8] stg mail -e --version=v9 \
  2019-09-11 13:20                           ` Michal Hocko
  2019-09-11 13:51                             ` Michal Hocko
  2019-09-11 14:03                             ` Nitesh Narayan Lal
@ 2019-09-11 16:02                             ` David Hildenbrand
  2 siblings, 0 replies; 82+ messages in thread
From: David Hildenbrand @ 2019-09-11 16:02 UTC (permalink / raw)
  To: Michal Hocko
  Cc: Michael S. Tsirkin, Alexander Duyck, Alexander Duyck, virtio-dev,
	kvm list, Catalin Marinas, Dave Hansen, LKML, Matthew Wilcox,
	linux-mm, Andrew Morton, will, linux-arm-kernel, Oscar Salvador,
	Yang Zhang, Pankaj Gupta, Konrad Rzeszutek Wilk,
	Nitesh Narayan Lal, Rik van Riel, lcapitulino, Wang, Wei W,
	Andrea Arcangeli, ying.huang, Paolo Bonzini, Dan Williams,
	Fengguang Wu, Kirill A. Shutemov

>> Something slightly similar is being performed by Nitesh's patch set. On
>> every free of a certain granularity, he records it in the bitmap. These
>> bits are "hints of free pages".
>>
>> A thread then walks over the bitmap and tries to allocate the "hints".
>> If the pages were already reused, the bit is silently cleared.
>>
>> Instead of allocating/freeing, we could only try to isolate the
>> pageblock, then test if free. (One of the usual issues to work around is
>> MAX_ORDER-1 crossing pageblocks, that might need special care)
> 
> OK, cool that I have reinvented the wheel ;). Allocation is indeed not
> necessary as long as pages are isolated because nobody will allocate
> them.

It's always good if you come to the same conclusion ;)

>  
>> I think you should have a look at the rough idea of Nitesh's patch set
>> to see if something like that is going into a better direction. The
>> bitmap part is in place to do bulk reporting and avoid duplicate reports.
> 
> Let's see how much time I can find for that in my endless inbox whack a mole.

Can totally understand - it's only a single patch.

>  
>> I think main points we want (and what I am missing from callback idea
>> being discussed) are
>> 1. Do bulk reporting only when a certain threshold is reached
> 
> Is a time based approach too coarse?

Usually that's then another parameter to fine tune, something to avoid
when just reporting continuously. I wouldn't say it's a no go, but at
least I would prefer right now to do it continuously.

> 
>> 2. Report only bigger granularities (especially, avoid THP splits in the
>> hypervisor - >= 2MB proofed to be effective)
> 
> the callback has supported order based scan in some of its iteration.

Missed that. But yeah, the other points are more important :)

> 
>> 3. Avoid reporting what has just been reported.
> 
> Is the overhead of checking a pfn range in a bitmask that much of an
> overhead to really care?

It's all about remembering what has already been reported. Nitesh solved
that via the bitmap. So he does exactly that. If we can optimize the
bitmap out - perfect - but I don't see an easy way to do that :)

> 
>> 4. Continuously report, not the "one time report everything" approach.
> 
> So you mean the allocator reporting this rather than an external code to
> poll right? I do not know, how much this is nice to have than must have?

I guess it is debatable - but I don't consider this one of the
fundamental issues. How to identify what to report and remember what has
already been reported is the main issue. Polling vs. notification is
just the cherry on top - IMHO.

-- 

Thanks,

David / dhildenb

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: [PATCH v9 0/8] stg mail -e --version=v9 \
  2019-09-11 13:51                             ` Michal Hocko
@ 2019-09-11 16:09                               ` David Hildenbrand
  2019-09-12  7:16                                 ` Michal Hocko
  0 siblings, 1 reply; 82+ messages in thread
From: David Hildenbrand @ 2019-09-11 16:09 UTC (permalink / raw)
  To: Michal Hocko
  Cc: Michael S. Tsirkin, Alexander Duyck, Alexander Duyck, virtio-dev,
	kvm list, Catalin Marinas, Dave Hansen, LKML, Matthew Wilcox,
	linux-mm, Andrew Morton, will, linux-arm-kernel, Oscar Salvador,
	Yang Zhang, Pankaj Gupta, Konrad Rzeszutek Wilk,
	Nitesh Narayan Lal, Rik van Riel, lcapitulino, Wang, Wei W,
	Andrea Arcangeli, ying.huang, Paolo Bonzini, Dan Williams,
	Fengguang Wu, Kirill A. Shutemov

On 11.09.19 15:51, Michal Hocko wrote:
> On Wed 11-09-19 15:20:02, Michal Hocko wrote:
> [...]
>>> 4. Continuously report, not the "one time report everything" approach.
>>
>> So you mean the allocator reporting this rather than an external code to
>> poll right? I do not know, how much this is nice to have than must have?
> 
> Another idea that I haven't really thought through so it might turned
> out to be completely bogus but let's try anyway. Your "report everything"
> just made me look and realize that free_pages_prepare already performs
> stuff that actually does something similar yet unrelated.
> 
> We do report to special page poisoning, zeroying or
> CONFIG_DEBUG_PAGEALLOC to unmap the address from the kernel address
> space. This sounds like something fitting your model no?
> 

AFAIKS, the poisoning/unmapping is done whenever a page is freed. I
don't quite see yet how that would help to remember if a page was
already reported. After reporting the page we would have to switch some
state (Nitesh: bitmap bit, Alexander: page flag) to identify that.

Of course, we could map the page and treat that as "the state" when we
reported it, but I am not sure that's such a good idea :)

As always, I might be very wrong ...

-- 

Thanks,

David / dhildenb

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: [PATCH v9 0/8] stg mail -e --version=v9 \
  2019-09-11 16:09                               ` David Hildenbrand
@ 2019-09-12  7:16                                 ` Michal Hocko
  2019-09-12  7:47                                   ` David Hildenbrand
  0 siblings, 1 reply; 82+ messages in thread
From: Michal Hocko @ 2019-09-12  7:16 UTC (permalink / raw)
  To: David Hildenbrand
  Cc: Michael S. Tsirkin, Alexander Duyck, Alexander Duyck, virtio-dev,
	kvm list, Catalin Marinas, Dave Hansen, LKML, Matthew Wilcox,
	linux-mm, Andrew Morton, will, linux-arm-kernel, Oscar Salvador,
	Yang Zhang, Pankaj Gupta, Konrad Rzeszutek Wilk,
	Nitesh Narayan Lal, Rik van Riel, lcapitulino, Wang, Wei W,
	Andrea Arcangeli, ying.huang, Paolo Bonzini, Dan Williams,
	Fengguang Wu, Kirill A. Shutemov

On Wed 11-09-19 18:09:18, David Hildenbrand wrote:
> On 11.09.19 15:51, Michal Hocko wrote:
> > On Wed 11-09-19 15:20:02, Michal Hocko wrote:
> > [...]
> >>> 4. Continuously report, not the "one time report everything" approach.
> >>
> >> So you mean the allocator reporting this rather than an external code to
> >> poll right? I do not know, how much this is nice to have than must have?
> > 
> > Another idea that I haven't really thought through so it might turned
> > out to be completely bogus but let's try anyway. Your "report everything"
> > just made me look and realize that free_pages_prepare already performs
> > stuff that actually does something similar yet unrelated.
> > 
> > We do report to special page poisoning, zeroying or
> > CONFIG_DEBUG_PAGEALLOC to unmap the address from the kernel address
> > space. This sounds like something fitting your model no?
> > 
> 
> AFAIKS, the poisoning/unmapping is done whenever a page is freed. I
> don't quite see yet how that would help to remember if a page was
> already reported.

Do you still have to differ that state when each page is reported?

> After reporting the page we would have to switch some
> state (Nitesh: bitmap bit, Alexander: page flag) to identify that.

Yes, you can either store the state somewhere.

> Of course, we could map the page and treat that as "the state" when we
> reported it, but I am not sure that's such a good idea :)
> 
> As always, I might be very wrong ...

I still do not fully understand the usecase so I might be equally wrong.
My thinking is along these lines. Why should you scan free pages when
you can effectively capture each freed page? If you go one step further
then post_alloc_hook would be the counterpart to know that your page has
been allocated.
-- 
Michal Hocko
SUSE Labs

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: [PATCH v9 0/8] stg mail -e --version=v9 \
  2019-09-12  7:16                                 ` Michal Hocko
@ 2019-09-12  7:47                                   ` David Hildenbrand
  2019-09-12  9:26                                     ` Michal Hocko
  2019-09-12 12:00                                     ` Nitesh Narayan Lal
  0 siblings, 2 replies; 82+ messages in thread
From: David Hildenbrand @ 2019-09-12  7:47 UTC (permalink / raw)
  To: Michal Hocko
  Cc: Michael S. Tsirkin, Alexander Duyck, Alexander Duyck, virtio-dev,
	kvm list, Catalin Marinas, Dave Hansen, LKML, Matthew Wilcox,
	linux-mm, Andrew Morton, will, linux-arm-kernel, Oscar Salvador,
	Yang Zhang, Pankaj Gupta, Konrad Rzeszutek Wilk,
	Nitesh Narayan Lal, Rik van Riel, lcapitulino, Wang, Wei W,
	Andrea Arcangeli, ying.huang, Paolo Bonzini, Dan Williams,
	Fengguang Wu, Kirill A. Shutemov

On 12.09.19 09:16, Michal Hocko wrote:
> On Wed 11-09-19 18:09:18, David Hildenbrand wrote:
>> On 11.09.19 15:51, Michal Hocko wrote:
>>> On Wed 11-09-19 15:20:02, Michal Hocko wrote:
>>> [...]
>>>>> 4. Continuously report, not the "one time report everything" approach.
>>>>
>>>> So you mean the allocator reporting this rather than an external code to
>>>> poll right? I do not know, how much this is nice to have than must have?
>>>
>>> Another idea that I haven't really thought through so it might turned
>>> out to be completely bogus but let's try anyway. Your "report everything"
>>> just made me look and realize that free_pages_prepare already performs
>>> stuff that actually does something similar yet unrelated.
>>>
>>> We do report to special page poisoning, zeroying or
>>> CONFIG_DEBUG_PAGEALLOC to unmap the address from the kernel address
>>> space. This sounds like something fitting your model no?
>>>
>>
>> AFAIKS, the poisoning/unmapping is done whenever a page is freed. I
>> don't quite see yet how that would help to remember if a page was
>> already reported.
> 
> Do you still have to differ that state when each page is reported?

Ah, very good point. I can see that the reason for this was not
discussed in this thread so far. (Alexander, Nitesh, please correct me
if I am wrong). It's buried in the long history of free page
hinting/reporting.

Some early patch sets tried to report during every free synchronously.
Free a page, report them to the hypervisor. This resulted in some issues
(especially, locking-related and the virtio + the hypervisor being
involved, resulting in unpredictable delays, quite some overhead ...).
It was no good.

One design decision then was to not report single pages, but a bunch of
pages at once. This made it necessary to "remember" the pages to be
reported and to temporarily block them from getting allocated while
reporting.

Nitesh implemented (at least) two "capture PFNs of free pages in an
array when freeing" approaches. One being synchronous from the freeing
CPU once the list was full (having similar issues as plain synchronous
reporting) and one being asynchronous by a separate thread (which solved
many locking issues).

Turned out the a simple array can quickly lead to us having to drop
"reports" to the hypervisor because the array is full and the reporting
thread was not able to keep up. Not good as well. Especially, if some
process frees a lot of memory this can happen quickly and Nitesh wa
sable to trigger this scenario frequently.

Finally, Nitesh decided to use the bitmap instead to keep track of pages
to report. I'd like to note that this approach could still be combined
with an "array of potentially free PFNs". Only when the array/circular
buffer runs out of entries ("reporting thread cannot keep up"), we would
have to go back to scanning the bitmap.

That was also the point where Alexander decided to look into integrating
tracking/handling reported/unreported pages directly in the buddy.

> 
>> After reporting the page we would have to switch some
>> state (Nitesh: bitmap bit, Alexander: page flag) to identify that.
> 
> Yes, you can either store the state somewhere.
> 
>> Of course, we could map the page and treat that as "the state" when we
>> reported it, but I am not sure that's such a good idea :)
>>
>> As always, I might be very wrong ...
> 
> I still do not fully understand the usecase so I might be equally wrong.
> My thinking is along these lines. Why should you scan free pages when
> you can effectively capture each freed page? If you go one step further
> then post_alloc_hook would be the counterpart to know that your page has
> been allocated.

I'd like to note that Nitesh's patch set contains the following hunk,
which is roughly what you were thinking :)


-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)
+		int migratetype, bool hint)
 {
 	unsigned long combined_pfn;
 	unsigned long uninitialized_var(buddy_pfn);
@@ -980,7 +981,8 @@ static inline void __free_one_page(struct page *page,
 				migratetype);
 	else
 		add_to_free_area(page, &zone->free_area[order], migratetype);
-
+	if (hint)
+		page_hinting_enqueue(page, order);
 }


(ignore the hint parameter, when he would switch to a isolate vs.
alloc/free, that can go away and all we left is the enqueue part)


Inside that callback we can remember the pages any way we want. Right
now in a bitmap. Maybe later in a array + bitmap (as discussed above).
Another idea I had was to simply go over all pages and report them when
running into this "array full" condition. But I am not yet sure about
the performance implications on rather large machines. So the bitmap
idea might have some other limitations but seems to do its job.

Hoe that makes things clearer and am not missing something.

-- 

Thanks,

David / dhildenb

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: [PATCH v9 0/8] stg mail -e --version=v9 \
  2019-09-11 15:12               ` Alexander Duyck
@ 2019-09-12  9:19                 ` Michal Hocko
  2019-09-12 10:24                   ` Kirill A. Shutemov
                                     ` (2 more replies)
  0 siblings, 3 replies; 82+ messages in thread
From: Michal Hocko @ 2019-09-12  9:19 UTC (permalink / raw)
  To: Alexander Duyck
  Cc: Alexander Duyck, virtio-dev, kvm list, Michael S. Tsirkin,
	Catalin Marinas, David Hildenbrand, Dave Hansen, LKML,
	Matthew Wilcox, linux-mm, Andrew Morton, will, linux-arm-kernel,
	Oscar Salvador, Yang Zhang, Pankaj Gupta, Konrad Rzeszutek Wilk,
	Nitesh Narayan Lal, Rik van Riel, lcapitulino, Wang, Wei W,
	Andrea Arcangeli, ying.huang, Paolo Bonzini, Dan Williams,
	Fengguang Wu, Kirill A. Shutemov, Mel Gorman, Vlastimil Babka

On Wed 11-09-19 08:12:03, Alexander Duyck wrote:
> On Wed, Sep 11, 2019 at 4:36 AM Michal Hocko <mhocko@kernel.org> wrote:
> >
> > On Tue 10-09-19 14:23:40, Alexander Duyck wrote:
> > [...]
> > > We don't put any limitations on the allocator other then that it needs to
> > > clean up the metadata on allocation, and that it cannot allocate a page
> > > that is in the process of being reported since we pulled it from the
> > > free_list. If the page is a "Reported" page then it decrements the
> > > reported_pages count for the free_area and makes sure the page doesn't
> > > exist in the "Boundary" array pointer value, if it does it moves the
> > > "Boundary" since it is pulling the page.
> >
> > This is still a non-trivial limitation on the page allocation from an
> > external code IMHO. I cannot give any explicit reason why an ordering on
> > the free list might matter (well except for page shuffling which uses it
> > to make physical memory pattern allocation more random) but the
> > architecture seems hacky and dubious to be honest. It shoulds like the
> > whole interface has been developed around a very particular and single
> > purpose optimization.
> 
> How is this any different then the code that moves a page that will
> likely be merged to the tail though?

I guess you are referring to the page shuffling. If that is the case
then this is an integral part of the allocator for a reason and it is
very well obvious in the code including the consequences. I do not
really like an idea of hiding similar constrains behind a generic
looking feature which is completely detached from the allocator and so
any future change of the allocator might subtly break it.

> In our case the "Reported" page is likely going to be much more
> expensive to allocate and use then a standard page because it will be
> faulted back in. In such a case wouldn't it make sense for us to want
> to keep the pages that don't require faults ahead of those pages in
> the free_list so that they are more likely to be allocated?

OK, I was suspecting this would pop out. And this is exactly why I
didn't like an idea of an external code imposing a non obvious constrains
to the allocator. You simply cannot count with any ordering with the
page allocator. We used to distinguish cache hot/cold pages in the past
and pushed pages to the specific end of the free list but that has been
removed. There are other potential changes like that possible. Shuffling
is a good recent example.

Anyway I am not a maintainer of this code. I would really like to hear
opinions from Mel and Vlastimil here (now CCed - the thread starts
http://lkml.kernel.org/r/20190907172225.10910.34302.stgit@localhost.localdomain.
-- 
Michal Hocko
SUSE Labs

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: [PATCH v9 0/8] stg mail -e --version=v9 \
  2019-09-12  7:47                                   ` David Hildenbrand
@ 2019-09-12  9:26                                     ` Michal Hocko
  2019-09-12 12:00                                     ` Nitesh Narayan Lal
  1 sibling, 0 replies; 82+ messages in thread
From: Michal Hocko @ 2019-09-12  9:26 UTC (permalink / raw)
  To: David Hildenbrand
  Cc: Michael S. Tsirkin, Alexander Duyck, Alexander Duyck, virtio-dev,
	kvm list, Catalin Marinas, Dave Hansen, LKML, Matthew Wilcox,
	linux-mm, Andrew Morton, will, linux-arm-kernel, Oscar Salvador,
	Yang Zhang, Pankaj Gupta, Konrad Rzeszutek Wilk,
	Nitesh Narayan Lal, Rik van Riel, lcapitulino, Wang, Wei W,
	Andrea Arcangeli, ying.huang, Paolo Bonzini, Dan Williams,
	Fengguang Wu, Kirill A. Shutemov

On Thu 12-09-19 09:47:30, David Hildenbrand wrote:
> On 12.09.19 09:16, Michal Hocko wrote:
> > On Wed 11-09-19 18:09:18, David Hildenbrand wrote:
> >> On 11.09.19 15:51, Michal Hocko wrote:
> >>> On Wed 11-09-19 15:20:02, Michal Hocko wrote:
> >>> [...]
> >>>>> 4. Continuously report, not the "one time report everything" approach.
> >>>>
> >>>> So you mean the allocator reporting this rather than an external code to
> >>>> poll right? I do not know, how much this is nice to have than must have?
> >>>
> >>> Another idea that I haven't really thought through so it might turned
> >>> out to be completely bogus but let's try anyway. Your "report everything"
> >>> just made me look and realize that free_pages_prepare already performs
> >>> stuff that actually does something similar yet unrelated.
> >>>
> >>> We do report to special page poisoning, zeroying or
> >>> CONFIG_DEBUG_PAGEALLOC to unmap the address from the kernel address
> >>> space. This sounds like something fitting your model no?
> >>>
> >>
> >> AFAIKS, the poisoning/unmapping is done whenever a page is freed. I
> >> don't quite see yet how that would help to remember if a page was
> >> already reported.
> > 
> > Do you still have to differ that state when each page is reported?
> 
> Ah, very good point. I can see that the reason for this was not
> discussed in this thread so far. (Alexander, Nitesh, please correct me
> if I am wrong). It's buried in the long history of free page
> hinting/reporting.

It would really be preferable to summarize such a previous discussion
ideally with some references.

> Some early patch sets tried to report during every free synchronously.
> Free a page, report them to the hypervisor. This resulted in some issues
> (especially, locking-related and the virtio + the hypervisor being
> involved, resulting in unpredictable delays, quite some overhead ...).
> It was no good.
> 
> One design decision then was to not report single pages, but a bunch of
> pages at once. This made it necessary to "remember" the pages to be
> reported and to temporarily block them from getting allocated while
> reporting.
> 
> Nitesh implemented (at least) two "capture PFNs of free pages in an
> array when freeing" approaches. One being synchronous from the freeing
> CPU once the list was full (having similar issues as plain synchronous
> reporting) and one being asynchronous by a separate thread (which solved
> many locking issues).
> 
> Turned out the a simple array can quickly lead to us having to drop
> "reports" to the hypervisor because the array is full and the reporting
> thread was not able to keep up. Not good as well. Especially, if some
> process frees a lot of memory this can happen quickly and Nitesh wa
> sable to trigger this scenario frequently.
> 
> Finally, Nitesh decided to use the bitmap instead to keep track of pages
> to report. I'd like to note that this approach could still be combined
> with an "array of potentially free PFNs". Only when the array/circular
> buffer runs out of entries ("reporting thread cannot keep up"), we would
> have to go back to scanning the bitmap.
> 
> That was also the point where Alexander decided to look into integrating
> tracking/handling reported/unreported pages directly in the buddy.

OK, this gives at least some background which is really appreciated.
Explaining _why_ you need something in the core MM is essential to move
forward.
 
> >> After reporting the page we would have to switch some
> >> state (Nitesh: bitmap bit, Alexander: page flag) to identify that.
> > 
> > Yes, you can either store the state somewhere.
> > 
> >> Of course, we could map the page and treat that as "the state" when we
> >> reported it, but I am not sure that's such a good idea :)
> >>
> >> As always, I might be very wrong ...
> > 
> > I still do not fully understand the usecase so I might be equally wrong.
> > My thinking is along these lines. Why should you scan free pages when
> > you can effectively capture each freed page? If you go one step further
> > then post_alloc_hook would be the counterpart to know that your page has
> > been allocated.
> 
> I'd like to note that Nitesh's patch set contains the following hunk,
> which is roughly what you were thinking :)
> 
> 
> -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)
> +		int migratetype, bool hint)
>  {
>  	unsigned long combined_pfn;
>  	unsigned long uninitialized_var(buddy_pfn);
> @@ -980,7 +981,8 @@ static inline void __free_one_page(struct page *page,
>  				migratetype);
>  	else
>  		add_to_free_area(page, &zone->free_area[order], migratetype);
> -
> +	if (hint)
> +		page_hinting_enqueue(page, order);
>  }
> 
> 
> (ignore the hint parameter, when he would switch to a isolate vs.
> alloc/free, that can go away and all we left is the enqueue part)
> 
> 
> Inside that callback we can remember the pages any way we want. Right
> now in a bitmap. Maybe later in a array + bitmap (as discussed above).
> Another idea I had was to simply go over all pages and report them when
> running into this "array full" condition. But I am not yet sure about
> the performance implications on rather large machines. So the bitmap
> idea might have some other limitations but seems to do its job.
> 
> Hoe that makes things clearer and am not missing something.

It certainly helped me to get a better idea. I have commented on my
reservations regarding the approach in this thread elsewhere but at
least I _think_ I am getting a point of what you guys try to achieve.

Thanks!
-- 
Michal Hocko
SUSE Labs

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: [PATCH v9 0/8] stg mail -e --version=v9 \
  2019-09-12  9:19                 ` Michal Hocko
@ 2019-09-12 10:24                   ` Kirill A. Shutemov
  2019-09-12 11:11                     ` Michal Hocko
  2019-09-12 15:42                   ` Alexander Duyck
  2019-09-12 16:35                   ` Mel Gorman
  2 siblings, 1 reply; 82+ messages in thread
From: Kirill A. Shutemov @ 2019-09-12 10:24 UTC (permalink / raw)
  To: Michal Hocko
  Cc: Alexander Duyck, Alexander Duyck, virtio-dev, kvm list,
	Michael S. Tsirkin, Catalin Marinas, David Hildenbrand,
	Dave Hansen, LKML, Matthew Wilcox, linux-mm, Andrew Morton, will,
	linux-arm-kernel, Oscar Salvador, Yang Zhang, Pankaj Gupta,
	Konrad Rzeszutek Wilk, Nitesh Narayan Lal, Rik van Riel,
	lcapitulino, Wang, Wei W, Andrea Arcangeli, ying.huang,
	Paolo Bonzini, Dan Williams, Fengguang Wu, Kirill A. Shutemov,
	Mel Gorman, Vlastimil Babka

On Thu, Sep 12, 2019 at 11:19:25AM +0200, Michal Hocko wrote:
> On Wed 11-09-19 08:12:03, Alexander Duyck wrote:
> > On Wed, Sep 11, 2019 at 4:36 AM Michal Hocko <mhocko@kernel.org> wrote:
> > >
> > > On Tue 10-09-19 14:23:40, Alexander Duyck wrote:
> > > [...]
> > > > We don't put any limitations on the allocator other then that it needs to
> > > > clean up the metadata on allocation, and that it cannot allocate a page
> > > > that is in the process of being reported since we pulled it from the
> > > > free_list. If the page is a "Reported" page then it decrements the
> > > > reported_pages count for the free_area and makes sure the page doesn't
> > > > exist in the "Boundary" array pointer value, if it does it moves the
> > > > "Boundary" since it is pulling the page.
> > >
> > > This is still a non-trivial limitation on the page allocation from an
> > > external code IMHO. I cannot give any explicit reason why an ordering on
> > > the free list might matter (well except for page shuffling which uses it
> > > to make physical memory pattern allocation more random) but the
> > > architecture seems hacky and dubious to be honest. It shoulds like the
> > > whole interface has been developed around a very particular and single
> > > purpose optimization.
> > 
> > How is this any different then the code that moves a page that will
> > likely be merged to the tail though?
> 
> I guess you are referring to the page shuffling. If that is the case
> then this is an integral part of the allocator for a reason and it is
> very well obvious in the code including the consequences. I do not
> really like an idea of hiding similar constrains behind a generic
> looking feature which is completely detached from the allocator and so
> any future change of the allocator might subtly break it.

I don't necessary follow why shuffling is more integral to page allocator
than reporting would be. It's next to shutffle.c under mm/ and integrated
in a simillar way.

-- 
 Kirill A. Shutemov

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: [PATCH v9 0/8] stg mail -e --version=v9 \
  2019-09-12 10:24                   ` Kirill A. Shutemov
@ 2019-09-12 11:11                     ` Michal Hocko
  0 siblings, 0 replies; 82+ messages in thread
From: Michal Hocko @ 2019-09-12 11:11 UTC (permalink / raw)
  To: Kirill A. Shutemov
  Cc: Alexander Duyck, Alexander Duyck, virtio-dev, kvm list,
	Michael S. Tsirkin, Catalin Marinas, David Hildenbrand,
	Dave Hansen, LKML, Matthew Wilcox, linux-mm, Andrew Morton, will,
	linux-arm-kernel, Oscar Salvador, Yang Zhang, Pankaj Gupta,
	Konrad Rzeszutek Wilk, Nitesh Narayan Lal, Rik van Riel,
	lcapitulino, Wang, Wei W, Andrea Arcangeli, ying.huang,
	Paolo Bonzini, Dan Williams, Fengguang Wu, Kirill A. Shutemov,
	Mel Gorman, Vlastimil Babka

On Thu 12-09-19 13:24:25, Kirill A. Shutemov wrote:
> On Thu, Sep 12, 2019 at 11:19:25AM +0200, Michal Hocko wrote:
> > On Wed 11-09-19 08:12:03, Alexander Duyck wrote:
> > > On Wed, Sep 11, 2019 at 4:36 AM Michal Hocko <mhocko@kernel.org> wrote:
> > > >
> > > > On Tue 10-09-19 14:23:40, Alexander Duyck wrote:
> > > > [...]
> > > > > We don't put any limitations on the allocator other then that it needs to
> > > > > clean up the metadata on allocation, and that it cannot allocate a page
> > > > > that is in the process of being reported since we pulled it from the
> > > > > free_list. If the page is a "Reported" page then it decrements the
> > > > > reported_pages count for the free_area and makes sure the page doesn't
> > > > > exist in the "Boundary" array pointer value, if it does it moves the
> > > > > "Boundary" since it is pulling the page.
> > > >
> > > > This is still a non-trivial limitation on the page allocation from an
> > > > external code IMHO. I cannot give any explicit reason why an ordering on
> > > > the free list might matter (well except for page shuffling which uses it
> > > > to make physical memory pattern allocation more random) but the
> > > > architecture seems hacky and dubious to be honest. It shoulds like the
> > > > whole interface has been developed around a very particular and single
> > > > purpose optimization.
> > > 
> > > How is this any different then the code that moves a page that will
> > > likely be merged to the tail though?
> > 
> > I guess you are referring to the page shuffling. If that is the case
> > then this is an integral part of the allocator for a reason and it is
> > very well obvious in the code including the consequences. I do not
> > really like an idea of hiding similar constrains behind a generic
> > looking feature which is completely detached from the allocator and so
> > any future change of the allocator might subtly break it.
> 
> I don't necessary follow why shuffling is more integral to page allocator
> than reporting would be. It's next to shutffle.c under mm/ and integrated
> in a simillar way.

The main difference from my understanding is that the page reporting is
a more generic looking feature which might grow different users over
time yet there is a hardcoded set of restrictions to the allocator. Page
shuffling is an integral part of the allocator without any other
visibility outside.

-- 
Michal Hocko
SUSE Labs

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: [PATCH v9 0/8] stg mail -e --version=v9 \
  2019-09-12  7:47                                   ` David Hildenbrand
  2019-09-12  9:26                                     ` Michal Hocko
@ 2019-09-12 12:00                                     ` Nitesh Narayan Lal
  1 sibling, 0 replies; 82+ messages in thread
From: Nitesh Narayan Lal @ 2019-09-12 12:00 UTC (permalink / raw)
  To: David Hildenbrand, Michal Hocko
  Cc: Michael S. Tsirkin, Alexander Duyck, Alexander Duyck, virtio-dev,
	kvm list, Catalin Marinas, Dave Hansen, LKML, Matthew Wilcox,
	linux-mm, Andrew Morton, will, linux-arm-kernel, Oscar Salvador,
	Yang Zhang, Pankaj Gupta, Konrad Rzeszutek Wilk, Rik van Riel,
	lcapitulino, Wang, Wei W, Andrea Arcangeli, ying.huang,
	Paolo Bonzini, Dan Williams, Fengguang Wu, Kirill A. Shutemov


On 9/12/19 3:47 AM, David Hildenbrand wrote:
> On 12.09.19 09:16, Michal Hocko wrote:
>> On Wed 11-09-19 18:09:18, David Hildenbrand wrote:
>>> On 11.09.19 15:51, Michal Hocko wrote:
>>>> On Wed 11-09-19 15:20:02, Michal Hocko wrote:
>>>> [...]
>>>>>> 4. Continuously report, not the "one time report everything" approach.
>>>>> So you mean the allocator reporting this rather than an external code to
>>>>> poll right? I do not know, how much this is nice to have than must have?
>>>> Another idea that I haven't really thought through so it might turned
>>>> out to be completely bogus but let's try anyway. Your "report everything"
>>>> just made me look and realize that free_pages_prepare already performs
>>>> stuff that actually does something similar yet unrelated.
>>>>
>>>> We do report to special page poisoning, zeroying or
>>>> CONFIG_DEBUG_PAGEALLOC to unmap the address from the kernel address
>>>> space. This sounds like something fitting your model no?
>>>>
>>> AFAIKS, the poisoning/unmapping is done whenever a page is freed. I
>>> don't quite see yet how that would help to remember if a page was
>>> already reported.
>> Do you still have to differ that state when each page is reported?
> Ah, very good point. I can see that the reason for this was not
> discussed in this thread so far. (Alexander, Nitesh, please correct me
> if I am wrong). It's buried in the long history of free page
> hinting/reporting.
>
> Some early patch sets tried to report during every free synchronously.
> Free a page, report them to the hypervisor. This resulted in some issues
> (especially, locking-related and the virtio + the hypervisor being
> involved, resulting in unpredictable delays, quite some overhead ...).
> It was no good.

+1
If I remember correctly then Alexander had posted a patch-set
prior to this series where he was reporting every page of a fixed
order from __free_one_page(). But as you said it will be costly as
it will involve one hypercall per page of reporting_order.

>
> One design decision then was to not report single pages, but a bunch of
> pages at once. This made it necessary to "remember" the pages to be
> reported and to temporarily block them from getting allocated while
> reporting.

Until my v7 posting [1] I was doing this. We did not proceed with
this as blocking allocation was not recommended for reporting.

>
> Nitesh implemented (at least) two "capture PFNs of free pages in an
> array when freeing" approaches. One being synchronous from the freeing
> CPU once the list was full (having similar issues as plain synchronous
> reporting) and one being asynchronous by a separate thread (which solved
> many locking issues).

One issue with asynchronous + array approach was that it could have lead
to false OOMs due to several pages being isolated at the same time.

>
> Turned out the a simple array can quickly lead to us having to drop
> "reports" to the hypervisor because the array is full and the reporting
> thread was not able to keep up. Not good as well. Especially, if some
> process frees a lot of memory this can happen quickly and Nitesh wa
> sable to trigger this scenario frequently.

+1

>
> Finally, Nitesh decided to use the bitmap instead to keep track of pages
> to report. I'd like to note that this approach could still be combined
> with an "array of potentially free PFNs". Only when the array/circular
> buffer runs out of entries ("reporting thread cannot keep up"), we would
> have to go back to scanning the bitmap.

I will have to think about it.

> That was also the point where Alexander decided to look into integrating
> tracking/handling reported/unreported pages directly in the buddy.
>
>>> After reporting the page we would have to switch some
>>> state (Nitesh: bitmap bit, Alexander: page flag) to identify that.
>> Yes, you can either store the state somewhere.
>>
>>> Of course, we could map the page and treat that as "the state" when we
>>> reported it, but I am not sure that's such a good idea :)
>>>
>>> As always, I might be very wrong ...
>> I still do not fully understand the usecase so I might be equally wrong.
>> My thinking is along these lines. Why should you scan free pages when
>> you can effectively capture each freed page? If you go one step further
>> then post_alloc_hook would be the counterpart to know that your page has
>> been allocated.
> I'd like to note that Nitesh's patch set contains the following hunk,
> which is roughly what you were thinking :)
>
>
> -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)
> +		int migratetype, bool hint)
>  {
>  	unsigned long combined_pfn;
>  	unsigned long uninitialized_var(buddy_pfn);
> @@ -980,7 +981,8 @@ static inline void __free_one_page(struct page *page,
>  				migratetype);
>  	else
>  		add_to_free_area(page, &zone->free_area[order], migratetype);
> -
> +	if (hint)
> +		page_hinting_enqueue(page, order);
>  }
>
>
> (ignore the hint parameter, when he would switch to a isolate vs.
> alloc/free, that can go away and all we left is the enqueue part)

Precisely.
Although, there would be a scenario where the allocation will
take place for a page whose order would be < REPORTING_ORDER.
In that case, if I decide to ignore all the remaining pages and clear
the previously head free page bit, I might end
up losing the reporting opportunity.

But I can certainly look into this.

>
>
> Inside that callback we can remember the pages any way we want. Right
> now in a bitmap. Maybe later in a array + bitmap (as discussed above).
> Another idea I had was to simply go over all pages and report them when
> running into this "array full" condition. But I am not yet sure about
> the performance implications on rather large machines. So the bitmap
> idea might have some other limitations but seems to do its job.

That's correct, I was actually trying to come up with a basic framework.
Which is acceptable in terms of benefits and performance and that can fit into
most of the use-cases (if not all).
After which my plan was to further optimize it.

>
> Hoe that makes things clearer and am not missing something.

Thanks for explaining.

>
-- 
Thanks
Nitesh


^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: [PATCH v9 0/8] stg mail -e --version=v9 \
  2019-09-12  9:19                 ` Michal Hocko
  2019-09-12 10:24                   ` Kirill A. Shutemov
@ 2019-09-12 15:42                   ` Alexander Duyck
  2019-09-12 16:35                   ` Mel Gorman
  2 siblings, 0 replies; 82+ messages in thread
From: Alexander Duyck @ 2019-09-12 15:42 UTC (permalink / raw)
  To: Michal Hocko, Alexander Duyck
  Cc: virtio-dev, kvm list, Michael S. Tsirkin, Catalin Marinas,
	David Hildenbrand, Dave Hansen, LKML, Matthew Wilcox, linux-mm,
	Andrew Morton, will, linux-arm-kernel, Oscar Salvador,
	Yang Zhang, Pankaj Gupta, Konrad Rzeszutek Wilk,
	Nitesh Narayan Lal, Rik van Riel, lcapitulino, Wang, Wei W,
	Andrea Arcangeli, ying.huang, Paolo Bonzini, Dan Williams,
	Fengguang Wu, Kirill A. Shutemov, Mel Gorman, Vlastimil Babka

On Thu, 2019-09-12 at 11:19 +0200, Michal Hocko wrote:
> On Wed 11-09-19 08:12:03, Alexander Duyck wrote:
> > On Wed, Sep 11, 2019 at 4:36 AM Michal Hocko <mhocko@kernel.org> wrote:
> > > On Tue 10-09-19 14:23:40, Alexander Duyck wrote:
> > > [...]
> > > > We don't put any limitations on the allocator other then that it needs to
> > > > clean up the metadata on allocation, and that it cannot allocate a page
> > > > that is in the process of being reported since we pulled it from the
> > > > free_list. If the page is a "Reported" page then it decrements the
> > > > reported_pages count for the free_area and makes sure the page doesn't
> > > > exist in the "Boundary" array pointer value, if it does it moves the
> > > > "Boundary" since it is pulling the page.
> > > 
> > > This is still a non-trivial limitation on the page allocation from an
> > > external code IMHO. I cannot give any explicit reason why an ordering on
> > > the free list might matter (well except for page shuffling which uses it
> > > to make physical memory pattern allocation more random) but the
> > > architecture seems hacky and dubious to be honest. It shoulds like the
> > > whole interface has been developed around a very particular and single
> > > purpose optimization.
> > 
> > How is this any different then the code that moves a page that will
> > likely be merged to the tail though?
> 
> I guess you are referring to the page shuffling. If that is the case
> then this is an integral part of the allocator for a reason and it is
> very well obvious in the code including the consequences. I do not
> really like an idea of hiding similar constrains behind a generic
> looking feature which is completely detached from the allocator and so
> any future change of the allocator might subtly break it.
> 
> > In our case the "Reported" page is likely going to be much more
> > expensive to allocate and use then a standard page because it will be
> > faulted back in. In such a case wouldn't it make sense for us to want
> > to keep the pages that don't require faults ahead of those pages in
> > the free_list so that they are more likely to be allocated?
> 
> OK, I was suspecting this would pop out. And this is exactly why I
> didn't like an idea of an external code imposing a non obvious constrains
> to the allocator. You simply cannot count with any ordering with the
> page allocator. We used to distinguish cache hot/cold pages in the past
> and pushed pages to the specific end of the free list but that has been
> removed. There are other potential changes like that possible. Shuffling
> is a good recent example.
> 
> Anyway I am not a maintainer of this code. I would really like to hear
> opinions from Mel and Vlastimil here (now CCed - the thread starts
> http://lkml.kernel.org/r/20190907172225.10910.34302.stgit@localhost.localdomain.

One alternative I could do if we are wanting to make things more obvious
would be to add yet another add_to_free_list_XXX function that would be
used specifically for reported pages. The only real requirement I have is
that we have to insert reported pages such that we generate a continuous
block without interleaving non-reported pages in between. So as long as
reported pages are always inserted at the boundary/iterator when we are
actively reporting on a section then I can guarantee the list won't have
gaps formed.

Also as far as the concerns about this being an external user, one thing I
can do is break up the headers a bit and define an internal header in mm/
that defines all the items used by the page allocator, and another in
include/linux/ that defines what is used by devices when receiving the
notifications. It would then help to reduce the likelihood of an outside
entity messing with the page allocator too much.


^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: [PATCH v9 0/8] stg mail -e --version=v9 \
  2019-09-12  9:19                 ` Michal Hocko
  2019-09-12 10:24                   ` Kirill A. Shutemov
  2019-09-12 15:42                   ` Alexander Duyck
@ 2019-09-12 16:35                   ` Mel Gorman
  2019-09-12 17:48                     ` Alexander Duyck
  2 siblings, 1 reply; 82+ messages in thread
From: Mel Gorman @ 2019-09-12 16:35 UTC (permalink / raw)
  To: Michal Hocko
  Cc: Alexander Duyck, Alexander Duyck, virtio-dev, kvm list,
	Michael S. Tsirkin, Catalin Marinas, David Hildenbrand,
	Dave Hansen, LKML, Matthew Wilcox, linux-mm, Andrew Morton, will,
	linux-arm-kernel, Oscar Salvador, Yang Zhang, Pankaj Gupta,
	Konrad Rzeszutek Wilk, Nitesh Narayan Lal, Rik van Riel,
	lcapitulino, Wang, Wei W, Andrea Arcangeli, ying.huang,
	Paolo Bonzini, Dan Williams, Fengguang Wu, Kirill A. Shutemov,
	Mel Gorman, Vlastimil Babka

On Thu, Sep 12, 2019 at 11:19:25AM +0200, Michal Hocko wrote:
> On Wed 11-09-19 08:12:03, Alexander Duyck wrote:
> > On Wed, Sep 11, 2019 at 4:36 AM Michal Hocko <mhocko@kernel.org> wrote:
> > >
> > > On Tue 10-09-19 14:23:40, Alexander Duyck wrote:
> > > [...]
> > > > We don't put any limitations on the allocator other then that it needs to
> > > > clean up the metadata on allocation, and that it cannot allocate a page
> > > > that is in the process of being reported since we pulled it from the
> > > > free_list. If the page is a "Reported" page then it decrements the
> > > > reported_pages count for the free_area and makes sure the page doesn't
> > > > exist in the "Boundary" array pointer value, if it does it moves the
> > > > "Boundary" since it is pulling the page.
> > >
> > > This is still a non-trivial limitation on the page allocation from an
> > > external code IMHO. I cannot give any explicit reason why an ordering on
> > > the free list might matter (well except for page shuffling which uses it
> > > to make physical memory pattern allocation more random) but the
> > > architecture seems hacky and dubious to be honest. It shoulds like the
> > > whole interface has been developed around a very particular and single
> > > purpose optimization.
> > 
> > How is this any different then the code that moves a page that will
> > likely be merged to the tail though?
> 
> I guess you are referring to the page shuffling. If that is the case
> then this is an integral part of the allocator for a reason and it is
> very well obvious in the code including the consequences. I do not
> really like an idea of hiding similar constrains behind a generic
> looking feature which is completely detached from the allocator and so
> any future change of the allocator might subtly break it.
> 

It's not just that, compaction pokes into the free_area information as
well and directly takes pages from the free list without going through
the page allocator itself. It assumes that a free page is a free page
and only takes the zone and migratetype into account.

> > In our case the "Reported" page is likely going to be much more
> > expensive to allocate and use then a standard page because it will be
> > faulted back in. In such a case wouldn't it make sense for us to want
> > to keep the pages that don't require faults ahead of those pages in
> > the free_list so that they are more likely to be allocated?
> 
> OK, I was suspecting this would pop out. And this is exactly why I
> didn't like an idea of an external code imposing a non obvious constrains
> to the allocator. You simply cannot count with any ordering with the
> page allocator.

Indeed not. It can be arbitrary and compaction can interfere with the
ordering as well. While in theory that could be addressed by always
going through an interface maintained by the page allocator, it would be
tricky to test the virtio case in particular.

> We used to distinguish cache hot/cold pages in the past
> and pushed pages to the specific end of the free list but that has been
> removed.

That was always best effort too, not a hard guarantee. It was eventually
removed as the cost of figuring out the ordering exceeded the benefit.

> There are other potential changes like that possible. Shuffling
> is a good recent example.
> 
> Anyway I am not a maintainer of this code. I would really like to hear
> opinions from Mel and Vlastimil here (now CCed - the thread starts
> http://lkml.kernel.org/r/20190907172225.10910.34302.stgit@localhost.localdomain.

I worry that poking too much into the internal state of the allocator
will be fragile long-term. There is the arch alloc/free hooks but they
are typically about protections only and does not interfere with the
internal state of the allocator. Compaction pokes in as well but once
the page is off the free list, the page allocator no longer cares so
again there is on interference with the internal state. If the state is
interefered with externally, it becomes unclear what happens if things
like page merging is deferred in a way the allocator cannot control as
high-order allocation requests may fail for example. For THP, it would
not matter but failed allocation reports when pages are on the freelist,
but unsuitable for allocation because of the reported state, would be
hard to debug. Similarly, latency issues due to a reported page being
picked for allocation but requiring communication with the hypervisor
will be difficult to debug and atomic allocations may fail entirely.
Finally, if merging was broken for reported/unreported pages, it could
be a long time before such bugs were fixed.

That's a lot of caveats to optimise communication about unused free
pages to the allocator. I didn't read the patches particularly carefully
but it was not clear why a best effort was not made to track free pages
and if the metadata maintenance for that fills then do exhaustive
searches for remaining pages. It might be difficult to stabilise that as
the metadata may overflow again while the exhaustive search takes place.
Much would depend on the frequency that pages are entering/leaving
reported state.

-- 
Mel Gorman
SUSE Labs

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: [PATCH v9 0/8] stg mail -e --version=v9 \
  2019-09-12 16:35                   ` Mel Gorman
@ 2019-09-12 17:48                     ` Alexander Duyck
  0 siblings, 0 replies; 82+ messages in thread
From: Alexander Duyck @ 2019-09-12 17:48 UTC (permalink / raw)
  To: Mel Gorman, Michal Hocko
  Cc: Alexander Duyck, virtio-dev, kvm list, Michael S. Tsirkin,
	Catalin Marinas, David Hildenbrand, Dave Hansen, LKML,
	Matthew Wilcox, linux-mm, Andrew Morton, will, linux-arm-kernel,
	Oscar Salvador, Yang Zhang, Pankaj Gupta, Konrad Rzeszutek Wilk,
	Nitesh Narayan Lal, Rik van Riel, lcapitulino, Wang, Wei W,
	Andrea Arcangeli, ying.huang, Paolo Bonzini, Dan Williams,
	Fengguang Wu, Kirill A. Shutemov, Mel Gorman, Vlastimil Babka

On Thu, 2019-09-12 at 17:35 +0100, Mel Gorman wrote:
> On Thu, Sep 12, 2019 at 11:19:25AM +0200, Michal Hocko wrote:
> > On Wed 11-09-19 08:12:03, Alexander Duyck wrote:
> > > On Wed, Sep 11, 2019 at 4:36 AM Michal Hocko <mhocko@kernel.org> wrote:
> > > > On Tue 10-09-19 14:23:40, Alexander Duyck wrote:
> > > > [...]
> > > > > We don't put any limitations on the allocator other then that it needs to
> > > > > clean up the metadata on allocation, and that it cannot allocate a page
> > > > > that is in the process of being reported since we pulled it from the
> > > > > free_list. If the page is a "Reported" page then it decrements the
> > > > > reported_pages count for the free_area and makes sure the page doesn't
> > > > > exist in the "Boundary" array pointer value, if it does it moves the
> > > > > "Boundary" since it is pulling the page.
> > > > 
> > > > This is still a non-trivial limitation on the page allocation from an
> > > > external code IMHO. I cannot give any explicit reason why an ordering on
> > > > the free list might matter (well except for page shuffling which uses it
> > > > to make physical memory pattern allocation more random) but the
> > > > architecture seems hacky and dubious to be honest. It shoulds like the
> > > > whole interface has been developed around a very particular and single
> > > > purpose optimization.
> > > 
> > > How is this any different then the code that moves a page that will
> > > likely be merged to the tail though?
> > 
> > I guess you are referring to the page shuffling. If that is the case
> > then this is an integral part of the allocator for a reason and it is
> > very well obvious in the code including the consequences. I do not
> > really like an idea of hiding similar constrains behind a generic
> > looking feature which is completely detached from the allocator and so
> > any future change of the allocator might subtly break it.
> > 
> 
> It's not just that, compaction pokes into the free_area information as
> well and directly takes pages from the free list without going through
> the page allocator itself. It assumes that a free page is a free page
> and only takes the zone and migratetype into account.

Pulling pages out at random isn't an issue as long as the boundary pointer
gets pushed back. However the list tumbling with the
move_freelist_head/tail would be much more problematic for me since it is
essentially shuffling the list and will cause reported pages to be
shuffled in with non-reported ones.

> > > In our case the "Reported" page is likely going to be much more
> > > expensive to allocate and use then a standard page because it will be
> > > faulted back in. In such a case wouldn't it make sense for us to want
> > > to keep the pages that don't require faults ahead of those pages in
> > > the free_list so that they are more likely to be allocated?
> > 
> > OK, I was suspecting this would pop out. And this is exactly why I
> > didn't like an idea of an external code imposing a non obvious constrains
> > to the allocator. You simply cannot count with any ordering with the
> > page allocator.
> 
> Indeed not. It can be arbitrary and compaction can interfere with the
> ordering as well. While in theory that could be addressed by always
> going through an interface maintained by the page allocator, it would be
> tricky to test the virtio case in particular.
> 
> > We used to distinguish cache hot/cold pages in the past
> > and pushed pages to the specific end of the free list but that has been
> > removed.
> 
> That was always best effort too, not a hard guarantee. It was eventually
> removed as the cost of figuring out the ordering exceeded the benefit.
> 
> > There are other potential changes like that possible. Shuffling
> > is a good recent example.
> > 
> > Anyway I am not a maintainer of this code. I would really like to hear
> > opinions from Mel and Vlastimil here (now CCed - the thread starts
> > http://lkml.kernel.org/r/20190907172225.10910.34302.stgit@localhost.localdomain.
> 
> I worry that poking too much into the internal state of the allocator
> will be fragile long-term. There is the arch alloc/free hooks but they
> are typically about protections only and does not interfere with the
> internal state of the allocator. Compaction pokes in as well but once
> the page is off the free list, the page allocator no longer cares so
> again there is on interference with the internal state. If the state is
> interefered with externally, it becomes unclear what happens if things
> like page merging is deferred in a way the allocator cannot control as
> high-order allocation requests may fail for example. For THP, it would
> not matter but failed allocation reports when pages are on the freelist,
> but unsuitable for allocation because of the reported state, would be
> hard to debug. Similarly, latency issues due to a reported page being
> picked for allocation but requiring communication with the hypervisor
> will be difficult to debug and atomic allocations may fail entirely.
> Finally, if merging was broken for reported/unreported pages, it could
> be a long time before such bugs were fixed.

We weren't preventing allocations off of the list other then when the
pages were actually off the list and being reported. So a reported page
could still be allocated normally.

As far as state there were only two things that were really being tracked
with the Reported flag. Basically when we cleared it we needed to make
sure the boundary pointer for the freelist was checked so we could push it
back if needed, and the count for the reported pages was decremented. All
the page->index was providing was an index into the boundary array so we
could find the pointer for that specific free_list.

> That's a lot of caveats to optimise communication about unused free
> pages to the allocator. I didn't read the patches particularly carefully
> but it was not clear why a best effort was not made to track free pages
> and if the metadata maintenance for that fills then do exhaustive
> searches for remaining pages. It might be difficult to stabilise that as
> the metadata may overflow again while the exhaustive search takes place.
> Much would depend on the frequency that pages are entering/leaving
> reported state.

What I was trying to avoid is having to perform an exhaustive walk of the
free_list. I was using boundary as an iterator. Since we have to hold the
zone->lock while pulling pages I wanted to keep the critical section as
small and fast as possible.

It seems like you were somewhat accomplishing that in the compaction code
by using the move_freelist_head/tail calls to basically roll over the list
as you are working through it. Maybe I will look to see just how expensive
it would be to do something similar as that would at least partially
reduce the cost.



^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: [PATCH v9 5/8] arm64: Move hugetlb related definitions out of pgtable.h to page-defs.h
  2019-09-07 17:25 ` [PATCH v9 5/8] arm64: Move hugetlb related definitions out of pgtable.h to page-defs.h Alexander Duyck
  2019-09-09  8:52   ` David Hildenbrand
@ 2019-09-17 17:48   ` Will Deacon
  2019-09-17 20:07     ` Alexander Duyck
  1 sibling, 1 reply; 82+ messages in thread
From: Will Deacon @ 2019-09-17 17:48 UTC (permalink / raw)
  To: Alexander Duyck
  Cc: virtio-dev, kvm, mst, catalin.marinas, david, dave.hansen,
	linux-kernel, willy, mhocko, linux-mm, akpm, linux-arm-kernel,
	osalvador, yang.zhang.wz, pagupta, konrad.wilk, nitesh, riel,
	lcapitulino, wei.w.wang, aarcange, ying.huang, pbonzini,
	dan.j.williams, fengguang.wu, alexander.h.duyck, kirill.shutemov

On Sat, Sep 07, 2019 at 10:25:45AM -0700, Alexander Duyck wrote:
> From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> 
> Move the static definition for things such as HUGETLB_PAGE_ORDER out of
> asm/pgtable.h and place it in page-defs.h. By doing this the includes
> become much easier to deal with as currently arm64 is the only architecture
> that didn't include this definition in the asm/page.h file or a file
> included by it.
> 
> It also makes logical sense as PAGE_SHIFT was already defined in
> page-defs.h so now we also have HPAGE_SHIFT defined there as well.
> 
> Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> ---
>  arch/arm64/include/asm/page-def.h |    9 +++++++++
>  arch/arm64/include/asm/pgtable.h  |    9 ---------
>  2 files changed, 9 insertions(+), 9 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/page-def.h b/arch/arm64/include/asm/page-def.h
> index f99d48ecbeef..1c5b079e2482 100644
> --- a/arch/arm64/include/asm/page-def.h
> +++ b/arch/arm64/include/asm/page-def.h
> @@ -20,4 +20,13 @@
>  #define CONT_SIZE		(_AC(1, UL) << (CONT_SHIFT + PAGE_SHIFT))
>  #define CONT_MASK		(~(CONT_SIZE-1))
>  
> +/*
> + * Hugetlb definitions.
> + */
> +#define HUGE_MAX_HSTATE		4
> +#define HPAGE_SHIFT		PMD_SHIFT
> +#define HPAGE_SIZE		(_AC(1, UL) << HPAGE_SHIFT)
> +#define HPAGE_MASK		(~(HPAGE_SIZE - 1))
> +#define HUGETLB_PAGE_ORDER	(HPAGE_SHIFT - PAGE_SHIFT)
> +
>  #endif /* __ASM_PAGE_DEF_H */
> diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
> index 7576df00eb50..06a376de9bd6 100644
> --- a/arch/arm64/include/asm/pgtable.h
> +++ b/arch/arm64/include/asm/pgtable.h
> @@ -305,15 +305,6 @@ static inline int pte_same(pte_t pte_a, pte_t pte_b)
>   */
>  #define pte_mkhuge(pte)		(__pte(pte_val(pte) & ~PTE_TABLE_BIT))
>  
> -/*
> - * Hugetlb definitions.
> - */
> -#define HUGE_MAX_HSTATE		4
> -#define HPAGE_SHIFT		PMD_SHIFT
> -#define HPAGE_SIZE		(_AC(1, UL) << HPAGE_SHIFT)
> -#define HPAGE_MASK		(~(HPAGE_SIZE - 1))
> -#define HUGETLB_PAGE_ORDER	(HPAGE_SHIFT - PAGE_SHIFT)
> -

Acked-by: Will Deacon <will@kernel.org>

I'm assuming you're taking this along with the other patches, but please
shout if you'd rather it went via the arm64 tree.

Will

^ permalink raw reply	[flat|nested] 82+ messages in thread

* Re: [PATCH v9 5/8] arm64: Move hugetlb related definitions out of pgtable.h to page-defs.h
  2019-09-17 17:48   ` Will Deacon
@ 2019-09-17 20:07     ` Alexander Duyck
  0 siblings, 0 replies; 82+ messages in thread
From: Alexander Duyck @ 2019-09-17 20:07 UTC (permalink / raw)
  To: Will Deacon
  Cc: virtio-dev, kvm list, Michael S. Tsirkin, Catalin Marinas,
	David Hildenbrand, Dave Hansen, LKML, Matthew Wilcox,
	Michal Hocko, linux-mm, Andrew Morton, linux-arm-kernel,
	Oscar Salvador, Yang Zhang, Pankaj Gupta, Konrad Rzeszutek Wilk,
	Nitesh Narayan Lal, Rik van Riel, lcapitulino, Wang, Wei W,
	Andrea Arcangeli, ying.huang, Paolo Bonzini, Dan Williams,
	Fengguang Wu, Alexander Duyck, Kirill A. Shutemov

On Tue, Sep 17, 2019 at 10:49 AM Will Deacon <will@kernel.org> wrote:
>
> On Sat, Sep 07, 2019 at 10:25:45AM -0700, Alexander Duyck wrote:
> > From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> >
> > Move the static definition for things such as HUGETLB_PAGE_ORDER out of
> > asm/pgtable.h and place it in page-defs.h. By doing this the includes
> > become much easier to deal with as currently arm64 is the only architecture
> > that didn't include this definition in the asm/page.h file or a file
> > included by it.
> >
> > It also makes logical sense as PAGE_SHIFT was already defined in
> > page-defs.h so now we also have HPAGE_SHIFT defined there as well.
> >
> > Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> > ---
> >  arch/arm64/include/asm/page-def.h |    9 +++++++++
> >  arch/arm64/include/asm/pgtable.h  |    9 ---------
> >  2 files changed, 9 insertions(+), 9 deletions(-)
> >
> > diff --git a/arch/arm64/include/asm/page-def.h b/arch/arm64/include/asm/page-def.h
> > index f99d48ecbeef..1c5b079e2482 100644
> > --- a/arch/arm64/include/asm/page-def.h
> > +++ b/arch/arm64/include/asm/page-def.h
> > @@ -20,4 +20,13 @@
> >  #define CONT_SIZE            (_AC(1, UL) << (CONT_SHIFT + PAGE_SHIFT))
> >  #define CONT_MASK            (~(CONT_SIZE-1))
> >
> > +/*
> > + * Hugetlb definitions.
> > + */
> > +#define HUGE_MAX_HSTATE              4
> > +#define HPAGE_SHIFT          PMD_SHIFT
> > +#define HPAGE_SIZE           (_AC(1, UL) << HPAGE_SHIFT)
> > +#define HPAGE_MASK           (~(HPAGE_SIZE - 1))
> > +#define HUGETLB_PAGE_ORDER   (HPAGE_SHIFT - PAGE_SHIFT)
> > +
> >  #endif /* __ASM_PAGE_DEF_H */
> > diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
> > index 7576df00eb50..06a376de9bd6 100644
> > --- a/arch/arm64/include/asm/pgtable.h
> > +++ b/arch/arm64/include/asm/pgtable.h
> > @@ -305,15 +305,6 @@ static inline int pte_same(pte_t pte_a, pte_t pte_b)
> >   */
> >  #define pte_mkhuge(pte)              (__pte(pte_val(pte) & ~PTE_TABLE_BIT))
> >
> > -/*
> > - * Hugetlb definitions.
> > - */
> > -#define HUGE_MAX_HSTATE              4
> > -#define HPAGE_SHIFT          PMD_SHIFT
> > -#define HPAGE_SIZE           (_AC(1, UL) << HPAGE_SHIFT)
> > -#define HPAGE_MASK           (~(HPAGE_SIZE - 1))
> > -#define HUGETLB_PAGE_ORDER   (HPAGE_SHIFT - PAGE_SHIFT)
> > -
>
> Acked-by: Will Deacon <will@kernel.org>
>
> I'm assuming you're taking this along with the other patches, but please
> shout if you'd rather it went via the arm64 tree.
>
> Will

As it turns out I am close to submitting a v10 that doesn't need this
patch. I basically just needed to move the list manipulators out of
mmzone.h and then moved my header file out of there so I no longer
needed the code.

Thanks.

- Alex

^ permalink raw reply	[flat|nested] 82+ messages in thread

end of thread, other threads:[~2019-09-17 20:07 UTC | newest]

Thread overview: 82+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-09-07 17:25 [PATCH v9 0/8] stg mail -e --version=v9 \ Alexander Duyck
2019-09-07 17:25 ` [PATCH v9 1/8] mm: Add per-cpu logic to page shuffling Alexander Duyck
2019-09-09  8:14   ` David Hildenbrand
2019-09-09 15:11     ` Alexander Duyck
2019-09-10 12:11       ` Michal Hocko
2019-09-10 22:14         ` Alexander Duyck
2019-09-10 22:11     ` Alexander Duyck
2019-09-09  9:07   ` Kirill A. Shutemov
2019-09-09 15:12     ` Alexander Duyck
2019-09-07 17:25 ` [PATCH v9 2/8] mm: Adjust shuffle code to allow for future coalescing Alexander Duyck
2019-09-09  8:19   ` David Hildenbrand
2019-09-09  9:47   ` Kirill A. Shutemov
2019-09-09 15:22     ` Alexander Duyck
2019-09-09 15:35       ` Kirill A. Shutemov
2019-09-09 15:37         ` Alexander Duyck
2019-09-09 16:43     ` Alexander Duyck
2019-09-09 17:00       ` Kirill A. Shutemov
2019-09-10 12:20   ` Michal Hocko
2019-09-10 14:48     ` Alexander Duyck
2019-09-07 17:25 ` [PATCH v9 3/8] mm: Move set/get_pcppage_migratetype to mmzone.h Alexander Duyck
2019-09-09  8:22   ` David Hildenbrand
2019-09-09  9:56   ` Kirill A. Shutemov
2019-09-09 18:01     ` Alexander Duyck
2019-09-09 18:12       ` Alexander Duyck
2019-09-10 12:23   ` Michal Hocko
2019-09-10 14:46     ` Alexander Duyck
2019-09-10 17:45       ` Michal Hocko
2019-09-10 20:26         ` Alexander Duyck
2019-09-07 17:25 ` [PATCH v9 4/8] mm: Use zone and order instead of free area in free_list manipulators Alexander Duyck
2019-09-10 12:27   ` Michal Hocko
2019-09-07 17:25 ` [PATCH v9 5/8] arm64: Move hugetlb related definitions out of pgtable.h to page-defs.h Alexander Duyck
2019-09-09  8:52   ` David Hildenbrand
2019-09-09 15:27     ` Alexander Duyck
2019-09-17 17:48   ` Will Deacon
2019-09-17 20:07     ` Alexander Duyck
2019-09-07 17:25 ` [PATCH v9 6/8] mm: Introduce Reported pages Alexander Duyck
2019-09-09 14:42   ` Kirill A. Shutemov
2019-09-09 16:25     ` Alexander Duyck
2019-09-09 16:33       ` Kirill A. Shutemov
2019-09-07 17:26 ` [PATCH v9 7/8] virtio-balloon: Pull page poisoning config out of free page hinting Alexander Duyck
2019-09-09  8:59   ` David Hildenbrand
2019-09-09 15:31     ` Alexander Duyck
2019-09-07 17:26 ` [PATCH v9 8/8] virtio-balloon: Add support for providing unused page reports to host Alexander Duyck
2019-09-07 17:34 ` [PATCH v9 0/8] mm / virtio: Provide support for unused page reporting Alexander Duyck
2019-09-10 12:42 ` [PATCH v9 0/8] stg mail -e --version=v9 \ Michal Hocko
2019-09-10 14:42   ` Alexander Duyck
2019-09-10 14:47     ` Michal Hocko
2019-09-10 16:05       ` Alexander Duyck
2019-09-10 16:18         ` [virtio-dev] " Dr. David Alan Gilbert
2019-09-10 16:22           ` David Hildenbrand
2019-09-11  9:23             ` Michael S. Tsirkin
2019-09-11  9:50               ` David Hildenbrand
2019-09-10 17:52         ` Michal Hocko
2019-09-10 18:00           ` Michal Hocko
2019-09-10 20:37             ` Alexander Duyck
2019-09-10 21:23           ` Alexander Duyck
2019-09-11 11:36             ` Michal Hocko
2019-09-11 11:47               ` David Hildenbrand
2019-09-11 12:08               ` Michael S. Tsirkin
2019-09-11 12:19                 ` Michal Hocko
2019-09-11 12:25                   ` Michal Hocko
2019-09-11 12:42                     ` David Hildenbrand
2019-09-11 12:54                       ` Michal Hocko
2019-09-11 13:03                         ` David Hildenbrand
2019-09-11 13:20                           ` Michal Hocko
2019-09-11 13:51                             ` Michal Hocko
2019-09-11 16:09                               ` David Hildenbrand
2019-09-12  7:16                                 ` Michal Hocko
2019-09-12  7:47                                   ` David Hildenbrand
2019-09-12  9:26                                     ` Michal Hocko
2019-09-12 12:00                                     ` Nitesh Narayan Lal
2019-09-11 14:03                             ` Nitesh Narayan Lal
2019-09-11 16:02                             ` David Hildenbrand
2019-09-11 13:19                         ` Nitesh Narayan Lal
2019-09-11 12:55                       ` Nitesh Narayan Lal
2019-09-11 15:12               ` Alexander Duyck
2019-09-12  9:19                 ` Michal Hocko
2019-09-12 10:24                   ` Kirill A. Shutemov
2019-09-12 11:11                     ` Michal Hocko
2019-09-12 15:42                   ` Alexander Duyck
2019-09-12 16:35                   ` Mel Gorman
2019-09-12 17:48                     ` Alexander Duyck

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).