[virtio-dev] Re: [PATCH v5 0/2] virtio-fs: add virtio file system device
On Fri, Jul 26, 2019 at 01:34:16PM +0100, Dr. David Alan Gilbert wrote: > * Michael S. Tsirkin (m...@redhat.com) wrote: > > Didn't look at the spec yet, but I have a question: > > > > On Fri, Jul 26, 2019 at 10:53:36AM +0100, Stefan Hajnoczi wrote: > > > v5: > > > * Explain multiqueue semantics: no ordering, identical functionality on > > > each queue, one FUSE session state shared between all queues > > > * Explain how the FUSE session is started with a FUSE_INIT request > > > * Consistently use "submit" vs "made available" and "complete" vs "used" > > > terminology [Michael] > > > * Explain endianness [Michael] > > > * Clarify hiprio vs normal queue usage [Michael] > > > * Move SHOULD, MUST, etc wording into normative sections [Michael] > > > * Mention that FUSE_INIT negotiated state needs to be transferred during > > > live migration [Michael] > > > * State that the DAX window is mapped with writeback caching like RAM > > > [Michael] > > > * Mention DAX window mapping alignment constraints (they are > > > communicated via the FUSE protocol) [Michael] > > > * Explain that FUSE_SETUPMAPPING fails when device resources are > > > exhausted and that splitting mappings consumes resources too [Michael] > > > * Clarify access rules to DAX window - only touch memory that has a > > > mapping establised > > > * Document that DAX data persistence is achieved via FUSE_FSYNC > > > > > > The following was raised during v4 review: > > > > > > > > There is a practical problem that the QEMU process may hit the > > mmap > > > > > > limit and be unable to perform its own mmaps due to the DAX > > Window. A > > > > > > limit must be enforced on the host so that QEMU's internal mmaps > > > > > > succeed. > > > > > > > > > > But number of mmaps are already limited by dax window size which > > is > > > > > controlled by virtiofsd. So all user has to do is start with > > smaller > > > > > dax window size if this ever becomes a concern. > > > > > > > > Yes, the DAX Window size sets a hard limit on the number of mappings > > > > (window_size / page_size). I think we should still communicate a > > > > maximum number of mappings to provide more control for cases where > > the > > > > page size and DAX Window size don't produce a desirable number. > > > > > > > > Consider that window_size = 8 GB and page_size = 4 KB already yields > > > > 2,097,152 maximum mappings. Oops, that number is too large! > > > > > > Ok, so that's something which will be in virtiofsd where maximum > > number > > > of outstanding can be configured by user and if we cross that limit, > > > FUSE_SETUPMAPPING will be returned with some error? > > > > Yes, virtiofsd will enforce the limit. > > > > The guest driver will also be aware of the limit via VIRTIO > > configuration space. > > > > was this addressed? > > In this version Stefan has marked SETUPMAPPING to say it can fail if out > of resources. > > The tricky problem with specifying a limit is that the limit is more > likely to be global than to be per-device, and so specifying it in > either the virtio config space or (as looked more appropriate) fuse init > doesn't feel right. > > IMHO we should never hit the limit in practical use, so it's really just > a matter of saying that it can fail and setting a large enough limit > that non-abusive drivers dont cause a problem. Yep, I updated the spec to mention that FUSE_SETUPMAPPING fails when there are insufficient resources. Drivers expect that it can happen and will have to unmap existing mappings if they wish to make new ones. Stefan signature.asc Description: PGP signature
[virtio-dev] Re: [PATCH v5 2/2] virtio-fs: add DAX window
On Fri, Jul 26, 2019 at 07:41:57AM -0400, Michael S. Tsirkin wrote: > On Fri, Jul 26, 2019 at 10:53:38AM +0100, Stefan Hajnoczi wrote: > > Describe how shared memory region ID 0 is the DAX window and how > > FUSE_SETUPMAPPING maps file ranges into the window. > > > > Signed-off-by: Stefan Hajnoczi > > --- > > Are there any security considerations with this memory sharing? > If yes it might be a good idea to add a chapter about that, > and functionality/performance/security tradeoffs involved. I'll add statements about security. In light of recent security attacks we should mention timing side-channel attacks, although the general security model is that each virtio-fs client has full access to the files in the shared directory and therefore a certain level of trust is already required since race conditions and data corruption are possible anyway. Stefan signature.asc Description: PGP signature
[virtio-dev] [RFC][Patch v12 1/2] mm: page_reporting: core infrastructure
This patch introduces the core infrastructure for free page reporting in
virtual environments. It enables the kernel to track the free pages which
can be reported to its hypervisor so that the hypervisor could
free and reuse that memory as per its requirement.
While the pages are getting processed in the hypervisor (e.g.,
via MADV_DONTNEED), the guest must not use them, otherwise, data loss
would be possible. To avoid such a situation, these pages are
temporarily removed from the buddy. The amount of pages removed
temporarily from the buddy is governed by the backend(virtio-balloon
in our case).
To efficiently identify free pages that can to be reported to the
hypervisor, bitmaps in a coarse granularity are used. Only fairly big
chunks are reported to the hypervisor - especially, to not break up THP
in the hypervisor - "MAX_ORDER - 2" on x86, and to save space. The bits
in the bitmap are an indication whether a page *might* be free, not a
guarantee. A new hook after buddy merging sets the bits.
Bitmaps are stored per zone, protected by the zone lock. A workqueue
asynchronously processes the bitmaps, trying to isolate and report pages
that are still free. The backend (virtio-balloon) is responsible for
reporting these batched pages to the host synchronously. Once reporting/
freeing is complete, isolated pages are returned back to the buddy.
Signed-off-by: Nitesh Narayan Lal
---
include/linux/mmzone.h | 11 ++
include/linux/page_reporting.h | 63 +++
mm/Kconfig | 6 +
mm/Makefile| 1 +
mm/page_alloc.c| 42 -
mm/page_reporting.c| 332 +
6 files changed, 448 insertions(+), 7 deletions(-)
create mode 100644 include/linux/page_reporting.h
create mode 100644 mm/page_reporting.c
diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index d77d717c620c..ba5f5b508f25 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -559,6 +559,17 @@ struct zone {
/* Zone statistics */
atomic_long_t vm_stat[NR_VM_ZONE_STAT_ITEMS];
atomic_long_t vm_numa_stat[NR_VM_NUMA_STAT_ITEMS];
+#ifdef CONFIG_PAGE_REPORTING
+ /* Pointer to the bitmap in PAGE_REPORTING_MIN_ORDER granularity */
+ unsigned long *bitmap;
+ /* Preserve start and end PFN in case they change due to hotplug */
+ unsigned long base_pfn;
+ unsigned long end_pfn;
+ /* Free pages of granularity PAGE_REPORTING_MIN_ORDER */
+ atomic_t free_pages;
+ /* Number of bits required in the bitmap */
+ unsigned long nbits;
+#endif
} cacheline_internodealigned_in_smp;
enum pgdat_flags {
diff --git a/include/linux/page_reporting.h b/include/linux/page_reporting.h
new file mode 100644
index ..37a39589939d
--- /dev/null
+++ b/include/linux/page_reporting.h
@@ -0,0 +1,63 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _LINUX_PAGE_REPORTING_H
+#define _LINUX_PAGE_REPORTING_H
+
+#define PAGE_REPORTING_MIN_ORDER (MAX_ORDER - 2)
+#define PAGE_REPORTING_MAX_PAGES 16
+
+#ifdef CONFIG_PAGE_REPORTING
+struct page_reporting_config {
+ /* function to hint batch of isolated pages */
+ void (*report)(struct page_reporting_config *phconf,
+ unsigned int num_pages);
+
+ /* scatterlist to hold the isolated pages to be hinted */
+ struct scatterlist *sg;
+
+ /*
+* Maxmimum pages that are going to be hinted to the hypervisor at a
+* time of granularity >= PAGE_REPORTING_MIN_ORDER.
+*/
+ int max_pages;
+
+ /* work object to process page reporting rqeuests */
+ struct work_struct reporting_work;
+
+ /* tracks the number of reporting request processed at a time */
+ atomic_t refcnt;
+};
+
+void __page_reporting_enqueue(struct page *page);
+void __return_isolated_page(struct zone *zone, struct page *page);
+void set_pageblock_migratetype(struct page *page, int migratetype);
+
+/**
+ * page_reporting_enqueue - checks the eligibility of the freed page based on
+ * its order for further page reporting processing.
+ * @page: page which has been freed.
+ * @order: order for the the free page.
+ */
+static inline void page_reporting_enqueue(struct page *page, int order)
+{
+ if (order < PAGE_REPORTING_MIN_ORDER)
+ return;
+ __page_reporting_enqueue(page);
+}
+
+int page_reporting_enable(struct page_reporting_config *phconf);
+void page_reporting_disable(struct page_reporting_config *phconf);
+#else
+static inline void page_reporting_enqueue(struct page *page, int order)
+{
+}
+
+static inline int page_reporting_enable(struct page_reporting_config *phconf)
+{
+ return -EOPNOTSUPP;
+}
+
+static inline void page_reporting_disable(struct page_reporting_config *phconf)
+{
+}
+#endif /* CONFIG_PAGE_REPORTING */
+#endif /* _LINUX_PAGE_REPORTING_H */
diff --git a/mm/Kconfig b/mm/Kconfig
[virtio-dev] [RFC][PATCH v12 0/2] mm: Support for page reporting
This patch series proposes an efficient mechanism for reporting free memory from a guest to its hypervisor. It especially enables guests with no page cache (e.g., nvdimm, virtio-pmem) or with small page caches (e.g., ram > disk) to rapidly hand back free memory to the hypervisor. This approach has a minimal impact on the existing core-mm infrastructure. This approach tracks all freed pages of the order MAX_ORDER - 2 in bitmaps. A new hook after buddy merging is used to set the bits in the bitmap for a freed page. Each set bit is cleared after they are processed/checked for re-allocation. Bitmaps are stored on a per-zone basis and are protected by the zone lock. A workqueue asynchronously processes the bitmaps as soon as a pre-defined memory threshold is met, trying to isolate and report pages that are still free. The isolated pages are stored in a scatterlist and are reported via virtio-balloon, which is responsible for sending batched pages to the hypervisor. Once the hypervisor processed the reporting request, the isolated pages are returned back to the buddy. The thershold which defines the number of pages which will be isolated and reported to the hypervisor at a time is currently hardcoded to 16 in the guest. Benefit analysis: Number of 5 GB guests (each touching 4 to 5 GB memory) that can be launched on a 15 GB single NUMA system without using swap space in the host. Guest kernel--> Unmodified with v12 page reporting Number of guests--> 2 7 Conclusion: In a page-reporting enabled kernel, the guest is able to report most of its unused memory back to the host. Due to this on the same host, I was able to launch 7 guests without touching any swap compared to 2 which were launched with an unmodified kernel. Performance Analysis: In order to measure the performance impact of this patch-series over an unmodified kernel, I am using will-it-scale/page_fault1 on a 30 GB, 24 vcpus single NUMA guest which is affined to a single node in the host. Over several runs, I observed that with this patch-series there is a degradation of around 1-3% for certain cases. This degradation could be a result of page-zeroing overhead which comes with every page-fault in the guest. I also tried this test on a 2 NUMA node host running page reporting enabled 60GB guest also having 2 NUMA nodes and 24 vcpus. I observed a similar degradation of around 1-3% in most of the cases. For certain cases, the variability even with an unmodified kernel was around 4-6% with every fresh boot. I will continue to investigate this further to find the reason behind it. Ongoing work-items: * I have a working prototype for supporting memory hotplug/hotremove with page reporting. However, it still requires more testing and fixes specifically on the hotremove side. Right now, for any memory hotplug or hotremove request bitmap or its respective fields are not changed. Hence, memory added via hotplug is not tracked in the bitmap. Similarly, removed memory is not reported to the hypervisor by using an online memory check. * I will also have to look into the details about how to handle page poisoning scenarios and test with directly assigned devices. Changes from v11: https://lkml.org/lkml/2019/7/10/742 * Moved the fields required to manage bitmap of free pages to 'struct zone'. * Replaced the list which was used to hold and report the free pages with scatterlist. * Tried to fix the anti-kernel patterns and improve overall code quality. * Fixed a few bugs in the code which were reported in the last posting. * Moved to use MADV_DONTNEED from MADV_FREE. * Replaced page hinting in favor of page reporting. * Addressed other comments which I received in the last posting. Changes from v10: https://lkml.org/lkml/2019/6/3/943 * Added logic to take care of multiple NUMA nodes scenarios. * Simplified the logic for reporting isolated pages to the host. (Eg. replaced dynamically allocated arrays with static ones, introduced wait event instead of the loop in order to wait for a response from the host) * Added a mutex to prevent race condition when page reporting is enabled by multiple drivers. * Simplified the logic responsible for decrementing free page counter for each zone. * Simplified code structuring/naming. -- Nitesh Narayan Lal (2): mm: page_reporting: core infrastructure virtio-balloon: interface to support free page reporting drivers/virtio/Kconfig | 1 + drivers/virtio/virtio_balloon.c | 64 +- include/linux/mmzone.h | 11 + include/linux/page_reporting.h | 63 ++ include/uapi/linux/virtio_balloon.h | 1 + mm/Kconfig | 6 + mm/Makefile | 1 + mm/page_alloc.c | 42 +++- mm/page_reporting.c | 332 9 files changed, 513 insertions(+), 8 deletions(-) create mode 100644
[virtio-dev] [RFC][Patch v12 2/2] virtio-balloon: interface to support free page reporting
Enables the kernel to negotiate VIRTIO_BALLOON_F_REPORTING feature with
the host. If it is available and page_reporting_flag is set to true,
page_reporting is enabled and its callback is configured along with
the max_pages count which indicates the maximum number of pages that
can be isolated and reported at a time. Currently, only free pages of
order >= (MAX_ORDER - 2) are reported. To prevent any false OOM
max_pages count is set to 16.
By default page_reporting feature is enabled and gets loaded as soon
as the virtio-balloon driver is loaded. However, it could be disabled
by writing the page_reporting_flag which is a virtio-balloon parameter.
Signed-off-by: Nitesh Narayan Lal
---
drivers/virtio/Kconfig | 1 +
drivers/virtio/virtio_balloon.c | 64 -
include/uapi/linux/virtio_balloon.h | 1 +
3 files changed, 65 insertions(+), 1 deletion(-)
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 226fbb995fb0..defec00d4ee2 100644
--- a/drivers/virtio/virtio_balloon.c
+++ b/drivers/virtio/virtio_balloon.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
/*
* Balloon device works in 4K page units. So each page is pointed to by
@@ -46,6 +47,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
};
@@ -55,7 +57,8 @@ enum virtio_balloon_config_read {
struct virtio_balloon {
struct virtio_device *vdev;
- struct virtqueue *inflate_vq, *deflate_vq, *stats_vq, *free_page_vq;
+ struct virtqueue *inflate_vq, *deflate_vq, *stats_vq, *free_page_vq,
+*reporting_vq;
/* Balloon's own wq for cpu-intensive work items */
struct workqueue_struct *balloon_wq;
@@ -113,6 +116,9 @@ struct virtio_balloon {
/* To register a shrinker to shrink memory upon memory pressure */
struct shrinker shrinker;
+
+ /* To configure page reporting to report isolated pages */
+ struct page_reporting_config page_reporting_conf;
};
static struct virtio_device_id id_table[] = {
@@ -120,6 +126,10 @@ static struct virtio_device_id id_table[] = {
{ 0 },
};
+bool page_reporting_flag = true;
+module_param(page_reporting_flag, bool, 0644);
+MODULE_PARM_DESC(page_reporting_flag, "Enable page reporting");
+
static u32 page_to_balloon_pfn(struct page *page)
{
unsigned long pfn = page_to_pfn(page);
@@ -152,6 +162,44 @@ static void tell_host(struct virtio_balloon *vb, struct
virtqueue *vq)
}
+void virtballoon_report_pages(struct page_reporting_config
*page_reporting_conf,
+ unsigned int num_pages)
+{
+ struct virtio_balloon *vb = container_of(page_reporting_conf,
+struct virtio_balloon,
+page_reporting_conf);
+ struct virtqueue *vq = vb->reporting_vq;
+ int err, unused;
+
+ /* We should always be able to add these buffers to an empty queue. */
+ err = virtqueue_add_inbuf(vq, page_reporting_conf->sg, num_pages, vb,
+ GFP_NOWAIT);
+ /* We should not report if the guest is low on memory */
+ if (unlikely(err))
+ return;
+ virtqueue_kick(vq);
+
+ /* When host has read buffer, this completes via balloon_ack */
+ wait_event(vb->acked, virtqueue_get_buf(vq, ));
+}
+
+static void virtballoon_page_reporting_setup(struct virtio_balloon *vb)
+{
+ struct device *dev = >vdev->dev;
+ int err;
+
+ vb->page_reporting_conf.report = virtballoon_report_pages;
+ vb->page_reporting_conf.max_pages = PAGE_REPORTING_MAX_PAGES;
+ err = page_reporting_enable(>page_reporting_conf);
+ if (err < 0) {
+ dev_err(dev, "Failed to enable reporting, err = %d\n", err);
+ page_reporting_flag = false;
+ vb->page_reporting_conf.report = NULL;
+ vb->page_reporting_conf.max_pages = 0;
+ return;
+ }
+}
+
static void set_page_pfns(struct virtio_balloon *vb,
__virtio32 pfns[], struct page *page)
{
@@ -476,6 +524,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;
+
[virtio-dev] [QEMU Patch 2/2] virtio-balloon: support for handling page reporting
Page reporting is a feature which enables the virtual machine to report
chunk of free pages to the hypervisor.
This patch enables QEMU to process these reports from the VM and discard the
unused memory range.
Signed-off-by: Nitesh Narayan Lal
---
hw/virtio/virtio-balloon.c | 41 ++
include/hw/virtio/virtio-balloon.h | 2 +-
2 files changed, 42 insertions(+), 1 deletion(-)
diff --git a/hw/virtio/virtio-balloon.c b/hw/virtio/virtio-balloon.c
index 25de154307..1132e47ee0 100644
--- a/hw/virtio/virtio-balloon.c
+++ b/hw/virtio/virtio-balloon.c
@@ -320,6 +320,39 @@ static void balloon_stats_set_poll_interval(Object *obj,
Visitor *v,
balloon_stats_change_timer(s, 0);
}
+static void virtio_balloon_handle_reporting(VirtIODevice *vdev, VirtQueue *vq)
+{
+VirtQueueElement *elem;
+
+while ((elem = virtqueue_pop(vq, sizeof(VirtQueueElement {
+unsigned int i;
+
+for (i = 0; i < elem->in_num; i++) {
+void *gaddr = elem->in_sg[i].iov_base;
+size_t size = elem->in_sg[i].iov_len;
+ram_addr_t ram_offset;
+size_t rb_page_size;
+ RAMBlock *rb;
+
+if (qemu_balloon_is_inhibited())
+continue;
+
+rb = qemu_ram_block_from_host(gaddr, false, _offset);
+rb_page_size = qemu_ram_pagesize(rb);
+
+/* For now we will simply ignore unaligned memory regions */
+if ((ram_offset | size) & (rb_page_size - 1))
+continue;
+
+ram_block_discard_range(rb, ram_offset, size);
+}
+
+virtqueue_push(vq, elem, 0);
+virtio_notify(vdev, vq);
+g_free(elem);
+}
+}
+
static void virtio_balloon_handle_output(VirtIODevice *vdev, VirtQueue *vq)
{
VirtIOBalloon *s = VIRTIO_BALLOON(vdev);
@@ -792,6 +825,12 @@ static void virtio_balloon_device_realize(DeviceState
*dev, Error **errp)
s->dvq = virtio_add_queue(vdev, 128, virtio_balloon_handle_output);
s->svq = virtio_add_queue(vdev, 128, virtio_balloon_receive_stats);
+if (virtio_has_feature(s->host_features,
+ VIRTIO_BALLOON_F_REPORTING)) {
+s->reporting_vq = virtio_add_queue(vdev, 16,
+ virtio_balloon_handle_reporting);
+}
+
if (virtio_has_feature(s->host_features,
VIRTIO_BALLOON_F_FREE_PAGE_HINT)) {
s->free_page_vq = virtio_add_queue(vdev, VIRTQUEUE_MAX_SIZE,
@@ -912,6 +951,8 @@ static Property virtio_balloon_properties[] = {
* is disabled, resulting in QEMU 3.1 migration incompatibility. This
* property retains this quirk for QEMU 4.1 machine types.
*/
+DEFINE_PROP_BIT("free-page-reporting", VirtIOBalloon, host_features,
+VIRTIO_BALLOON_F_REPORTING, true),
DEFINE_PROP_BOOL("qemu-4-0-config-size", VirtIOBalloon,
qemu_4_0_config_size, false),
DEFINE_PROP_LINK("iothread", VirtIOBalloon, iothread, TYPE_IOTHREAD,
diff --git a/include/hw/virtio/virtio-balloon.h
b/include/hw/virtio/virtio-balloon.h
index d1c968d237..15a05e6435 100644
--- a/include/hw/virtio/virtio-balloon.h
+++ b/include/hw/virtio/virtio-balloon.h
@@ -42,7 +42,7 @@ enum virtio_balloon_free_page_report_status {
typedef struct VirtIOBalloon {
VirtIODevice parent_obj;
-VirtQueue *ivq, *dvq, *svq, *free_page_vq;
+VirtQueue *ivq, *dvq, *svq, *free_page_vq, *reporting_vq;
uint32_t free_page_report_status;
uint32_t num_pages;
uint32_t actual;
--
2.21.0
-
To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
[virtio-dev] [QEMU Patch 1/2] virtio-balloon: adding bit for page reporting support
This patch will be replaced once the feature is merged into the Linux kernel. Signed-off-by: Nitesh Narayan Lal --- include/standard-headers/linux/virtio_balloon.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/standard-headers/linux/virtio_balloon.h b/include/standard-headers/linux/virtio_balloon.h index 9375ca2a70..1c5f6d6f2d 100644 --- a/include/standard-headers/linux/virtio_balloon.h +++ b/include/standard-headers/linux/virtio_balloon.h @@ -36,6 +36,7 @@ #define VIRTIO_BALLOON_F_DEFLATE_ON_OOM2 /* Deflate balloon on OOM */ #define VIRTIO_BALLOON_F_FREE_PAGE_HINT3 /* 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 -- 2.21.0 - To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
[virtio-dev] Re: [QEMU Patch 2/2] virtio-balloon: support for handling page reporting
On Mon, Aug 12, 2019 at 6:14 AM Nitesh Narayan Lal wrote:
>
> Page reporting is a feature which enables the virtual machine to report
> chunk of free pages to the hypervisor.
> This patch enables QEMU to process these reports from the VM and discard the
> unused memory range.
>
> Signed-off-by: Nitesh Narayan Lal
> ---
> hw/virtio/virtio-balloon.c | 41 ++
> include/hw/virtio/virtio-balloon.h | 2 +-
> 2 files changed, 42 insertions(+), 1 deletion(-)
>
> diff --git a/hw/virtio/virtio-balloon.c b/hw/virtio/virtio-balloon.c
> index 25de154307..1132e47ee0 100644
> --- a/hw/virtio/virtio-balloon.c
> +++ b/hw/virtio/virtio-balloon.c
> @@ -320,6 +320,39 @@ static void balloon_stats_set_poll_interval(Object *obj,
> Visitor *v,
> balloon_stats_change_timer(s, 0);
> }
>
> +static void virtio_balloon_handle_reporting(VirtIODevice *vdev, VirtQueue
> *vq)
> +{
> +VirtQueueElement *elem;
> +
> +while ((elem = virtqueue_pop(vq, sizeof(VirtQueueElement {
> +unsigned int i;
> +
> +for (i = 0; i < elem->in_num; i++) {
> +void *gaddr = elem->in_sg[i].iov_base;
> +size_t size = elem->in_sg[i].iov_len;
> +ram_addr_t ram_offset;
> +size_t rb_page_size;
> + RAMBlock *rb;
> +
> +if (qemu_balloon_is_inhibited())
> +continue;
> +
> +rb = qemu_ram_block_from_host(gaddr, false, _offset);
> +rb_page_size = qemu_ram_pagesize(rb);
> +
> +/* For now we will simply ignore unaligned memory regions */
> +if ((ram_offset | size) & (rb_page_size - 1))
> +continue;
> +
> +ram_block_discard_range(rb, ram_offset, size);
> +}
> +
> +virtqueue_push(vq, elem, 0);
> +virtio_notify(vdev, vq);
> +g_free(elem);
> +}
> +}
> +
No offense, but I am a bit annoyed. If you are going to copy my code
you should at least keep up with the fixes. You are missing all of the
stuff to handle the poison value. If you are going to just duplicate
my setup you might as well have just pulled the QEMU patches from the
last submission I did. Then this would have at least has the fix for
the page poisoning. Also it wouldn't hurt to mention that you are
basing it off of the patch set I submitted since it hasn't been
accepted yet.
> static void virtio_balloon_handle_output(VirtIODevice *vdev, VirtQueue *vq)
> {
> VirtIOBalloon *s = VIRTIO_BALLOON(vdev);
> @@ -792,6 +825,12 @@ static void virtio_balloon_device_realize(DeviceState
> *dev, Error **errp)
> s->dvq = virtio_add_queue(vdev, 128, virtio_balloon_handle_output);
> s->svq = virtio_add_queue(vdev, 128, virtio_balloon_receive_stats);
>
> +if (virtio_has_feature(s->host_features,
> + VIRTIO_BALLOON_F_REPORTING)) {
> +s->reporting_vq = virtio_add_queue(vdev, 16,
> + virtio_balloon_handle_reporting);
> +}
> +
> if (virtio_has_feature(s->host_features,
> VIRTIO_BALLOON_F_FREE_PAGE_HINT)) {
> s->free_page_vq = virtio_add_queue(vdev, VIRTQUEUE_MAX_SIZE,
> @@ -912,6 +951,8 @@ static Property virtio_balloon_properties[] = {
> * is disabled, resulting in QEMU 3.1 migration incompatibility. This
> * property retains this quirk for QEMU 4.1 machine types.
> */
> +DEFINE_PROP_BIT("free-page-reporting", VirtIOBalloon, host_features,
> +VIRTIO_BALLOON_F_REPORTING, true),
> DEFINE_PROP_BOOL("qemu-4-0-config-size", VirtIOBalloon,
> qemu_4_0_config_size, false),
> DEFINE_PROP_LINK("iothread", VirtIOBalloon, iothread, TYPE_IOTHREAD,
> diff --git a/include/hw/virtio/virtio-balloon.h
> b/include/hw/virtio/virtio-balloon.h
> index d1c968d237..15a05e6435 100644
> --- a/include/hw/virtio/virtio-balloon.h
> +++ b/include/hw/virtio/virtio-balloon.h
> @@ -42,7 +42,7 @@ enum virtio_balloon_free_page_report_status {
>
> typedef struct VirtIOBalloon {
> VirtIODevice parent_obj;
> -VirtQueue *ivq, *dvq, *svq, *free_page_vq;
> +VirtQueue *ivq, *dvq, *svq, *free_page_vq, *reporting_vq;
> uint32_t free_page_report_status;
> uint32_t num_pages;
> uint32_t actual;
> --
> 2.21.0
>q
-
To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
[virtio-dev] Re: [QEMU Patch 2/2] virtio-balloon: support for handling page reporting
On 8/12/19 11:18 AM, Alexander Duyck wrote:
> On Mon, Aug 12, 2019 at 6:14 AM Nitesh Narayan Lal wrote:
>> Page reporting is a feature which enables the virtual machine to report
>> chunk of free pages to the hypervisor.
>> This patch enables QEMU to process these reports from the VM and discard the
>> unused memory range.
>>
>> Signed-off-by: Nitesh Narayan Lal
>> ---
>> hw/virtio/virtio-balloon.c | 41 ++
>> include/hw/virtio/virtio-balloon.h | 2 +-
>> 2 files changed, 42 insertions(+), 1 deletion(-)
>>
>> diff --git a/hw/virtio/virtio-balloon.c b/hw/virtio/virtio-balloon.c
>> index 25de154307..1132e47ee0 100644
>> --- a/hw/virtio/virtio-balloon.c
>> +++ b/hw/virtio/virtio-balloon.c
>> @@ -320,6 +320,39 @@ static void balloon_stats_set_poll_interval(Object
>> *obj, Visitor *v,
>> balloon_stats_change_timer(s, 0);
>> }
>>
>> +static void virtio_balloon_handle_reporting(VirtIODevice *vdev, VirtQueue
>> *vq)
>> +{
>> +VirtQueueElement *elem;
>> +
>> +while ((elem = virtqueue_pop(vq, sizeof(VirtQueueElement {
>> +unsigned int i;
>> +
>> +for (i = 0; i < elem->in_num; i++) {
>> +void *gaddr = elem->in_sg[i].iov_base;
>> +size_t size = elem->in_sg[i].iov_len;
>> +ram_addr_t ram_offset;
>> +size_t rb_page_size;
>> + RAMBlock *rb;
>> +
>> +if (qemu_balloon_is_inhibited())
>> +continue;
>> +
>> +rb = qemu_ram_block_from_host(gaddr, false, _offset);
>> +rb_page_size = qemu_ram_pagesize(rb);
>> +
>> +/* For now we will simply ignore unaligned memory regions */
>> +if ((ram_offset | size) & (rb_page_size - 1))
>> +continue;
>> +
>> +ram_block_discard_range(rb, ram_offset, size);
>> +}
>> +
>> +virtqueue_push(vq, elem, 0);
>> +virtio_notify(vdev, vq);
>> +g_free(elem);
>> +}
>> +}
>> +
> No offense, but I am a bit annoyed.
None taken at all.
> If you are going to copy my code
> you should at least keep up with the fixes.
Yeah I did refer to your code and just because the quality of your code is
better than what I posted earlier and there is quite a lot for me to learn from
it.
> stuff to handle the poison value. If you are going to just duplicate
> my setup you might as well have just pulled the QEMU patches from the
> last submission I did. Then this would have at least has the fix for
> the page poisoning.
>
The only reason I didn't include the poison change as I still need to understand
them.
I have this mentioned in my cover-email.
> Also it wouldn't hurt to mention that you are
> basing it off of the patch set I submitted since it hasn't been
> accepted yet.
My bad!! This I will surely do from next time.
>
>> static void virtio_balloon_handle_output(VirtIODevice *vdev, VirtQueue *vq)
>> {
>> VirtIOBalloon *s = VIRTIO_BALLOON(vdev);
>> @@ -792,6 +825,12 @@ static void virtio_balloon_device_realize(DeviceState
>> *dev, Error **errp)
>> s->dvq = virtio_add_queue(vdev, 128, virtio_balloon_handle_output);
>> s->svq = virtio_add_queue(vdev, 128, virtio_balloon_receive_stats);
>>
>> +if (virtio_has_feature(s->host_features,
>> + VIRTIO_BALLOON_F_REPORTING)) {
>> +s->reporting_vq = virtio_add_queue(vdev, 16,
>> + virtio_balloon_handle_reporting);
>> +}
>> +
>> if (virtio_has_feature(s->host_features,
>> VIRTIO_BALLOON_F_FREE_PAGE_HINT)) {
>> s->free_page_vq = virtio_add_queue(vdev, VIRTQUEUE_MAX_SIZE,
>> @@ -912,6 +951,8 @@ static Property virtio_balloon_properties[] = {
>> * is disabled, resulting in QEMU 3.1 migration incompatibility. This
>> * property retains this quirk for QEMU 4.1 machine types.
>> */
>> +DEFINE_PROP_BIT("free-page-reporting", VirtIOBalloon, host_features,
>> +VIRTIO_BALLOON_F_REPORTING, true),
>> DEFINE_PROP_BOOL("qemu-4-0-config-size", VirtIOBalloon,
>> qemu_4_0_config_size, false),
>> DEFINE_PROP_LINK("iothread", VirtIOBalloon, iothread, TYPE_IOTHREAD,
>> diff --git a/include/hw/virtio/virtio-balloon.h
>> b/include/hw/virtio/virtio-balloon.h
>> index d1c968d237..15a05e6435 100644
>> --- a/include/hw/virtio/virtio-balloon.h
>> +++ b/include/hw/virtio/virtio-balloon.h
>> @@ -42,7 +42,7 @@ enum virtio_balloon_free_page_report_status {
>>
>> typedef struct VirtIOBalloon {
>> VirtIODevice parent_obj;
>> -VirtQueue *ivq, *dvq, *svq, *free_page_vq;
>> +VirtQueue *ivq, *dvq, *svq, *free_page_vq, *reporting_vq;
>> uint32_t free_page_report_status;
>> uint32_t num_pages;
>> uint32_t actual;
>> --
>> 2.21.0
>> q
--
Thanks
Nitesh
-
To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org
For
[virtio-dev] Re: [RFC][Patch v12 1/2] mm: page_reporting: core infrastructure
On Mon, Aug 12, 2019 at 6:13 AM Nitesh Narayan Lal wrote:
>
> This patch introduces the core infrastructure for free page reporting in
> virtual environments. It enables the kernel to track the free pages which
> can be reported to its hypervisor so that the hypervisor could
> free and reuse that memory as per its requirement.
>
> While the pages are getting processed in the hypervisor (e.g.,
> via MADV_DONTNEED), the guest must not use them, otherwise, data loss
> would be possible. To avoid such a situation, these pages are
> temporarily removed from the buddy. The amount of pages removed
> temporarily from the buddy is governed by the backend(virtio-balloon
> in our case).
>
> To efficiently identify free pages that can to be reported to the
> hypervisor, bitmaps in a coarse granularity are used. Only fairly big
> chunks are reported to the hypervisor - especially, to not break up THP
> in the hypervisor - "MAX_ORDER - 2" on x86, and to save space. The bits
> in the bitmap are an indication whether a page *might* be free, not a
> guarantee. A new hook after buddy merging sets the bits.
>
> Bitmaps are stored per zone, protected by the zone lock. A workqueue
> asynchronously processes the bitmaps, trying to isolate and report pages
> that are still free. The backend (virtio-balloon) is responsible for
> reporting these batched pages to the host synchronously. Once reporting/
> freeing is complete, isolated pages are returned back to the buddy.
>
> Signed-off-by: Nitesh Narayan Lal
So if I understand correctly the hotplug support for this is still not
included correct? I assume that is the case since I don't see any
logic for zone resizing.
Also I don't see how this dealt with the sparse issue that was pointed
out earlier. Specifically how would you deal with a zone that has a
wide range between the base and the end and a huge gap somewhere
in-between?
> ---
> include/linux/mmzone.h | 11 ++
> include/linux/page_reporting.h | 63 +++
> mm/Kconfig | 6 +
> mm/Makefile| 1 +
> mm/page_alloc.c| 42 -
> mm/page_reporting.c| 332 +
> 6 files changed, 448 insertions(+), 7 deletions(-)
> create mode 100644 include/linux/page_reporting.h
> create mode 100644 mm/page_reporting.c
>
> diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
> index d77d717c620c..ba5f5b508f25 100644
> --- a/include/linux/mmzone.h
> +++ b/include/linux/mmzone.h
> @@ -559,6 +559,17 @@ struct zone {
> /* Zone statistics */
> atomic_long_t vm_stat[NR_VM_ZONE_STAT_ITEMS];
> atomic_long_t vm_numa_stat[NR_VM_NUMA_STAT_ITEMS];
> +#ifdef CONFIG_PAGE_REPORTING
> + /* Pointer to the bitmap in PAGE_REPORTING_MIN_ORDER granularity */
> + unsigned long *bitmap;
> + /* Preserve start and end PFN in case they change due to hotplug */
> + unsigned long base_pfn;
> + unsigned long end_pfn;
> + /* Free pages of granularity PAGE_REPORTING_MIN_ORDER */
> + atomic_t free_pages;
> + /* Number of bits required in the bitmap */
> + unsigned long nbits;
> +#endif
> } cacheline_internodealigned_in_smp;
Okay, so the original thing this patch set had going for it was that
it was non-invasive. However, now you are adding a bunch of stuff to
the zone. That kind of loses the non-invasive argument for this patch
set compared to mine.
If we are going to continue further with this patch set then it might
be worth looking into dynamically allocating the space you need for
this block. At a minimum you could probably look at making the bitmap
an RCU based setup so you could define the base and end along with the
bitmap. It would probably help to resolve the hotplug issues you still
need to address.
> enum pgdat_flags {
> diff --git a/include/linux/page_reporting.h b/include/linux/page_reporting.h
> new file mode 100644
> index ..37a39589939d
> --- /dev/null
> +++ b/include/linux/page_reporting.h
> @@ -0,0 +1,63 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef _LINUX_PAGE_REPORTING_H
> +#define _LINUX_PAGE_REPORTING_H
> +
> +#define PAGE_REPORTING_MIN_ORDER (MAX_ORDER - 2)
> +#define PAGE_REPORTING_MAX_PAGES 16
> +
> +#ifdef CONFIG_PAGE_REPORTING
> +struct page_reporting_config {
> + /* function to hint batch of isolated pages */
> + void (*report)(struct page_reporting_config *phconf,
> + unsigned int num_pages);
> +
> + /* scatterlist to hold the isolated pages to be hinted */
> + struct scatterlist *sg;
> +
> + /*
> +* Maxmimum pages that are going to be hinted to the hypervisor at a
> +* time of granularity >= PAGE_REPORTING_MIN_ORDER.
> +*/
> + int max_pages;
> +
> + /* work object to process page reporting rqeuests */
> + struct work_struct reporting_work;
> +
> + /* tracks the number
[virtio-dev] [PATCH v5 6/6] virtio-balloon: Add support for providing unused page reports to host
From: Alexander Duyck
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
---
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 2c19457ab573..52f9eeda1877 100644
--- a/drivers/virtio/virtio_balloon.c
+++ b/drivers/virtio/virtio_balloon.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
/*
* 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, ));
+}
+
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)) {
@@ -931,12 +975,30 @@ static int virtballoon_probe(struct
[virtio-dev] [PATCH v5 QEMU 1/3] virtio-ballon: Implement support for page poison tracking feature
From: Alexander Duyck
We need to make certain to advertise support for page poison tracking if
we want to actually get data on if the guest will be poisoning pages. So
if free page hinting is active we should add page poisoning support and
let the guest disable it if it isn't using it.
Page poisoning will result in a page being dirtied on free. As such we
cannot really avoid having to copy the page at least one more time since
we will need to write the poison value to the destination. As such we can
just ignore free page hinting if page poisoning is enabled as it will
actually reduce the work we have to do.
Signed-off-by: Alexander Duyck
---
hw/virtio/virtio-balloon.c | 25 +
include/hw/virtio/virtio-balloon.h |1 +
2 files changed, 22 insertions(+), 4 deletions(-)
diff --git a/hw/virtio/virtio-balloon.c b/hw/virtio/virtio-balloon.c
index 25de15430710..003b3ebcfdfb 100644
--- a/hw/virtio/virtio-balloon.c
+++ b/hw/virtio/virtio-balloon.c
@@ -530,6 +530,15 @@ static void virtio_balloon_free_page_start(VirtIOBalloon
*s)
return;
}
+/*
+ * If page poisoning is enabled then we probably shouldn't bother with
+ * the hinting since the poisoning will dirty the page and invalidate
+ * the work we are doing anyway.
+ */
+if (virtio_vdev_has_feature(vdev, VIRTIO_BALLOON_F_PAGE_POISON)) {
+return;
+}
+
if (s->free_page_report_cmd_id == UINT_MAX) {
s->free_page_report_cmd_id =
VIRTIO_BALLOON_FREE_PAGE_REPORT_CMD_ID_MIN;
@@ -617,12 +626,10 @@ static size_t virtio_balloon_config_size(VirtIOBalloon *s)
if (s->qemu_4_0_config_size) {
return sizeof(struct virtio_balloon_config);
}
-if (virtio_has_feature(features, VIRTIO_BALLOON_F_PAGE_POISON)) {
+if (virtio_has_feature(features, VIRTIO_BALLOON_F_PAGE_POISON) ||
+virtio_has_feature(features, VIRTIO_BALLOON_F_FREE_PAGE_HINT)) {
return sizeof(struct virtio_balloon_config);
}
-if (virtio_has_feature(features, VIRTIO_BALLOON_F_FREE_PAGE_HINT)) {
-return offsetof(struct virtio_balloon_config, poison_val);
-}
return offsetof(struct virtio_balloon_config, free_page_report_cmd_id);
}
@@ -633,6 +640,7 @@ static void virtio_balloon_get_config(VirtIODevice *vdev,
uint8_t *config_data)
config.num_pages = cpu_to_le32(dev->num_pages);
config.actual = cpu_to_le32(dev->actual);
+config.poison_val = cpu_to_le32(dev->poison_val);
if (dev->free_page_report_status == FREE_PAGE_REPORT_S_REQUESTED) {
config.free_page_report_cmd_id =
@@ -696,6 +704,8 @@ static void virtio_balloon_set_config(VirtIODevice *vdev,
qapi_event_send_balloon_change(vm_ram_size -
((ram_addr_t) dev->actual <<
VIRTIO_BALLOON_PFN_SHIFT));
}
+dev->poison_val = virtio_vdev_has_feature(vdev,
VIRTIO_BALLOON_F_PAGE_POISON) ?
+ le32_to_cpu(config.poison_val) : 0;
trace_virtio_balloon_set_config(dev->actual, oldactual);
}
@@ -705,6 +715,9 @@ static uint64_t virtio_balloon_get_features(VirtIODevice
*vdev, uint64_t f,
VirtIOBalloon *dev = VIRTIO_BALLOON(vdev);
f |= dev->host_features;
virtio_add_feature(, VIRTIO_BALLOON_F_STATS_VQ);
+if (virtio_has_feature(f, VIRTIO_BALLOON_F_FREE_PAGE_HINT)) {
+virtio_add_feature(, VIRTIO_BALLOON_F_PAGE_POISON);
+}
return f;
}
@@ -846,6 +859,8 @@ static void virtio_balloon_device_reset(VirtIODevice *vdev)
g_free(s->stats_vq_elem);
s->stats_vq_elem = NULL;
}
+
+s->poison_val = 0;
}
static void virtio_balloon_set_status(VirtIODevice *vdev, uint8_t status)
@@ -908,6 +923,8 @@ static Property virtio_balloon_properties[] = {
VIRTIO_BALLOON_F_DEFLATE_ON_OOM, false),
DEFINE_PROP_BIT("free-page-hint", VirtIOBalloon, host_features,
VIRTIO_BALLOON_F_FREE_PAGE_HINT, false),
+DEFINE_PROP_BIT("x-page-poison", VirtIOBalloon, host_features,
+VIRTIO_BALLOON_F_PAGE_POISON, false),
/* QEMU 4.0 accidentally changed the config size even when free-page-hint
* is disabled, resulting in QEMU 3.1 migration incompatibility. This
* property retains this quirk for QEMU 4.1 machine types.
diff --git a/include/hw/virtio/virtio-balloon.h
b/include/hw/virtio/virtio-balloon.h
index d1c968d2376e..7fe78e5c14d7 100644
--- a/include/hw/virtio/virtio-balloon.h
+++ b/include/hw/virtio/virtio-balloon.h
@@ -70,6 +70,7 @@ typedef struct VirtIOBalloon {
uint32_t host_features;
bool qemu_4_0_config_size;
+uint32_t poison_val;
} VirtIOBalloon;
#endif
-
To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
[virtio-dev] [PATCH v5 5/6] virtio-balloon: Pull page poisoning config out of free page hinting
From: Alexander Duyck
Currently the page poisoning setting wasn't being enabled unless free page
hinting was enabled. However we will need the page poisoning tracking logic
as well for unused page reporting. As such pull it out and make it a
separate bit of config in the probe function.
In addition we can actually wrap the code in a check for NO_SANITY. If we
don't care what is actually in the page we can just default to 0 and leave
it there.
Signed-off-by: Alexander Duyck
---
drivers/virtio/virtio_balloon.c | 19 +--
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
index 226fbb995fb0..2c19457ab573 100644
--- a/drivers/virtio/virtio_balloon.c
+++ b/drivers/virtio/virtio_balloon.c
@@ -842,7 +842,6 @@ static int virtio_balloon_register_shrinker(struct
virtio_balloon *vb)
static int virtballoon_probe(struct virtio_device *vdev)
{
struct virtio_balloon *vb;
- __u32 poison_val;
int err;
if (!vdev->config->get) {
@@ -909,11 +908,19 @@ static int virtballoon_probe(struct virtio_device *vdev)
VIRTIO_BALLOON_CMD_ID_STOP);
spin_lock_init(>free_page_list_lock);
INIT_LIST_HEAD(>free_page_list);
- if (virtio_has_feature(vdev, VIRTIO_BALLOON_F_PAGE_POISON)) {
- memset(_val, PAGE_POISON, sizeof(poison_val));
- virtio_cwrite(vb->vdev, struct virtio_balloon_config,
- poison_val, _val);
- }
+ }
+ if (virtio_has_feature(vdev, VIRTIO_BALLOON_F_PAGE_POISON)) {
+ __u32 poison_val = 0;
+
+#if !defined(CONFIG_PAGE_POISONING_NO_SANITY)
+ /*
+* Let hypervisor know that we are expecting a specific
+* value to be written back in unused pages.
+*/
+ memset(_val, PAGE_POISON, sizeof(poison_val));
+#endif
+ virtio_cwrite(vb->vdev, struct virtio_balloon_config,
+ poison_val, _val);
}
/*
* We continue to use VIRTIO_BALLOON_F_DEFLATE_ON_OOM to decide if a
-
To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
[virtio-dev] [PATCH v5 QEMU 2/3] virtio-balloon: Add bit to notify guest of unused page reporting
From: Alexander Duyck Add a bit for the page reporting feature provided by virtio-balloon. This patch should be replaced once the feature is added to the Linux kernel and the bit is backported into this exported kernel header. Signed-off-by: Alexander Duyck --- include/standard-headers/linux/virtio_balloon.h |1 + 1 file changed, 1 insertion(+) diff --git a/include/standard-headers/linux/virtio_balloon.h b/include/standard-headers/linux/virtio_balloon.h index 9375ca2a70de..1c5f6d6f2de6 100644 --- a/include/standard-headers/linux/virtio_balloon.h +++ b/include/standard-headers/linux/virtio_balloon.h @@ -36,6 +36,7 @@ #define VIRTIO_BALLOON_F_DEFLATE_ON_OOM2 /* Deflate balloon on OOM */ #define VIRTIO_BALLOON_F_FREE_PAGE_HINT3 /* 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 - To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
[virtio-dev] [PATCH v5 0/6] 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. Changes from the RFC: https://lore.kernel.org/lkml/20190530215223.13974.22445.stgit@localhost.localdomain/ Moved aeration requested flag out of aerator and into zone->flags. Moved boundary out of free_area and into local variables for aeration. Moved aeration cycle out of interrupt and into workqueue. Left nr_free as total pages instead of splitting it between raw and aerated. Combined size and physical address values in virtio ring into one 64b value. Changes from v1: https://lore.kernel.org/lkml/20190619222922.1231.27432.stgit@localhost.localdomain/ Dropped "waste page treatment" in favor of "page hinting" Renamed files and functions from "aeration" to "page_hinting" Moved from page->lru list to scatterlist Replaced wait on refcnt in shutdown with RCU and cancel_delayed_work_sync Virtio now uses scatterlist directly instead of intermediate array Moved stats out of free_area, now in separate area and pointed to from zone Merged patch 5 into patch 4 to improve review-ability Updated various code comments throughout Changes from v2: https://lore.kernel.org/lkml/20190724165158.6685.87228.stgit@localhost.localdomain/ Dropped "page hinting" in favor of "page reporting" Renamed files from "hinting" to "reporting" Replaced "Hinted" page type with "Reported" page flag Added support for page poisoning while hinting is active Add QEMU patch that implements PAGE_POISON feature Changes from v3: https://lore.kernel.org/lkml/20190801222158.22190.96964.stgit@localhost.localdomain/ Added mutex lock around page reporting startup and shutdown Fixed reference to "page aeration" in patch 2 Split page reporting function bit out into separate QEMU patch Limited capacity of scatterlist to vq size - 1 instead of vq size Added exception handling for case of virtio descriptor allocation failure Changes from v4: https://lore.kernel.org/lkml/20190807224037.6891.53512.stgit@localhost.localdomain/ Replaced spin_(un)lock with spin_(un)lock_irq in page_reporting_cycle() Dropped if/continue for ternary operator in page_reporting_process() Added checks for
[virtio-dev] Re: [PATCH v5 1/6] mm: Adjust shuffle code to allow for future coalescing
On Mon, Aug 12, 2019 at 3:24 PM Dan Williams wrote:
>
> On Mon, Aug 12, 2019 at 2:33 PM Alexander Duyck
> wrote:
> >
> > From: Alexander Duyck
> >
> > This patch is meant to move the head/tail adding logic out of the shuffle
>
> s/This patch is meant to move/Move/
I'll update that on next submission.
> > code and into the __free_one_page function since ultimately that is where
> > it is really needed anyway. By doing this we should be able to reduce the
> > overhead
>
> Is the overhead benefit observable? I would expect the overhead of
> get_random_u64() dominates.
>
> > and can consolidate all of the list addition bits in one spot.
>
> This sounds the better argument.
Actually the overhead is the bit where we have to setup the arguments
and call the function. There is only one spot where this function is
ever called and that is in __free_one_page.
> [..]
> > diff --git a/mm/shuffle.h b/mm/shuffle.h
> > index 777a257a0d2f..add763cc0995 100644
> > --- a/mm/shuffle.h
> > +++ b/mm/shuffle.h
> > @@ -3,6 +3,7 @@
> > #ifndef _MM_SHUFFLE_H
> > #define _MM_SHUFFLE_H
> > #include
> > +#include
> >
> > /*
> > * SHUFFLE_ENABLE is called from the command line enabling path, or by
> > @@ -43,6 +44,32 @@ static inline bool is_shuffle_order(int order)
> > return false;
> > return order >= SHUFFLE_ORDER;
> > }
> > +
> > +static inline bool shuffle_add_to_tail(void)
> > +{
> > + static u64 rand;
> > + static u8 rand_bits;
> > + u64 rand_old;
> > +
> > + /*
> > +* The lack of locking is deliberate. If 2 threads race to
> > +* update the rand state it just adds to the entropy.
> > +*/
> > + if (rand_bits-- == 0) {
> > + rand_bits = 64;
> > + rand = get_random_u64();
> > + }
> > +
> > + /*
> > +* Test highest order bit while shifting our random value. This
> > +* should result in us testing for the carry flag following the
> > +* shift.
> > +*/
> > + rand_old = rand;
> > + rand <<= 1;
> > +
> > + return rand < rand_old;
> > +}
>
> This function seems too involved to be a static inline and I believe
> each compilation unit that might call this routine gets it's own copy
> of 'rand' and 'rand_bits' when the original expectation is that they
> are global. How about leave this bit to mm/shuffle.c and rename it
> coin_flip(), or something more generic, since it does not
> 'add_to_tail'? The 'add_to_tail' action is something the caller
> decides.
The thing is there is only one caller to this function, and that is
__free_one_page. That is why I made it a static inline since that way
we can avoid having to call this as a function at all and can just
inline the code into __free_one_page.
As far as making this more generic I guess I can look into that. Maybe
I will look at trying to implement something like get_random_bool()
and then just do a macro to point to that. One other things that
occurs to me now that I am looking over the code is that I am not sure
the original or this modified version actually provide all that much
randomness if multiple threads have access to it at the same time. If
rand_bits races past the 0 you can end up getting streaks of 0s for
256+ bits.
-
To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
[virtio-dev] Re: [RFC][Patch v12 1/2] mm: page_reporting: core infrastructure
On 8/12/19 2:47 PM, Alexander Duyck wrote:
> On Mon, Aug 12, 2019 at 6:13 AM Nitesh Narayan Lal wrote:
>> This patch introduces the core infrastructure for free page reporting in
>> virtual environments. It enables the kernel to track the free pages which
>> can be reported to its hypervisor so that the hypervisor could
>> free and reuse that memory as per its requirement.
>>
>> While the pages are getting processed in the hypervisor (e.g.,
>> via MADV_DONTNEED), the guest must not use them, otherwise, data loss
>> would be possible. To avoid such a situation, these pages are
>> temporarily removed from the buddy. The amount of pages removed
>> temporarily from the buddy is governed by the backend(virtio-balloon
>> in our case).
>>
>> To efficiently identify free pages that can to be reported to the
>> hypervisor, bitmaps in a coarse granularity are used. Only fairly big
>> chunks are reported to the hypervisor - especially, to not break up THP
>> in the hypervisor - "MAX_ORDER - 2" on x86, and to save space. The bits
>> in the bitmap are an indication whether a page *might* be free, not a
>> guarantee. A new hook after buddy merging sets the bits.
>>
>> Bitmaps are stored per zone, protected by the zone lock. A workqueue
>> asynchronously processes the bitmaps, trying to isolate and report pages
>> that are still free. The backend (virtio-balloon) is responsible for
>> reporting these batched pages to the host synchronously. Once reporting/
>> freeing is complete, isolated pages are returned back to the buddy.
>>
>> Signed-off-by: Nitesh Narayan Lal
> So if I understand correctly the hotplug support for this is still not
> included correct?
That is correct, I have it as an ongoing-item in my cover-email.
In case, we decide to go with this approach do you think it is a blocker?
> I assume that is the case since I don't see any
> logic for zone resizing.
>
> Also I don't see how this dealt with the sparse issue that was pointed
> out earlier. Specifically how would you deal with a zone that has a
> wide range between the base and the end and a huge gap somewhere
> in-between?
It doesn't. However, considering we are tracking page on order of (MAX_ORDER -
2) I don't think the loss will be significant.
In any case, this is certainly a drawback of this approach and I should add this
in my cover.
The one thing which I did change in this version is that now I started
maintaining bitmap for each zone.
>
>> ---
>> include/linux/mmzone.h | 11 ++
>> include/linux/page_reporting.h | 63 +++
>> mm/Kconfig | 6 +
>> mm/Makefile| 1 +
>> mm/page_alloc.c| 42 -
>> mm/page_reporting.c| 332 +
>> 6 files changed, 448 insertions(+), 7 deletions(-)
>> create mode 100644 include/linux/page_reporting.h
>> create mode 100644 mm/page_reporting.c
>>
>> diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
>> index d77d717c620c..ba5f5b508f25 100644
>> --- a/include/linux/mmzone.h
>> +++ b/include/linux/mmzone.h
>> @@ -559,6 +559,17 @@ struct zone {
>> /* Zone statistics */
>> atomic_long_t vm_stat[NR_VM_ZONE_STAT_ITEMS];
>> atomic_long_t vm_numa_stat[NR_VM_NUMA_STAT_ITEMS];
>> +#ifdef CONFIG_PAGE_REPORTING
>> + /* Pointer to the bitmap in PAGE_REPORTING_MIN_ORDER granularity */
>> + unsigned long *bitmap;
>> + /* Preserve start and end PFN in case they change due to hotplug */
>> + unsigned long base_pfn;
>> + unsigned long end_pfn;
>> + /* Free pages of granularity PAGE_REPORTING_MIN_ORDER */
>> + atomic_t free_pages;
>> + /* Number of bits required in the bitmap */
>> + unsigned long nbits;
>> +#endif
>> } cacheline_internodealigned_in_smp;
> Okay, so the original thing this patch set had going for it was that
> it was non-invasive. However, now you are adding a bunch of stuff to
> the zone. That kind of loses the non-invasive argument for this patch
> set compared to mine.
I think it is fair to add that it not as invasive as yours. :) (But that has its
own pros and cons)
In any case, I do understand your point.
>
>
> If we are going to continue further with this patch set then it might
> be worth looking into dynamically allocating the space you need for
> this block.
Not sure if I understood this part. Dynamic allocation for the structure which
you are suggesting below?
> At a minimum you could probably look at making the bitmap
> an RCU based setup so you could define the base and end along with the
> bitmap. It would probably help to resolve the hotplug issues you still
> need to address.
Thanks for the suggestion. I will look into it.
>
>> enum pgdat_flags {
>> diff --git a/include/linux/page_reporting.h b/include/linux/page_reporting.h
>> new file mode 100644
>> index ..37a39589939d
>> --- /dev/null
>> +++ b/include/linux/page_reporting.h
>> @@ -0,0 +1,63
[virtio-dev] Re: [RFC][Patch v12 1/2] mm: page_reporting: core infrastructure
>> ---
>> include/linux/mmzone.h | 11 ++
>> include/linux/page_reporting.h | 63 +++
>> mm/Kconfig | 6 +
>> mm/Makefile| 1 +
>> mm/page_alloc.c| 42 -
>> mm/page_reporting.c| 332 +
>> 6 files changed, 448 insertions(+), 7 deletions(-)
>> create mode 100644 include/linux/page_reporting.h
>> create mode 100644 mm/page_reporting.c
>>
>> diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
>> index d77d717c620c..ba5f5b508f25 100644
>> --- a/include/linux/mmzone.h
>> +++ b/include/linux/mmzone.h
>> @@ -559,6 +559,17 @@ struct zone {
>> /* Zone statistics */
>> atomic_long_t vm_stat[NR_VM_ZONE_STAT_ITEMS];
>> atomic_long_t vm_numa_stat[NR_VM_NUMA_STAT_ITEMS];
>> +#ifdef CONFIG_PAGE_REPORTING
>> + /* Pointer to the bitmap in PAGE_REPORTING_MIN_ORDER granularity */
>> + unsigned long *bitmap;
>> + /* Preserve start and end PFN in case they change due to hotplug */
>> + unsigned long base_pfn;
>> + unsigned long end_pfn;
>> + /* Free pages of granularity PAGE_REPORTING_MIN_ORDER */
>> + atomic_t free_pages;
>> + /* Number of bits required in the bitmap */
>> + unsigned long nbits;
>> +#endif
>> } cacheline_internodealigned_in_smp;
>
> Okay, so the original thing this patch set had going for it was that
> it was non-invasive. However, now you are adding a bunch of stuff to
> the zone. That kind of loses the non-invasive argument for this patch
> set compared to mine.
>
Adding something to "struct zone" is certainly less invasive than core
buddy modifications, just saying (I agree that this is suboptimal. I
would have guessed that all that's needed is a pointer to some private
structure here). However, the migratetype thingy below looks fishy to me.
> If we are going to continue further with this patch set then it might
> be worth looking into dynamically allocating the space you need for
> this block. At a minimum you could probably look at making the bitmap
> an RCU based setup so you could define the base and end along with the
> bitmap. It would probably help to resolve the hotplug issues you still
> need to address.
Yeah, I guess that makes sense.
[...]
>> +
>> +static int process_free_page(struct page *page,
>> +struct page_reporting_config *phconf, int count)
>> +{
>> + int mt, order, ret = 0;
>> +
>> + mt = get_pageblock_migratetype(page);
>> + order = page_private(page);
>> + ret = __isolate_free_page(page, order);
>> +
I just started looking into the wonderful world of
isolation/compaction/migration.
I don't think saving/restoring the migratetype is correct here. AFAIK,
MOVABLE/UNMOVABLE/RECLAIMABLE is just a hint, doesn't mean that e.g.,
movable pages and up in UNMOVABLE or ordinary kernel allocations on
MOVABLE. So that shouldn't be an issue - I guess.
1. You should never allocate something that is no
MOVABLE/UNMOVABLE/RECLAIMABLE. Especially not, if you have ISOLATE or
CMA here. There should at least be a !is_migrate_isolate_page() check
somewhere
2. set_migratetype_isolate() takes the zone lock, so to avoid racing
with isolation code, you have to hold the zone lock. Your code seems to
do that, so at least you cannot race against isolation.
3. You could end up temporarily allocating something in the
ZONE_MOVABLE. The pages you allocate are, however, not movable. There
would have to be a way to make alloc_contig_range()/offlining code
properly wait until the pages have been processed. Not sure about the
real implications, though - too many details in the code (I wonder if
Alex' series has a way of dealing with that)
When you restore the migratetype, you could suddenly overwrite e.g.,
ISOLATE, which feels wrong.
[...]
> So as per your comments in the cover page, the two functions above
> should also probably be plugged into the zone resizing logic somewhere
> so if a zone is resized the bitmap is adjusted.
>
>> +/**
>> + * zone_reporting_init - For each zone initializes the page reporting fields
>> + * and allocates the respective bitmap.
>> + *
>> + * This function returns 0 on successful initialization, -ENOMEM otherwise.
>> + */
>> +static int zone_reporting_init(void)
>> +{
>> + struct zone *zone;
>> + int ret;
>> +
>> + for_each_populated_zone(zone) {
>> +#ifdef CONFIG_ZONE_DEVICE
>> + /* we can not report pages which are not in the buddy */
>> + if (zone_idx(zone) == ZONE_DEVICE)
>> + continue;
>> +#endif
>
> I'm pretty sure this isn't needed since I don't think the ZONE_DEVICE
> zone will be considered "populated".
>
I think you are right (although it's confusing, we will have present
sections part of a zone but the zone has no present_pages - screams like
a re factoring - leftover from ZONE_DEVICE introduction).
--
Thanks,
[virtio-dev] [PATCH v5 QEMU 3/3] virtio-balloon: Provide a interface for unused page reporting
From: Alexander Duyck
Add support for what I am referring to as "unused page reporting".
Basically the idea is to function very similar to how the balloon works
in that we basically end up madvising the page as not being used. However
we don't really need to bother with any deflate type logic since the page
will be faulted back into the guest when it is read or written to.
This is meant to be a simplification of the existing balloon interface
to use for providing hints to what memory needs to be freed. I am assuming
this is safe to do as the deflate logic does not actually appear to do very
much other than tracking what subpages have been released and which ones
haven't.
Signed-off-by: Alexander Duyck
---
hw/virtio/virtio-balloon.c | 46 ++--
include/hw/virtio/virtio-balloon.h |2 +-
2 files changed, 45 insertions(+), 3 deletions(-)
diff --git a/hw/virtio/virtio-balloon.c b/hw/virtio/virtio-balloon.c
index 003b3ebcfdfb..7a30df63bc77 100644
--- a/hw/virtio/virtio-balloon.c
+++ b/hw/virtio/virtio-balloon.c
@@ -320,6 +320,40 @@ static void balloon_stats_set_poll_interval(Object *obj,
Visitor *v,
balloon_stats_change_timer(s, 0);
}
+static void virtio_balloon_handle_report(VirtIODevice *vdev, VirtQueue *vq)
+{
+VirtIOBalloon *dev = VIRTIO_BALLOON(vdev);
+VirtQueueElement *elem;
+
+while ((elem = virtqueue_pop(vq, sizeof(VirtQueueElement {
+ unsigned int i;
+
+for (i = 0; i < elem->in_num; i++) {
+void *addr = elem->in_sg[i].iov_base;
+size_t size = elem->in_sg[i].iov_len;
+ram_addr_t ram_offset;
+size_t rb_page_size;
+RAMBlock *rb;
+
+if (qemu_balloon_is_inhibited() || dev->poison_val)
+continue;
+
+rb = qemu_ram_block_from_host(addr, false, _offset);
+rb_page_size = qemu_ram_pagesize(rb);
+
+/* For now we will simply ignore unaligned memory regions */
+if ((ram_offset | size) & (rb_page_size - 1))
+continue;
+
+ram_block_discard_range(rb, ram_offset, size);
+}
+
+virtqueue_push(vq, elem, 0);
+virtio_notify(vdev, vq);
+g_free(elem);
+}
+}
+
static void virtio_balloon_handle_output(VirtIODevice *vdev, VirtQueue *vq)
{
VirtIOBalloon *s = VIRTIO_BALLOON(vdev);
@@ -627,7 +661,8 @@ static size_t virtio_balloon_config_size(VirtIOBalloon *s)
return sizeof(struct virtio_balloon_config);
}
if (virtio_has_feature(features, VIRTIO_BALLOON_F_PAGE_POISON) ||
-virtio_has_feature(features, VIRTIO_BALLOON_F_FREE_PAGE_HINT)) {
+virtio_has_feature(features, VIRTIO_BALLOON_F_FREE_PAGE_HINT) ||
+virtio_has_feature(features, VIRTIO_BALLOON_F_REPORTING)) {
return sizeof(struct virtio_balloon_config);
}
return offsetof(struct virtio_balloon_config, free_page_report_cmd_id);
@@ -715,7 +750,8 @@ static uint64_t virtio_balloon_get_features(VirtIODevice
*vdev, uint64_t f,
VirtIOBalloon *dev = VIRTIO_BALLOON(vdev);
f |= dev->host_features;
virtio_add_feature(, VIRTIO_BALLOON_F_STATS_VQ);
-if (virtio_has_feature(f, VIRTIO_BALLOON_F_FREE_PAGE_HINT)) {
+if (virtio_has_feature(f, VIRTIO_BALLOON_F_FREE_PAGE_HINT) ||
+virtio_has_feature(f, VIRTIO_BALLOON_F_REPORTING)) {
virtio_add_feature(, VIRTIO_BALLOON_F_PAGE_POISON);
}
@@ -805,6 +841,10 @@ static void virtio_balloon_device_realize(DeviceState
*dev, Error **errp)
s->dvq = virtio_add_queue(vdev, 128, virtio_balloon_handle_output);
s->svq = virtio_add_queue(vdev, 128, virtio_balloon_receive_stats);
+if (virtio_has_feature(s->host_features, VIRTIO_BALLOON_F_REPORTING)) {
+s->rvq = virtio_add_queue(vdev, 32, virtio_balloon_handle_report);
+}
+
if (virtio_has_feature(s->host_features,
VIRTIO_BALLOON_F_FREE_PAGE_HINT)) {
s->free_page_vq = virtio_add_queue(vdev, VIRTQUEUE_MAX_SIZE,
@@ -931,6 +971,8 @@ static Property virtio_balloon_properties[] = {
*/
DEFINE_PROP_BOOL("qemu-4-0-config-size", VirtIOBalloon,
qemu_4_0_config_size, false),
+DEFINE_PROP_BIT("unused-page-reporting", VirtIOBalloon, host_features,
+VIRTIO_BALLOON_F_REPORTING, true),
DEFINE_PROP_LINK("iothread", VirtIOBalloon, iothread, TYPE_IOTHREAD,
IOThread *),
DEFINE_PROP_END_OF_LIST(),
diff --git a/include/hw/virtio/virtio-balloon.h
b/include/hw/virtio/virtio-balloon.h
index 7fe78e5c14d7..db5bf7127112 100644
--- a/include/hw/virtio/virtio-balloon.h
+++ b/include/hw/virtio/virtio-balloon.h
@@ -42,7 +42,7 @@ enum virtio_balloon_free_page_report_status {
typedef struct VirtIOBalloon {
VirtIODevice parent_obj;
-VirtQueue *ivq, *dvq, *svq, *free_page_vq;
+VirtQueue *ivq, *dvq, *svq, *free_page_vq, *rvq;
uint32_t free_page_report_status;
uint32_t
[virtio-dev] [PATCH v5 4/6] mm: Introduce Reported pages
From: Alexander Duyck
In order to pave the way for free page reporting in virtualized
environments we will need a way to get pages out of the free lists and
identify those pages after they have been returned. To accomplish this,
this patch adds the concept of a Reported Buddy, which is essentially
meant to just be the Uptodate flag used in conjunction with the Buddy
page type.
It adds a set of pointers we shall call "boundary" which represents the
upper boundary between the unreported and reported pages. The general idea
is that in order for a page to cross from one side of the boundary to the
other it will need to go through the reporting process. Ultimately a
free_list has been fully processed when the boundary has been moved from
the tail all they way up to occupying the first entry in the list.
Doing this we should be able to make certain that we keep the reported
pages as one contiguous block in each free list. This will allow us to
efficiently manipulate the free lists whenever we need to go in and start
sending reports to the hypervisor that there are new pages that have been
freed and are no longer in use.
An added advantage to this approach is that we should be reducing the
overall memory footprint of the guest as it will be more likely to recycle
warm pages versus trying to allocate the reported pages that were likely
evicted from the guest memory.
Since we will only be reporting one zone at a time we keep the boundary
limited to being defined for just the zone we are currently reporting pages
from. Doing this we can keep the number of additional pointers needed quite
small. To flag that the boundaries are in place we use a single bit
in the zone to indicate that reporting and the boundaries are active.
The determination of when to start reporting is based on the tracking of
the number of free pages in a given area versus the number of reported
pages in that area. We keep track of the number of reported pages per
free_area in a separate zone specific area. We do this to avoid modifying
the free_area structure as this can lead to false sharing for the highest
order with the zone lock which leads to a noticeable performance
degradation.
Signed-off-by: Alexander Duyck
---
include/linux/mmzone.h | 40 +
include/linux/page-flags.h | 11 +
include/linux/page_reporting.h | 138 ++
mm/Kconfig |5 +
mm/Makefile|1
mm/memory_hotplug.c|1
mm/page_alloc.c| 136 +-
mm/page_reporting.c| 308
8 files changed, 632 insertions(+), 8 deletions(-)
create mode 100644 include/linux/page_reporting.h
create mode 100644 mm/page_reporting.c
diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index 2f2b6f968ed3..b8ed926552b1 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -462,6 +462,14 @@ struct zone {
seqlock_t span_seqlock;
#endif
+#ifdef CONFIG_PAGE_REPORTING
+ /*
+* Pointer to reported page tracking statistics array. The size of
+* the array is MAX_ORDER - PAGE_REPORTING_MIN_ORDER. NULL when
+* unused page reporting is not present.
+*/
+ unsigned long *reported_pages;
+#endif
int initialized;
/* Write-intensive fields used from the page allocator */
@@ -537,6 +545,14 @@ enum zone_flags {
ZONE_BOOSTED_WATERMARK, /* zone recently boosted watermarks.
* Cleared when kswapd is woken.
*/
+ ZONE_PAGE_REPORTING_REQUESTED, /* zone enabled page reporting and has
+* requested flushing the data out of
+* higher order pages.
+*/
+ ZONE_PAGE_REPORTING_ACTIVE, /* zone enabled page reporting and is
+* activly flushing the data out of
+* higher order pages.
+*/
};
static inline unsigned long zone_managed_pages(struct zone *zone)
@@ -757,6 +773,8 @@ static inline bool pgdat_is_empty(pg_data_t *pgdat)
return !pgdat->node_start_pfn && !pgdat->node_spanned_pages;
}
+#include
+
/* Used for pages not on another list */
static inline void add_to_free_list(struct page *page, struct zone *zone,
unsigned int order, int migratetype)
@@ -771,10 +789,16 @@ static inline void add_to_free_list(struct page *page,
struct zone *zone,
static inline void add_to_free_list_tail(struct page *page, struct zone *zone,
unsigned int order, int migratetype)
{
- struct free_area *area = >free_area[order];
+ struct list_head *tail = get_unreported_tail(zone, order, migratetype);
-
[virtio-dev] [PATCH v5 2/6] mm: Move set/get_pcppage_migratetype to mmzone.h
From: Alexander Duyck
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.
Signed-off-by: Alexander Duyck
---
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 e3cb6e7aa296..f04192f5ec3c 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
-
To unsubscribe, e-mail: virtio-dev-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
[virtio-dev] [PATCH v5 1/6] mm: Adjust shuffle code to allow for future coalescing
From: Alexander Duyck
This patch is meant to move the head/tail adding logic out of the shuffle
code and into the __free_one_page function since ultimately that is where
it is really needed anyway. By doing this we should be able to reduce the
overhead and can consolidate all of the list addition bits in one spot.
Signed-off-by: Alexander Duyck
---
include/linux/mmzone.h | 12
mm/page_alloc.c| 70 +++-
mm/shuffle.c | 24
mm/shuffle.h | 32 ++
4 files changed, 71 insertions(+), 67 deletions(-)
diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index aa0dd8ca36c8..c6bd8e9bb476 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -116,18 +116,6 @@ static inline void add_to_free_area_tail(struct page
*page, struct free_area *ar
area->nr_free++;
}
-#ifdef CONFIG_SHUFFLE_PAGE_ALLOCATOR
-/* Used to preserve page allocation order entropy */
-void add_to_free_area_random(struct page *page, struct free_area *area,
- int migratetype);
-#else
-static inline void add_to_free_area_random(struct page *page,
- struct free_area *area, int migratetype)
-{
- add_to_free_area(page, area, migratetype);
-}
-#endif
-
/* Used for pages which are on another list */
static inline void move_to_free_area(struct page *page, struct free_area *area,
int migratetype)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index af29c05e23aa..e3cb6e7aa296 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -877,6 +877,36 @@ static inline struct capture_control *task_capc(struct
zone *zone)
#endif /* CONFIG_COMPACTION */
/*
+ * If this is not the largest possible page, check if the buddy
+ * of the next-highest order is free. If it is, it's possible
+ * that pages are being freed that will coalesce soon. In case,
+ * that is happening, add the free page to the tail of the list
+ * so it's less likely to be used soon and more likely to be merged
+ * as a higher order page
+ */
+static inline bool
+buddy_merge_likely(unsigned long pfn, unsigned long buddy_pfn,
+ struct page *page, unsigned int order)
+{
+ struct page *higher_page, *higher_buddy;
+ unsigned long combined_pfn;
+
+ if (order >= MAX_ORDER - 2)
+ return false;
+
+ if (!pfn_valid_within(buddy_pfn))
+ return false;
+
+ combined_pfn = buddy_pfn & pfn;
+ higher_page = page + (combined_pfn - pfn);
+ buddy_pfn = __find_buddy_pfn(combined_pfn, order + 1);
+ higher_buddy = higher_page + (buddy_pfn - combined_pfn);
+
+ return pfn_valid_within(buddy_pfn) &&
+ page_is_buddy(higher_page, higher_buddy, order + 1);
+}
+
+/*
* Freeing function for a buddy system allocator.
*
* The concept of a buddy system is to maintain direct-mapped table
@@ -905,11 +935,12 @@ static inline void __free_one_page(struct page *page,
struct zone *zone, unsigned int order,
int migratetype)
{
- unsigned long combined_pfn;
+ struct capture_control *capc = task_capc(zone);
unsigned long uninitialized_var(buddy_pfn);
- struct page *buddy;
+ unsigned long combined_pfn;
+ struct free_area *area;
unsigned int max_order;
- struct capture_control *capc = task_capc(zone);
+ struct page *buddy;
max_order = min_t(unsigned int, MAX_ORDER, pageblock_order + 1);
@@ -978,35 +1009,12 @@ static inline void __free_one_page(struct page *page,
done_merging:
set_page_order(page, order);
- /*
-* If this is not the largest possible page, check if the buddy
-* of the next-highest order is free. If it is, it's possible
-* that pages are being freed that will coalesce soon. In case,
-* that is happening, add the free page to the tail of the list
-* so it's less likely to be used soon and more likely to be merged
-* as a higher order page
-*/
- if ((order < MAX_ORDER-2) && pfn_valid_within(buddy_pfn)
- && !is_shuffle_order(order)) {
- struct page *higher_page, *higher_buddy;
- combined_pfn = buddy_pfn & pfn;
- higher_page = page + (combined_pfn - pfn);
- buddy_pfn = __find_buddy_pfn(combined_pfn, order + 1);
- higher_buddy = higher_page + (buddy_pfn - combined_pfn);
- if (pfn_valid_within(buddy_pfn) &&
- page_is_buddy(higher_page, higher_buddy, order + 1)) {
- add_to_free_area_tail(page, >free_area[order],
- migratetype);
- return;
- }
- }
-
- if (is_shuffle_order(order))
- add_to_free_area_random(page, >free_area[order],
- migratetype);
+
