| |
|
 |
|
 |
|
|
|
| |
|
|
xen-users
RE: [Xen-users] Re: Memory resizing
> -----Original Message-----
> From: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
> [mailto:xen-users-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of
> Mark Williamson
> Sent: 16 October 2006 17:21
> To: xen-users@xxxxxxxxxxxxxxxxxxx
> Cc: Anthony Liguori; Jiri Denemark
> Subject: Re: [Xen-users] Re: Memory resizing
>
> > So the kernel still has 7800MB of memory, (7800-160)MBs
> eaten up by balloon
> > driver and 160MBs available to userspace, right? In that
> case, it seems
> > it's rather an issue of VM subsystem in Linux.
>
> Well, the kernel is probably thinking "Arrrg I've almost used
> all physical
> memory! Must free some now in case I run out!". Seems odd
> that it'd do that
> rather than swapping - but how much free physical memory did
> you have? Is it
> possible that with other tasks running too you'd run out (or
> quite low) of
> physical memory?
>
> The OOM killer is presumably worried that the kernel will run
> out of ram and
> not be able to use it for essential kernel data structures...
>
> The easy fix for you is probably to either remove the OOM
> killer (I think it's
> a compile-time option, and some people would like to see it removed
> completely) or to creat the domain smaller to start with.
>
> > I wonder if playing with altering kernel's swappiness would
> help in that...
> > I tried to make 8GB swap but that didn't help much.
>
> Hmmmm. Not sure, but I'd be more comfortable with reducing
> the "incentive" to
> the OOM killer in terms of physical memory set up, rather
> than trying to just
> increase swap and hope...
One way to (to some extent at least) avoid the OOM killer is to "echo 2
< /proc/sys/vm/overcommit_memory" as described in "man malloc" - it
means that applications and kernel isn't allowed to allocate memory that
isn't ACTUALLY there - so when an application happily says "give me
100MB of RAM", malloc checks to see if there REALLY is 100MB of RAM
before it says "Yes", whilst in the "normal" case, it says "Sure, here's
a block of memory that could be made into 100MB at some point". The
problem trying to be solved here is that many applications ask for a
huge amount of memory even if they don't need it [the app needs a 300
long and 300 wide array SOMETIMES, but most of the time, the app just
needs 300 in one direction and 4 in the other, so a lot of memory is not
ACTUALLY used]. So memory allocation is allowed to "Happy-go-lucky" and
"overspend".
--
Mats
>
> Good luck!
>
> Btw, this behaviour could be thought of as a bug (in that
> we're making Linux
> do silly things) so it'd be worth posting a bug on BugZilla
> and sending
> details to the xen-devel list - if you have time, that is.
>
> Cheers,
> Mark
>
> --
> Dave: Just a question. What use is a unicyle with no seat?
> And no pedals!
> Mark: To answer a question with a question: What use is a skateboard?
> Dave: Skateboards have wheels.
> Mark: My wheel has a wheel!
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-users
>
>
>
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
|
|
| |
|
Home