|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] [PATCH RFC 00/10] Xen balloon page compaction support
Hi all
This is a prototype to make Xen balloon driver work with balloon page
compaction. The goal is to reduce guest physical address space fragmentation
introduced by balloon pages. Having guest physical address space as contiguous
as possible is generally useful (because guest can have higher order pages), and
it should also help improve HVM performance (provided that guest kernel knows
how to use huge pages -- Linux has hugetlbfs and transparent huge page).
The approach is simple. Core balloon driver is made one of the page sources of
Xen balloon driver. Those pages allocated from core balloon driver are subject
to balloon page compaction.
It can be found at [0] how memory compaction is supposed to work. Balloon page
compaction makes use of page migration infrastructure in kernel to migrate
balloon pages from start of a zone to end of a zone, hence creating contiguous
physical address space for guest. Callback to migrate balloon page to another
location is provided by Xen balloon driver. In essence the callback just
inflates one page and deflates the other.
Looking at the stats of my experiment, to completely defragment guest address
space can be very time consuming because 1) compaction thread can only work
with a small amount of pages in one pass and 2) compaction thread moves
ballooned pages towards end of zone while buddy page allocator can allocate
ballooned pages in the middle of a zone, which increases compaction thread's
workload.
Here are some statistics.
VM has 1024 MB ram. Balloon it up and down in 64 MB trunk while compiling
kernel. After a while VM memory is set to 768 MB and compilation is stopped.
Before compaction starts, /proc/buddyinfo looks like this.
Node 0, zone DMA 406 276 79 19 5 3 4 1
0 1 0
Node 0, zone DMA32 8162 16373 10204 3944 874 137 23 10
2 0 4
Use following command to repeatedly trigger memory compaction.
while true; do echo 3 > /proc/sys/vm/drop_caches; echo 1 >
/proc/sys/vm/compact_memory; sleep 5; done
After compaction runs for about 20 minutes, /proc/buddyinfo looks like this.
Node 0, zone DMA 25 26 16 7 5 5 5 4
2 2 0
Node 0, zone DMA32 2078 2480 1696 796 376 293 221 199
189 43 16
Numbers of high order pages increase. The number of 2 MB pages increases from 8
(4 * 2 + 0) to 75 (16 * 2 + 43).
If VM is ballooned down when there's nothing running inside, buddyinfo looks
like this.
Node 0, zone DMA 5 15 8 2 3 3 4 2
1 3 0
Node 0, zone DMA32 603 380 152 85 48 32 11 8
2 1 137
The number of 2 MB pages is 275 (137 * 2 + 1).
In conclusion, balloon page compaction cannot guarantee the end result is the
same as a quietly ballooned down system. But it does provide some improvement.
The nice thing about this approach is that it doesn't rely on any hypervisor
side feature to work. Also if the defragmentation algorithm improves we get
free improvement as well.
Any thought on this patch series?
Wei.
[0] https://lwn.net/Articles/368869/
Wei Liu (10):
balloon_compaction: don't BUG() when it is not necessary
xen/balloon: fix code comment for free_xenballooned_pages
xen/balloon: consolidate data structures
xen/balloon: factor out function to update balloon stats
xen/balloon: rework increase_reservation
xen/balloon: make use of generic balloon driver
xen/balloon: factor out some helper functions
xen/balloon: implement migratepage
balloon: BALLOON_COMPACTION now depends on XEN_BALLOON
XXX: balloon bitmap and sysrq key to dump bitmap
drivers/virtio/virtio_balloon.c | 2 +-
drivers/xen/balloon.c | 630 ++++++++++++++++++++++++++----------
drivers/xen/xen-balloon.c | 24 +-
include/linux/balloon_compaction.h | 3 +-
include/xen/balloon.h | 19 +-
mm/Kconfig | 2 +-
mm/balloon_compaction.c | 9 +-
7 files changed, 501 insertions(+), 188 deletions(-)
--
1.7.10.4
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |