[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
[email protected] \
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/[email protected]/
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/[email protected]/
Dropped "waste page treatment" in favor of "page hinting"
Renamed files and functions from "aeration" to "page_hinting"
Moved from page->lru list to scatterlist
Replaced wait on refcnt in shutdown with RCU and cancel_delayed_work_sync
Virtio now uses scatterlist directly instead of 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/[email protected]/
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/[email protected]/
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/[email protected]/
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/[email protected]/
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/[email protected]/
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/[email protected]/
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/[email protected]/
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
--
From: Alexander Duyck <[email protected]>
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 <[email protected]>
Signed-off-by: Alexander Duyck <[email protected]>
---
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
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
<[email protected]> 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/[email protected]/
> 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/[email protected]/
> Dropped "waste page treatment" in favor of "page hinting"
> Renamed files and functions from "aeration" to "page_hinting"
> Moved from page->lru list to scatterlist
> Replaced wait on refcnt in shutdown with RCU and cancel_delayed_work_sync
> Virtio now uses scatterlist directly instead of 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/[email protected]/
> 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/[email protected]/
> 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/[email protected]/
> 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/[email protected]/
> 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/[email protected]/
> 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/[email protected]/
> 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/[email protected]/
> 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
>
> --
From: Alexander Duyck <[email protected]>
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 <[email protected]>
---
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
On 07.09.19 19:25, Alexander Duyck wrote:
> From: Alexander Duyck <[email protected]>
>
> 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 <[email protected]>
> Signed-off-by: Alexander Duyck <[email protected]>
> ---
> 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 <[email protected]>
--
Thanks,
David / dhildenb
On Sat, Sep 07, 2019 at 10:25:28AM -0700, Alexander Duyck wrote:
> From: Alexander Duyck <[email protected]>
>
> 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 <[email protected]>
> Signed-off-by: Alexander Duyck <[email protected]>
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
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 <[email protected]>
> > >
> > > 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 <[email protected]>
> > > Signed-off-by: Alexander Duyck <[email protected]>
> >
> > 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.
On Tue, Sep 10, 2019 at 5:42 AM Michal Hocko <[email protected]> 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.
On Tue 10-09-19 07:42:43, Alexander Duyck wrote:
> On Tue, Sep 10, 2019 at 5:42 AM Michal Hocko <[email protected]> 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
On Tue 10-09-19 07:46:50, Alexander Duyck wrote:
> On Tue, Sep 10, 2019 at 5:23 AM Michal Hocko <[email protected]> wrote:
> >
> > On Sat 07-09-19 10:25:28, Alexander Duyck wrote:
> > > From: Alexander Duyck <[email protected]>
> > >
> > > 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
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 <[email protected]>
> >
> > 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 <[email protected]>
> > Signed-off-by: Alexander Duyck <[email protected]>
>
> 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 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
On Sat 07-09-19 10:25:28, Alexander Duyck wrote:
> From: Alexander Duyck <[email protected]>
>
> 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 <[email protected]>
> Signed-off-by: Alexander Duyck <[email protected]>
> ---
> 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
On Tue, Sep 10, 2019 at 5:23 AM Michal Hocko <[email protected]> wrote:
>
> On Sat 07-09-19 10:25:28, Alexander Duyck wrote:
> > From: Alexander Duyck <[email protected]>
> >
> > 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.
On Tue, Sep 10, 2019 at 7:47 AM Michal Hocko <[email protected]> wrote:
>
> On Tue 10-09-19 07:42:43, Alexander Duyck wrote:
> > On Tue, Sep 10, 2019 at 5:42 AM Michal Hocko <[email protected]> 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.
On Tue 10-09-19 09:05:43, Alexander Duyck wrote:
> On Tue, Sep 10, 2019 at 7:47 AM Michal Hocko <[email protected]> wrote:
> >
> > On Tue 10-09-19 07:42:43, Alexander Duyck wrote:
> > > On Tue, Sep 10, 2019 at 5:42 AM Michal Hocko <[email protected]> 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
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
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 <[email protected]> wrote:
> > > On Sat 07-09-19 10:25:28, Alexander Duyck wrote:
> > > > From: Alexander Duyck <[email protected]>
> > > >
> > > > 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.
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.
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 <[email protected]> wrote:
> > > On Tue 10-09-19 07:42:43, Alexander Duyck wrote:
> > > > On Tue, Sep 10, 2019 at 5:42 AM Michal Hocko <[email protected]> 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.
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/[email protected]
--
Michal Hocko
SUSE Labs
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/[email protected]
>
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
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/[email protected]
>
> --
> Michal Hocko
> SUSE Labs
Linus nacked that one. He thinks invoking callbacks with lots of
internal mm locks is too fragile.
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/[email protected]
>
> 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
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/[email protected]
> >
> > 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
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/[email protected]
>>>
>>> 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
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/[email protected]
> >>>
> >>> 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
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/[email protected]
>>>> 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
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/[email protected]
>>>>>
>>>>> 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
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/[email protected]
> >>>>>
> >>>>> 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
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/[email protected]
>>>>> 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
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
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/[email protected]
>>>>>>> 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
On Wed, Sep 11, 2019 at 4:36 AM Michal Hocko <[email protected]> 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/[email protected]
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.
>> 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
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
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
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
On Wed 11-09-19 08:12:03, Alexander Duyck wrote:
> On Wed, Sep 11, 2019 at 4:36 AM Michal Hocko <[email protected]> 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/[email protected].
--
Michal Hocko
SUSE Labs
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
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 <[email protected]> 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
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 <[email protected]> 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
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
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 <[email protected]> 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/[email protected].
>
> 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.
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 <[email protected]> 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/[email protected].
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.
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 <[email protected]> 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/[email protected].
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