similar to: [PATCH] KVM virtio balloon driver

Following patch introduces a KVM guest balloon driver. Communication to/from the host is performed via virtio. Next patch implements the QEMU driver and handling. Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com> Index: linux-2.6-nv/drivers/virtio/Kconfig =================================================================== --- linux-2.6-nv.orig/drivers/virtio/Kconfig +++

Following patch introduces a KVM guest balloon driver. Communication to/from the host is performed via virtio. Next patch implements the QEMU driver and handling. Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com> Index: linux-2.6-nv/drivers/virtio/Kconfig =================================================================== --- linux-2.6-nv.orig/drivers/virtio/Kconfig +++

This implementation of a virtio balloon driver uses the page cache to "store" pages that have been released to the host. The communication (outside of target counts) is one way--the guest notifies the host when it adds a page to the page cache, allowing the host to madvise(2) with MADV_DONTNEED. Reclaim in the guest is therefore automatic and implicit (via the regular page reclaim).

This implementation of a virtio balloon driver uses the page cache to "store" pages that have been released to the host. The communication (outside of target counts) is one way--the guest notifies the host when it adds a page to the page cache, allowing the host to madvise(2) with MADV_DONTNEED. Reclaim in the guest is therefore automatic and implicit (via the regular page reclaim).

pagecache for pages above lower limit but that is a separate question about driver design, I would like to make sure I understand the high level design first. > > > > Note that users could not care less about how a driver > > is implemented internally. > > > > Is there some workload where you see VM working better with > > this than regular balloon? Any

pagecache for pages above lower limit but that is a separate question about driver design, I would like to make sure I understand the high level design first. > > > > Note that users could not care less about how a driver > > is implemented internally. > > > > Is there some workload where you see VM working better with > > this than regular balloon? Any

Signed-off-by: Christoph Hellwig <hch@lst.de> Index: linux-2.6/fs/ocfs2/cluster/tcp.c =================================================================== --- linux-2.6.orig/fs/ocfs2/cluster/tcp.c 2007-05-06 13:51:17.000000000 +0200 +++ linux-2.6/fs/ocfs2/cluster/tcp.c 2007-05-17 15:00:14.000000000 +0200 @@ -261,14 +261,12 @@ out: static void o2net_complete_nodes_nsw(struct o2net_node

Add QEMU support for the KVM balloon driver. Memory hinting is performed via madvise(). Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com> Index: kvm-userspace/libkvm/libkvm.c =================================================================== --- kvm-userspace.orig/libkvm/libkvm.c +++ kvm-userspace/libkvm/libkvm.c @@ -886,6 +886,17 @@ int kvm_is_ready_for_interrupt_injection return

Add QEMU support for the KVM balloon driver. Memory hinting is performed via madvise(). Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com> Index: kvm-userspace/libkvm/libkvm.c =================================================================== --- kvm-userspace.orig/libkvm/libkvm.c +++ kvm-userspace/libkvm/libkvm.c @@ -886,6 +886,17 @@ int kvm_is_ready_for_interrupt_injection return

From: Sjur Br?ndeland <sjur.brandeland at stericsson.com> Add a simple serial connection driver called VIRTIO_ID_RPROC_SERIAL (11) for communicating with a remote processor in an asymmetric multi-processing configuration. This implementation reuses the existing virtio_console implementation, and adds support for DMA allocation of data buffers and disables use of tty console and the virtio

From: Sjur Br?ndeland <sjur.brandeland at stericsson.com> Add a simple serial connection driver called VIRTIO_ID_RPROC_SERIAL (11) for communicating with a remote processor in an asymmetric multi-processing configuration. This implementation reuses the existing virtio_console implementation, and adds support for DMA allocation of data buffers and disables use of tty console and the virtio

This patch-set introduces a new virtio type "rproc_serial" for communicating with remote processors over shared memory. The driver depends on the the remoteproc framework. As preparation for introducing "rproc_serial" I've done a refactoring of the transmit buffer handling. NOTE: These two patches are identical to first two patches of the V8 patch-set, but are rebased to

This patch-set introduces a new virtio type "rproc_serial" for communicating with remote processors over shared memory. The driver depends on the the remoteproc framework. As preparation for introducing "rproc_serial" I've done a refactoring of the transmit buffer handling. NOTE: These two patches are identical to first two patches of the V8 patch-set, but are rebased to

From: Sjur Br?ndeland <sjur.brandeland at stericsson.com> This patch-set introduces a new virtio type "rproc_serial" for communicating with remote processors over shared memory. The driver depends on the the remoteproc framework. As preparation for introducing "rproc_serial" I've done a refactoring of the transmit buffer handling. Changes since v7: - Rebased to

From: Sjur Br?ndeland <sjur.brandeland at stericsson.com> This patch-set introduces a new virtio type "rproc_serial" for communicating with remote processors over shared memory. The driver depends on the the remoteproc framework. As preparation for introducing "rproc_serial" I've done a refactoring of the transmit buffer handling. Changes since v7: - Rebased to

From: Sjur Br?ndeland <sjur.brandeland at stericsson.com> I thought rebasing rproc_serial to linux-next was going to be trivial. But when starting the merge I realized that I had to refactor the the patches from Masami Hiramatsu. The splice support has the same issue as I faced, with different type of buffers in the out_vq. So I ended up refactoring the splice functionality. The code size

From: Sjur Br?ndeland <sjur.brandeland at stericsson.com> I thought rebasing rproc_serial to linux-next was going to be trivial. But when starting the merge I realized that I had to refactor the the patches from Masami Hiramatsu. The splice support has the same issue as I faced, with different type of buffers in the out_vq. So I ended up refactoring the splice functionality. The code size

From: Sjur Br?ndeland <sjur.brandeland at stericsson.com> This patch-set introduces a new virtio type "rproc_serial" for communicating with remote processors over shared memory. The driver depends on the the remoteproc framework. As preparation for introducing "rproc_serial" I've done a refactoring of the transmit buffer handling. This patch-set is a rework of the

From: Sjur Br?ndeland <sjur.brandeland at stericsson.com> This patch-set introduces a new virtio type "rproc_serial" for communicating with remote processors over shared memory. The driver depends on the the remoteproc framework. As preparation for introducing "rproc_serial" I've done a refactoring of the transmit buffer handling. This patch-set is a rework of the

Migration from mod_timer() to schedule_delayed_work(). Signed-off-by: Daniel Kiper <dkiper@net-space.pl> --- drivers/xen/balloon.c | 16 +++------------- 1 files changed, 3 insertions(+), 13 deletions(-) diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c index 952cfe2..4223f64 100644 --- a/drivers/xen/balloon.c +++ b/drivers/xen/balloon.c @@ -99,8 +99,7 @@ static