On Sat, Nov 27, 2010 at 02:54:46PM +0800, cloudroot wrote:
> Hi Dan:
>
>
>
> I have set the benchmark to test balloon driver, but
> unfortunately the Xen crashed on memory Panic.
>
> Before I attach the details output from serial port(which takes
> time on next run), I am afraid of I might miss something on test
> environment.
>
>
>
> My dom0 kernel is 2.6.31, pvops.
>
You should switch to 2.6.32 based dom0 kernel.
2.6.31 tree is not supported or maintained anymore.
So switch to xen/stable-2.6.32.x branch in Jeremy's git tree.
Other than that.. I haven't tried ballooning with HVM guests,
so I'm not sure if that should work with the EL5 kernel.
-- Pasi
> Well currently there is no driver/xen/balloon.c on this kernel source
> tree, so I build the xen-balloon.ko, Xen-platform-pci.ko form
>
> linux-2.6.18.x86_64, and installed in Dom U, which is redhat 5.4.
>
>
>
> What I did is put a C program in the each Dom U(total 24 HVM),
> the program will allocate the memory and fill it with random string
> repeatly.
>
> And in dom0, a phthon monitor will collect the meminfo from
> xenstore and calculate the target to balloon from Committed_AS.
>
> The panic happens when the program is running in just one Dom.
>
>
>
> I am writing to ask whether my balloon driver is out of date, or
> where can I get the latest source code,
>
> I've googled a lot, but still have a lot of confusion on those
> source tree.
>
>
>
> Many thanks.
>
>
>
>
>
> From: tinnycloud [mailto:tinnycloud@xxxxxxxxxxx]
> Date: 2010.11.23 22:58
> TO: 'Dan Magenheimer'; 'xen devel'
> CC: 'george.dunlap@xxxxxxxxxxxxx'
> Subject: re: Xen balloon driver discuss
>
>
>
> HI Dan:
>
>
>
> Appreciate for your presentation in summarizing the memory
> overcommit, really vivid and in great help.
>
> Well, I guess recently days the strategy in my mind will fall
> into the solution Set C in pdf.
>
>
>
> The tmem solution your worked out for memory overcommit is both
> efficient and effective.
>
> I guess I will have a try on Linux Guest.
>
>
>
> The real situation I have is most of the running VMs on host are
> windows. So I had to come up those policies to balance the memory.
>
> Although policies are all workload dependent. Good news is host
> workload is configurable, and not very heavy
>
> So I will try to figure out some favorable policy. The policies referred
> in pdf are good start for me.
>
>
>
> Today, instead of trying to implement "/proc/meminfo" with shared
> pages, I hacked the balloon driver to have another
>
> workqueue periodically write meminfo into xenstore through
> xenbus, which solve the problem of xenstrore high CPU
>
> utilization problem.
>
>
>
> Later I will try to google more on how Citrix does.
>
> Thanks for your help, or do you have any better idea for windows
> guest?
>
>
>
>
>
> Sent: Dan Magenheimer [mailto:dan.magenheimer@xxxxxxxxxx]
> Date: 2010.11.23 1:47
> To: MaoXiaoyun; xen devel
> CC: george.dunlap@xxxxxxxxxxxxx
> Subject: RE: Xen balloon driver discuss
>
>
>
> Xenstore IS slow and you could improve xenballoond performance by only
> sending the single CommittedAS value from xenballoond in domU to dom0
> instead of all of /proc/meminfo. But you are making an assumption that
> getting memory utilization information from domU to dom0 FASTER (e.g. with
> a shared page) will provide better ballooning results. I have not found
> this to be the case, which is what led to my investigation into
> self-ballooning, which led to Transcendent Memory. See the 2010 Xen
> Summit for more information.
>
>
>
> In your last paragraph below "Regards balloon strategy", the problem is it
> is not easy to define "enough memory" and "shortage of memory" within any
> guest and almost impossible to define it and effectively load balance
> across many guests. See my Linux Plumber's Conference presentation (with
> complete speaker notes) here:
>
>
>
>
> [1]http://oss.oracle.com/projects/tmem/dist/documentation/presentations/MemMgmtVirtEnv-LPC2010-Final.pdf
>
>
>
>
> [2]http://oss.oracle.com/projects/tmem/dist/documentation/presentations/MemMgmtVirtEnv-LPC2010-SpkNotes.pdf
>
>
>
> From: MaoXiaoyun [mailto:tinnycloud@xxxxxxxxxxx]
> Sent: Sunday, November 21, 2010 9:33 PM
> To: xen devel
> Cc: Dan Magenheimer; george.dunlap@xxxxxxxxxxxxx
> Subject: RE: Xen balloon driver discuss
>
>
>
>
> Since currently /cpu/meminfo is sent to domain 0 via xenstore, which in my
> opinoin is slow.
> What I want to do is: there is a shared page between domU and dom0, and
> domU periodically
> update the meminfo into the page, while on the other side dom0 retrive the
> updated data for
> caculating the target, which is used by guest for balloning.
>
> The problem I met is, currently I don't know how to implement a shared
> page between
> dom0 and domU.
> Would it like dom 0 alloc a unbound event and wait guest to connect, and
> transfer date through
> grant table?
> Or someone has more efficient way?
> many thanks.
>
> > From: tinnycloud@xxxxxxxxxxx
> > To: xen-devel@xxxxxxxxxxxxxxxxxxx
> > CC: dan.magenheimer@xxxxxxxxxx; George.Dunlap@xxxxxxxxxxxxx
> > Subject: Xen balloon driver discuss
> > Date: Sun, 21 Nov 2010 14:26:01 +0800
> >
> > Hi:
> > Greeting first.
> >
> > I was trying to run about 24 HVMS (currently only Linux, later will
> > involve Windows) on one physical server with 24GB memory, 16CPUs.
> > Each VM is configured with 2GB memory, and I reserved 8GB memory for
> > dom0.
> > For safety reason, only domain U's memory is allowed to balloon.
> >
> > Inside domain U, I used xenballooned provide by xensource,
> > periodically write /proc/meminfo into xenstore in dom
> > 0(/local/domain/did/memory/meminfo).
> > And in domain 0, I wrote a python script to read the meminfo, like
> > xen provided strategy, use Committed_AS to calculate the domain U
> balloon
> > target.
> > The time interval is ! 1 seconds.
> >
> > Inside each VM, I setup a apache server for test. Well, I'd
> > like to say the result is not so good.
> > It appears that too much read/write on xenstore, when I give some of
> > the stress(by using ab) to guest domains,
> > the CPU usage of xenstore is up to 100%. Thus the monitor running in
> > dom0 also response quite slowly.
> > Also, in ab test, the Committed_AS grows very fast, reach to maxmem
> > in short time, but in fact the only a small amount
> > of memory guest really need, so I guess there should be some more to
> > be taken into consideration for ballooning.
> >
> > For xenstore issue, I first plan to wrote a C program inside domain
> > U to replace xenballoond to see whether the situation
> > will be refined. If not, how about set up event channel directly for
> > domU and dom0, would it be faster?
> >
> > Regards balloon strategy, I would do like this, when there ! are
> > enough memory , just fulfill the guest balloon request, and when
> shortage
> > of memory, distribute memory evenly on the guests those request
> > inflation.
> >
> > Does anyone have better suggestion, thanks in advance.
> >
>
> References
>
> Visible links
> 1.
> http://oss.oracle.com/projects/tmem/dist/documentation/presentations/MemMgmtVirtEnv-LPC2010-Final.pdf
> 2.
> http://oss.oracle.com/projects/tmem/dist/documentation/presentations/MemMgmtVirtEnv-LPC2010-SpkNotes.pdf
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home