Carsten Schiers
2009-Jun-05 12:41 UTC
AW: [Xen-devel] linux: try harder to balloon up under memory pressure.
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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Ian Campbell
2009-Jun-05 13:02 UTC
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_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Carsten Schiers
2009-Jun-05 13:28 UTC
AW: [Xen-devel] linux: try harder to balloon up under memory pressure.
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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel