From: Vasiliy G Tolstov <v.tolstov@selfip.ru>
To: Dan Magenheimer <dan.magenheimer@oracle.com>
Cc: xen-devel@lists.xensource.com, Daniel Kiper <dkiper@net-space.pl>
Subject: RE: failed to start centos 5 domU with maxmem=30000
Date: Fri, 13 Aug 2010 09:56:11 +0400 [thread overview]
Message-ID: <1281678971.9689.7.camel@vase.work> (raw)
In-Reply-To: <7aace8e6-6878-40cb-8ed3-e66cf0e90ce1@default>
В Чтв, 12/08/2010 в 11:00 -0700, Dan Magenheimer пишет:
> > > > Why this is not provided in documentation or on web site?
> > >
> > > Hi Vasily --
> > >
> > > This function limits how far memory can be reduced when
> > > ballooning a guest (including dom0). It is only a heuristic
> > > but is intended to take into account the various overheads
> > > a guest Linux kernel requires to manage memory to avoid
> > > out-of-memory conditions.
> > >
> > > But I think you are correct... the same (or similar)
> > > function should be published as it also serves as a
> > > guideline for the ratio between memory= and maxmem=
> > > parameters when creating a guest: If the ratio
> > > of maxmem divided by memory is too high, the guest
> > > will not even boot.
> >
> > Is that possible to use memory=32 and maxmem=60000 ?
>
> I think the answer is no. I believe there is a kernel
> data structure for each 4K page in physical memory
> I don't remember the size of this data structure, but
> assume it is 4 bytes. That means that for 1GB of
> physical memory (as specified by maxmem) this data
> structure requires 1MB of physical memory just to track
> the 1GB. So for your maxmem=60000, memory=60 would
> only be enough for this one kernel data structure (and
> the kernel requires many other data structures to
> be functional).
>
Ok. Thank's.
> Daniel Kiper is developing virtual hotplug memory for Xen
> guests. This may be a good use case for it.
>
I'm try for my systems. Thank's
> > > I am curious as to why you would specify memory= so
> > > much smaller than maxmem=. Are you trying to overcommit
> > > memory for guests that are often idle but sometimes use
> > > a very large amount of memory?
> >
> > We want to provide ability to use small as possible memory if the guest
> > is idle. And much as possible when the guest under heavy load.
>
> This is a much harder problem than it seems. You may want
> to look at some of the presentations on Transcendent Memory
> that explain why it is hard. (Most can be found at
> http://oss.oracle.com/projects/tmem )
Need to support in domU... this is bad. But i'm try it.
--
Vasiliy G Tolstov <v.tolstov@selfip.ru>
Selfip.Ru
next prev parent reply other threads:[~2010-08-13 5:56 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-12 10:24 failed to start centos 5 domU with maxmem=30000 Vasiliy G Tolstov
2010-08-12 11:37 ` Pasi Kärkkäinen
2010-08-12 11:37 ` Vasiliy G Tolstov
2010-08-12 12:17 ` Dan Magenheimer
2010-08-12 12:24 ` Vasiliy G Tolstov
2010-08-12 18:00 ` Dan Magenheimer
2010-08-13 5:56 ` Vasiliy G Tolstov [this message]
2010-08-12 18:34 ` Jeremy Fitzhardinge
2010-08-13 5:54 ` Vasiliy G Tolstov
2010-08-13 15:19 ` Dan Magenheimer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1281678971.9689.7.camel@vase.work \
--to=v.tolstov@selfip.ru \
--cc=dan.magenheimer@oracle.com \
--cc=dkiper@net-space.pl \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).