* AW: linux: try harder to balloon up under memory pressure.
@ 2009-06-05 12:41 Carsten Schiers
2009-06-05 13:02 ` Ian Campbell
0 siblings, 1 reply; 3+ messages in thread
From: Carsten Schiers @ 2009-06-05 12:41 UTC (permalink / raw)
To: Ian Campbell; +Cc: xen-devel, Keir Fraser
Ian, sorry if this question is stupid, but might this patch be the remedy
for an observation that I made:
pv DomU with need for swiotlb memory (kernel option swiotlb=32,force) is
not starting with an error "not being able to allocate enough memory",
especially during startup phase where some 7 DomUs are starting, but will
succeed to do so if you wait some minutes
To my current knowledge, swiotlb memory is just memory, although there are
some further "reuirements", but I assume it's handled the same way.
BR,
Carsten.
----- Originalnachricht -----
Von: Ian Campbell <Ian.Campbell@eu.citrix.com>
Gesendet: Fre, 5.6.2009 12:57
An: xen-devel <xen-devel@lists.xensource.com>
Cc: Keir Fraser <Keir.Fraser@eu.citrix.com>
Betreff: [Xen-devel] linux: try harder to balloon up under memory pressure.
Currently if the balloon driver is unable to increase the guest's
reservation it assumes the failure was due to reaching its full
allocation, gives up on the ballooning operation and records the limit
it reached as the "hard limit". The driver will not try again until
the target is set again (even to the same value).
However it is possible that ballooning has in fact failed due to
memory pressure in the host and therefore it is desirable to keep
attempting to reach the target in case memory becomes available. The
most likely scenario is that some guests are ballooning down while
others are ballooning up and therefore there is temporary memory
pressure while things stabilise. You would not expect a well behaved
toolstack to ask a domain to balloon to more than its allocation nor
would you expect it to deliberately over-commit memory by setting
balloon targets which exceed the total host memory.
This patch drops the concept of a hard limit and causes the balloon
driver to retry increasing the reservation on a timer in the same
manner as when decreasing the reservation.
Also if we partially succeed in increasing the reservation
(i.e. receive less pages than we asked for) then we may as well keep
those pages rather than returning them to Xen.
This patch is for the 2.6.18-xen tree.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
diff -r fd9c565657b8 drivers/xen/balloon/balloon.c
--- a/drivers/xen/balloon/balloon.c Thu Jun 04 16:26:49 2009 +0100
+++ b/drivers/xen/balloon/balloon.c Fri Jun 05 11:56:22 2009 +0100
@@ -188,7 +188,7 @@
static unsigned long current_target(void)
{
- unsigned long target = min(bs.target_pages, bs.hard_limit);
+ unsigned long target = bs.target_pages;
if (target > (bs.current_pages + bs.balloon_low + bs.balloon_high))
target = bs.current_pages + bs.balloon_low + bs.balloon_high;
return target;
@@ -255,26 +255,12 @@
}
set_xen_guest_handle(reservation.extent_start, frame_list);
- reservation.nr_extents = nr_pages;
- rc = HYPERVISOR_memory_op(
- XENMEM_populate_physmap, &reservation);
- if (rc < nr_pages) {
- if (rc > 0) {
- int ret;
+ reservation.nr_extents = nr_pages;
+ rc = HYPERVISOR_memory_op(XENMEM_populate_physmap, &reservation);
+ if (rc < 0)
+ goto out;
- /* We hit the Xen hard limit: reprobe. */
- reservation.nr_extents = rc;
- ret = HYPERVISOR_memory_op(XENMEM_decrease_reservation,
- &reservation);
- BUG_ON(ret != rc);
- }
- if (rc >= 0)
- bs.hard_limit = (bs.current_pages + rc -
- bs.driver_pages);
- goto out;
- }
-
- for (i = 0; i < nr_pages; i++) {
+ for (i = 0; i < rc; i++) {
page = balloon_retrieve();
BUG_ON(page == NULL);
@@ -302,13 +288,13 @@
balloon_free_page(page);
}
- bs.current_pages += nr_pages;
+ bs.current_pages += rc;
totalram_pages = bs.current_pages;
out:
balloon_unlock(flags);
- return 0;
+ return rc < 0 ? rc : rc != nr_pages;
}
static int decrease_reservation(unsigned long nr_pages)
@@ -420,7 +406,6 @@
void balloon_set_new_target(unsigned long target)
{
/* No need for lock. Not read-modify-write updates. */
- bs.hard_limit = ~0UL;
bs.target_pages = max(target, minimum_target());
schedule_work(&balloon_worker);
}
@@ -498,17 +483,11 @@
"Requested target: %8lu kB\n"
"Low-mem balloon: %8lu kB\n"
"High-mem balloon: %8lu kB\n"
- "Driver pages: %8lu kB\n"
- "Xen hard limit: ",
+ "Driver pages: %8lu kB\n",
PAGES2KB(bs.current_pages), PAGES2KB(bs.target_pages),
PAGES2KB(bs.balloon_low), PAGES2KB(bs.balloon_high),
PAGES2KB(bs.driver_pages));
- if (bs.hard_limit != ~0UL)
- len += sprintf(page + len, "%8lu kB\n",
- PAGES2KB(bs.hard_limit));
- else
- len += sprintf(page + len, " ??? kB\n");
*eof = 1;
return len;
@@ -539,7 +518,6 @@
bs.balloon_low = 0;
bs.balloon_high = 0;
bs.driver_pages = 0UL;
- bs.hard_limit = ~0UL;
init_timer(&balloon_timer);
balloon_timer.data = 0;
diff -r fd9c565657b8 drivers/xen/balloon/common.h
--- a/drivers/xen/balloon/common.h Thu Jun 04 16:26:49 2009 +0100
+++ b/drivers/xen/balloon/common.h Fri Jun 05 11:56:22 2009 +0100
@@ -35,8 +35,6 @@
/* We aim for 'current allocation' == 'target allocation'. */
unsigned long current_pages;
unsigned long target_pages;
- /* We may hit the hard limit in Xen. If we do then we remember it. */
- unsigned long hard_limit;
/*
* Drivers may alter the memory reservation independently, but they
* must inform the balloon driver so we avoid hitting the hard limit.
diff -r fd9c565657b8 drivers/xen/balloon/sysfs.c
--- a/drivers/xen/balloon/sysfs.c Thu Jun 04 16:26:49 2009 +0100
+++ b/drivers/xen/balloon/sysfs.c Fri Jun 05 11:56:22 2009 +0100
@@ -53,9 +53,6 @@
BALLOON_SHOW(current_kb, "%lu\n", PAGES2KB(bs.current_pages));
BALLOON_SHOW(low_kb, "%lu\n", PAGES2KB(bs.balloon_low));
BALLOON_SHOW(high_kb, "%lu\n", PAGES2KB(bs.balloon_high));
-BALLOON_SHOW(hard_limit_kb,
- (bs.hard_limit!=~0UL) ? "%lu\n" : "???\n",
- (bs.hard_limit!=~0UL) ? PAGES2KB(bs.hard_limit) : 0);
BALLOON_SHOW(driver_kb, "%lu\n", PAGES2KB(bs.driver_pages));
static ssize_t show_target_kb(struct sys_device *dev, char *buf)
@@ -96,7 +93,6 @@
&attr_current_kb.attr,
&attr_low_kb.attr,
&attr_high_kb.attr,
- &attr_hard_limit_kb.attr,
&attr_driver_kb.attr,
NULL
};
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: AW: linux: try harder to balloon up under memory pressure.
2009-06-05 12:41 Carsten Schiers
@ 2009-06-05 13:02 ` Ian Campbell
0 siblings, 0 replies; 3+ messages in thread
From: Ian Campbell @ 2009-06-05 13:02 UTC (permalink / raw)
To: Carsten Schiers; +Cc: xen-devel, Keir Fraser
On Fri, 2009-06-05 at 08:41 -0400, Carsten Schiers wrote:
> Ian, sorry if this question is stupid, but might this patch be the remedy
> for an observation that I made:
>
> pv DomU with need for swiotlb memory (kernel option swiotlb=32,force) is
> not starting with an error "not being able to allocate enough memory",
> especially during startup phase where some 7 DomUs are starting, but will
> succeed to do so if you wait some minutes
>
> To my current knowledge, swiotlb memory is just memory, although there are
> some further "reuirements", but I assume it's handled the same way.
It is similar but not the same, swiotlb uses XENMEM_exchange (via
xen_create_contiguous_region()) to swap pages for more suitable ones
while ballooning uses XENMEM_populate_physmap to simply allocate more
pages so this patch is unlikely to help.
I can't really explain why swiotlb-suitable pages would be unavailable
while a bunch of domains are starting but some become available later on
(without killing one or more of those domains).
Do you see "Cannot allocate SWIOTLB buffer!" or "No suitable physical
memory available for SWIOTLB buffer!"?
Ian.
>
> BR,
> Carsten.
>
> ----- Originalnachricht -----
> Von: Ian Campbell <Ian.Campbell@eu.citrix.com>
> Gesendet: Fre, 5.6.2009 12:57
> An: xen-devel <xen-devel@lists.xensource.com>
> Cc: Keir Fraser <Keir.Fraser@eu.citrix.com>
> Betreff: [Xen-devel] linux: try harder to balloon up under memory pressure.
>
> Currently if the balloon driver is unable to increase the guest's
> reservation it assumes the failure was due to reaching its full
> allocation, gives up on the ballooning operation and records the limit
> it reached as the "hard limit". The driver will not try again until
> the target is set again (even to the same value).
>
> However it is possible that ballooning has in fact failed due to
> memory pressure in the host and therefore it is desirable to keep
> attempting to reach the target in case memory becomes available. The
> most likely scenario is that some guests are ballooning down while
> others are ballooning up and therefore there is temporary memory
> pressure while things stabilise. You would not expect a well behaved
> toolstack to ask a domain to balloon to more than its allocation nor
> would you expect it to deliberately over-commit memory by setting
> balloon targets which exceed the total host memory.
>
> This patch drops the concept of a hard limit and causes the balloon
> driver to retry increasing the reservation on a timer in the same
> manner as when decreasing the reservation.
>
> Also if we partially succeed in increasing the reservation
> (i.e. receive less pages than we asked for) then we may as well keep
> those pages rather than returning them to Xen.
>
> This patch is for the 2.6.18-xen tree.
>
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
>
> diff -r fd9c565657b8 drivers/xen/balloon/balloon.c
> --- a/drivers/xen/balloon/balloon.c Thu Jun 04 16:26:49 2009 +0100
> +++ b/drivers/xen/balloon/balloon.c Fri Jun 05 11:56:22 2009 +0100
> @@ -188,7 +188,7 @@
>
> static unsigned long current_target(void)
> {
> - unsigned long target = min(bs.target_pages, bs.hard_limit);
> + unsigned long target = bs.target_pages;
> if (target > (bs.current_pages + bs.balloon_low + bs.balloon_high))
> target = bs.current_pages + bs.balloon_low + bs.balloon_high;
> return target;
> @@ -255,26 +255,12 @@
> }
>
> set_xen_guest_handle(reservation.extent_start, frame_list);
> - reservation.nr_extents = nr_pages;
> - rc = HYPERVISOR_memory_op(
> - XENMEM_populate_physmap, &reservation);
> - if (rc < nr_pages) {
> - if (rc > 0) {
> - int ret;
> + reservation.nr_extents = nr_pages;
> + rc = HYPERVISOR_memory_op(XENMEM_populate_physmap, &reservation);
> + if (rc < 0)
> + goto out;
>
> - /* We hit the Xen hard limit: reprobe. */
> - reservation.nr_extents = rc;
> - ret = HYPERVISOR_memory_op(XENMEM_decrease_reservation,
> - &reservation);
> - BUG_ON(ret != rc);
> - }
> - if (rc >= 0)
> - bs.hard_limit = (bs.current_pages + rc -
> - bs.driver_pages);
> - goto out;
> - }
> -
> - for (i = 0; i < nr_pages; i++) {
> + for (i = 0; i < rc; i++) {
> page = balloon_retrieve();
> BUG_ON(page == NULL);
>
> @@ -302,13 +288,13 @@
> balloon_free_page(page);
> }
>
> - bs.current_pages += nr_pages;
> + bs.current_pages += rc;
> totalram_pages = bs.current_pages;
>
> out:
> balloon_unlock(flags);
>
> - return 0;
> + return rc < 0 ? rc : rc != nr_pages;
> }
>
> static int decrease_reservation(unsigned long nr_pages)
> @@ -420,7 +406,6 @@
> void balloon_set_new_target(unsigned long target)
> {
> /* No need for lock. Not read-modify-write updates. */
> - bs.hard_limit = ~0UL;
> bs.target_pages = max(target, minimum_target());
> schedule_work(&balloon_worker);
> }
> @@ -498,17 +483,11 @@
> "Requested target: %8lu kB\n"
> "Low-mem balloon: %8lu kB\n"
> "High-mem balloon: %8lu kB\n"
> - "Driver pages: %8lu kB\n"
> - "Xen hard limit: ",
> + "Driver pages: %8lu kB\n",
> PAGES2KB(bs.current_pages), PAGES2KB(bs.target_pages),
> PAGES2KB(bs.balloon_low), PAGES2KB(bs.balloon_high),
> PAGES2KB(bs.driver_pages));
>
> - if (bs.hard_limit != ~0UL)
> - len += sprintf(page + len, "%8lu kB\n",
> - PAGES2KB(bs.hard_limit));
> - else
> - len += sprintf(page + len, " ??? kB\n");
>
> *eof = 1;
> return len;
> @@ -539,7 +518,6 @@
> bs.balloon_low = 0;
> bs.balloon_high = 0;
> bs.driver_pages = 0UL;
> - bs.hard_limit = ~0UL;
>
> init_timer(&balloon_timer);
> balloon_timer.data = 0;
> diff -r fd9c565657b8 drivers/xen/balloon/common.h
> --- a/drivers/xen/balloon/common.h Thu Jun 04 16:26:49 2009 +0100
> +++ b/drivers/xen/balloon/common.h Fri Jun 05 11:56:22 2009 +0100
> @@ -35,8 +35,6 @@
> /* We aim for 'current allocation' == 'target allocation'. */
> unsigned long current_pages;
> unsigned long target_pages;
> - /* We may hit the hard limit in Xen. If we do then we remember it. */
> - unsigned long hard_limit;
> /*
> * Drivers may alter the memory reservation independently, but they
> * must inform the balloon driver so we avoid hitting the hard limit.
> diff -r fd9c565657b8 drivers/xen/balloon/sysfs.c
> --- a/drivers/xen/balloon/sysfs.c Thu Jun 04 16:26:49 2009 +0100
> +++ b/drivers/xen/balloon/sysfs.c Fri Jun 05 11:56:22 2009 +0100
> @@ -53,9 +53,6 @@
> BALLOON_SHOW(current_kb, "%lu\n", PAGES2KB(bs.current_pages));
> BALLOON_SHOW(low_kb, "%lu\n", PAGES2KB(bs.balloon_low));
> BALLOON_SHOW(high_kb, "%lu\n", PAGES2KB(bs.balloon_high));
> -BALLOON_SHOW(hard_limit_kb,
> - (bs.hard_limit!=~0UL) ? "%lu\n" : "???\n",
> - (bs.hard_limit!=~0UL) ? PAGES2KB(bs.hard_limit) : 0);
> BALLOON_SHOW(driver_kb, "%lu\n", PAGES2KB(bs.driver_pages));
>
> static ssize_t show_target_kb(struct sys_device *dev, char *buf)
> @@ -96,7 +93,6 @@
> &attr_current_kb.attr,
> &attr_low_kb.attr,
> &attr_high_kb.attr,
> - &attr_hard_limit_kb.attr,
> &attr_driver_kb.attr,
> NULL
> };
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
^ permalink raw reply [flat|nested] 3+ messages in thread
* AW: linux: try harder to balloon up under memory pressure.
@ 2009-06-05 13:28 Carsten Schiers
0 siblings, 0 replies; 3+ messages in thread
From: Carsten Schiers @ 2009-06-05 13:28 UTC (permalink / raw)
To: Ian Campbell; +Cc: xen-devel, Keir Fraser
It's this part here:
/*
* Get IO TLB memory from the low pages
*/
iotlb_virt_start = alloc_bootmem_pages(bytes);
if (!iotlb_virt_start)
panic("Cannot allocate SWIOTLB buffer!\n");
dma_bits = get_order(IO_TLB_SEGSIZE << IO_TLB_SHIFT) + PAGE_SHIFT;
for (i = 0; i < iotlb_nslabs; i += IO_TLB_SEGSIZE) {
do {
rc = xen_create_contiguous_region(
(unsigned long)iotlb_virt_start + (i << IO_TLB_SHIFT),
get_order(IO_TLB_SEGSIZE << IO_TLB_SHIFT),
dma_bits);
} while (rc && dma_bits++ < max_dma_bits);
if (rc) {
if (i == 0)
===> panic("No suitable physical memory available for SWIOTLB buffer!\n"
===> "Use dom0_mem Xen boot parameter to reserve\n"
===> "some DMA memory (e.g., dom0_mem=-128M).\n");
Whether it occurs at all and why it's gone is quite a mistery for me. Please note that in addition to
the DomU that actually crashed, there is another with swiotlb=32,force. Changing the order to start
might change what DomU is crashing, but in most cases, it will start after waiting some minutes, yes
minutes.
Maybe it's important for you that I have some memory left in general:
data:/var/log/xen# xm info
host : data
release : 2.6.18.8-xen-3.4.0
version : #1 SMP Wed May 27 13:20:06 CEST 2009
machine : x86_64
nr_cpus : 2
nr_nodes : 1
cores_per_socket : 2
threads_per_core : 1
cpu_mhz : 2109
hw_caps : 178bf3ff:ebd3fbff:00000000:00000010:00002001:00000000:0000011f:00000000
virt_caps : hvm
total_memory : 4094
free_memory : 287
node_to_cpu : node0:0-1
node_to_memory : node0:287
xen_major : 3
xen_minor : 4
xen_extra : .0
xen_caps : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64
xen_scheduler : credit
xen_pagesize : 4096
platform_params : virt_start=0xffff800000000000
xen_changeset : unavailable
cc_compiler : gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
cc_compile_by : root
cc_compile_domain : space.zz
cc_compile_date : Wed Jun 3 06:16:55 CEST 2009
xend_config_format : 4
The DomU is defined like this (PCI device is an USB, where I attach an USB ISDN box):
kernel='/usr/lib/xen/boot/vmlinuz-2.6.18.8-xen-3.4.0'
ramdisk='/usr/lib/xen/boot/initrd.img-2.6.18.8-xen-3.4.0'
extra='swiotlb=32,force xencons=tty'
name='uhura'
memory='1024'
root='/dev/xvda1 ro'
cpu_weight='128'
disk = [
'phy:/dev/space/uhura_lv_root,xvda1,w',
'phy:/dev/space/uhura_lv_swap,xvda2,w',
'phy:/dev/space/uhura_lv_vos,xvda3,w'
]
vif = [
'mac=00:16:3E:60:4C:B7,bridge=intern'
]
pci = [
'00:02.0'
]
The settings for Xen and Dom0 are (lines broken for readability):
title Xen 3.4.0 / Xen 2.6.18.8-xen-3.4.0 / multi / with cpufreq mgmt
root (hd0,0)
kernel /xen-3.4.0.gz vga=text-80x25 dom0_mem=256M cpuidle cpufreq=dom0-kernel
module /vmlinuz-2.6.18.8-xen-3.4.0 root=/dev/mapper/space-data_lv_root ro BOOT console=tty0
pciback.hide=(00:02.0)(00:02.1)(00:06.0)(01:07.0)(01:08.0)(01:09.0) noirqdebug nousb
xencons=off
module /initrd.img-2.6.18.8-xen-3.4.0
savedefault
Part of xend-config.sxp related to memory is (don't ask me why I set 196 here, but when playing arround
yesterday with 256 and 192 (to leave over 64MB, it happend again. When reverted, everything is ok):
# dom0-min-mem is the lowest permissible memory level (in MB) for dom0.
# This is a minimum both for auto-ballooning (as enabled by
# enable-dom0-ballooning below) and for xm mem-set when applied to dom0.
(dom0-min-mem 196)
# Whether to enable auto-ballooning of dom0 to allow domUs to be created.
# If enable-dom0-ballooning = no, dom0 will never balloon out.
(enable-dom0-ballooning yes)
GrC.
----- Originalnachricht -----
Von: Ian Campbell <Ian.Campbell@eu.citrix.com>
Gesendet: Fre, 5.6.2009 15:02
An: Carsten Schiers <carsten@schiers.de>
Cc: xen-devel <xen-devel@lists.xensource.com> ; Keir Fraser <Keir.Fraser@eu.citrix.com>
Betreff: Re: AW: [Xen-devel] linux: try harder to balloon up under memory pressure.
On Fri, 2009-06-05 at 08:41 -0400, Carsten Schiers wrote:
> Ian, sorry if this question is stupid, but might this patch be the remedy
> for an observation that I made:
>
> pv DomU with need for swiotlb memory (kernel option swiotlb=32,force) is
> not starting with an error "not being able to allocate enough memory",
> especially during startup phase where some 7 DomUs are starting, but will
> succeed to do so if you wait some minutes
>
> To my current knowledge, swiotlb memory is just memory, although there are
> some further "reuirements", but I assume it's handled the same way.
It is similar but not the same, swiotlb uses XENMEM_exchange (via
xen_create_contiguous_region()) to swap pages for more suitable ones
while ballooning uses XENMEM_populate_physmap to simply allocate more
pages so this patch is unlikely to help.
I can't really explain why swiotlb-suitable pages would be unavailable
while a bunch of domains are starting but some become available later on
(without killing one or more of those domains).
Do you see "Cannot allocate SWIOTLB buffer!" or "No suitable physical
memory available for SWIOTLB buffer!"?
Ian.
>
> BR,
> Carsten.
>
> ----- Originalnachricht -----
> Von: Ian Campbell <Ian.Campbell@eu.citrix.com>
> Gesendet: Fre, 5.6.2009 12:57
> An: xen-devel <xen-devel@lists.xensource.com>
> Cc: Keir Fraser <Keir.Fraser@eu.citrix.com>
> Betreff: [Xen-devel] linux: try harder to balloon up under memory pressure.
>
> Currently if the balloon driver is unable to increase the guest's
> reservation it assumes the failure was due to reaching its full
> allocation, gives up on the ballooning operation and records the limit
> it reached as the "hard limit". The driver will not try again until
> the target is set again (even to the same value).
>
> However it is possible that ballooning has in fact failed due to
> memory pressure in the host and therefore it is desirable to keep
> attempting to reach the target in case memory becomes available. The
> most likely scenario is that some guests are ballooning down while
> others are ballooning up and therefore there is temporary memory
> pressure while things stabilise. You would not expect a well behaved
> toolstack to ask a domain to balloon to more than its allocation nor
> would you expect it to deliberately over-commit memory by setting
> balloon targets which exceed the total host memory.
>
> This patch drops the concept of a hard limit and causes the balloon
> driver to retry increasing the reservation on a timer in the same
> manner as when decreasing the reservation.
>
> Also if we partially succeed in increasing the reservation
> (i.e. receive less pages than we asked for) then we may as well keep
> those pages rather than returning them to Xen.
>
> This patch is for the 2.6.18-xen tree.
>
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
>
> diff -r fd9c565657b8 drivers/xen/balloon/balloon.c
> --- a/drivers/xen/balloon/balloon.c Thu Jun 04 16:26:49 2009 +0100
> +++ b/drivers/xen/balloon/balloon.c Fri Jun 05 11:56:22 2009 +0100
> @@ -188,7 +188,7 @@
>
> static unsigned long current_target(void)
> {
> - unsigned long target = min(bs.target_pages, bs.hard_limit);
> + unsigned long target = bs.target_pages;
> if (target > (bs.current_pages + bs.balloon_low + bs.balloon_high))
> target = bs.current_pages + bs.balloon_low + bs.balloon_high;
> return target;
> @@ -255,26 +255,12 @@
> }
>
> set_xen_guest_handle(reservation.extent_start, frame_list);
> - reservation.nr_extents = nr_pages;
> - rc = HYPERVISOR_memory_op(
> - XENMEM_populate_physmap, &reservation);
> - if (rc < nr_pages) {
> - if (rc > 0) {
> - int ret;
> + reservation.nr_extents = nr_pages;
> + rc = HYPERVISOR_memory_op(XENMEM_populate_physmap, &reservation);
> + if (rc < 0)
> + goto out;
>
> - /* We hit the Xen hard limit: reprobe. */
> - reservation.nr_extents = rc;
> - ret = HYPERVISOR_memory_op(XENMEM_decrease_reservation,
> - &reservation);
> - BUG_ON(ret != rc);
> - }
> - if (rc >= 0)
> - bs.hard_limit = (bs.current_pages + rc -
> - bs.driver_pages);
> - goto out;
> - }
> -
> - for (i = 0; i < nr_pages; i++) {
> + for (i = 0; i < rc; i++) {
> page = balloon_retrieve();
> BUG_ON(page == NULL);
>
> @@ -302,13 +288,13 @@
> balloon_free_page(page);
> }
>
> - bs.current_pages += nr_pages;
> + bs.current_pages += rc;
> totalram_pages = bs.current_pages;
>
> out:
> balloon_unlock(flags);
>
> - return 0;
> + return rc < 0 ? rc : rc != nr_pages;
> }
>
> static int decrease_reservation(unsigned long nr_pages)
> @@ -420,7 +406,6 @@
> void balloon_set_new_target(unsigned long target)
> {
> /* No need for lock. Not read-modify-write updates. */
> - bs.hard_limit = ~0UL;
> bs.target_pages = max(target, minimum_target());
> schedule_work(&balloon_worker);
> }
> @@ -498,17 +483,11 @@
> "Requested target: %8lu kB\n"
> "Low-mem balloon: %8lu kB\n"
> "High-mem balloon: %8lu kB\n"
> - "Driver pages: %8lu kB\n"
> - "Xen hard limit: ",
> + "Driver pages: %8lu kB\n",
> PAGES2KB(bs.current_pages), PAGES2KB(bs.target_pages),
> PAGES2KB(bs.balloon_low), PAGES2KB(bs.balloon_high),
> PAGES2KB(bs.driver_pages));
>
> - if (bs.hard_limit != ~0UL)
> - len += sprintf(page + len, "%8lu kB\n",
> - PAGES2KB(bs.hard_limit));
> - else
> - len += sprintf(page + len, " ??? kB\n");
>
> *eof = 1;
> return len;
> @@ -539,7 +518,6 @@
> bs.balloon_low = 0;
> bs.balloon_high = 0;
> bs.driver_pages = 0UL;
> - bs.hard_limit = ~0UL;
>
> init_timer(&balloon_timer);
> balloon_timer.data = 0;
> diff -r fd9c565657b8 drivers/xen/balloon/common.h
> --- a/drivers/xen/balloon/common.h Thu Jun 04 16:26:49 2009 +0100
> +++ b/drivers/xen/balloon/common.h Fri Jun 05 11:56:22 2009 +0100
> @@ -35,8 +35,6 @@
> /* We aim for 'current allocation' == 'target allocation'. */
> unsigned long current_pages;
> unsigned long target_pages;
> - /* We may hit the hard limit in Xen. If we do then we remember it. */
> - unsigned long hard_limit;
> /*
> * Drivers may alter the memory reservation independently, but they
> * must inform the balloon driver so we avoid hitting the hard limit.
> diff -r fd9c565657b8 drivers/xen/balloon/sysfs.c
> --- a/drivers/xen/balloon/sysfs.c Thu Jun 04 16:26:49 2009 +0100
> +++ b/drivers/xen/balloon/sysfs.c Fri Jun 05 11:56:22 2009 +0100
> @@ -53,9 +53,6 @@
> BALLOON_SHOW(current_kb, "%lu\n", PAGES2KB(bs.current_pages));
> BALLOON_SHOW(low_kb, "%lu\n", PAGES2KB(bs.balloon_low));
> BALLOON_SHOW(high_kb, "%lu\n", PAGES2KB(bs.balloon_high));
> -BALLOON_SHOW(hard_limit_kb,
> - (bs.hard_limit!=~0UL) ? "%lu\n" : "???\n",
> - (bs.hard_limit!=~0UL) ? PAGES2KB(bs.hard_limit) : 0);
> BALLOON_SHOW(driver_kb, "%lu\n", PAGES2KB(bs.driver_pages));
>
> static ssize_t show_target_kb(struct sys_device *dev, char *buf)
> @@ -96,7 +93,6 @@
> &attr_current_kb.attr,
> &attr_low_kb.attr,
> &attr_high_kb.attr,
> - &attr_hard_limit_kb.attr,
> &attr_driver_kb.attr,
> NULL
> };
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2009-06-05 13:28 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-06-05 13:28 AW: linux: try harder to balloon up under memory pressure Carsten Schiers
-- strict thread matches above, loose matches on Subject: below --
2009-06-05 12:41 Carsten Schiers
2009-06-05 13:02 ` Ian Campbell
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.