Re: [Xen-devel] is paging_new_log_dirty_page alloc page harmfull?

[Tim Deegan <Tim.Deegan@xxxxxxxxxx>]

At 03:41 +0000 on 07 Mar (1299469316), MaoXiaoyun wrote:
> Thanks Tim.
>
> Do you have suggestion on how many memory I should reserved, is 512M
> enough?  There is a balloon daemon process in dom0 do the memory
> management, the striaght way to reserve memory is after recycle memory
> form domains which no need memory , then give the memory to those
> domains who need memory. What do you think of this?

Maybe the people who have been working on the toolstack can answer this
one - 512MiB free sounds like more than enough to me but I could be
wrong. 

Tim.

> > Date: Fri, 4 Mar 2011 11:16:59 +0000
> > From: Tim.Deegan@xxxxxxxxxx
> > To: tinnycloud@xxxxxxxxxxx
> > CC: xen-devel@xxxxxxxxxxxxxxxxxxx
> > Subject: Re: [Xen-devel] is paging_new_log_dirty_page alloc page harmfull?
> >
> > At 11:11 +0000 on 04 Mar (1299237101), MaoXiaoyun wrote:
> > > Hi:
> > >
> > > I've been testing on memory overcommit on Xen by using balloon driver.
> > > On our stress test, it is possilbe that heap memory in xen is use up. 
> > > Thus the serial
> > > port will show log as below:
> > >
> > > (XEN) paging_log_dirty_range: 138 failed page allocs while logging dirty 
> > > pages
> > > (XEN) paging_log_dirty_range: 138 failed page allocs while logging dirty 
> > > pages
> > > (XEN) paging_log_dirty_range: 138 failed page allocs while logging dirty 
> > > pages
> > >
> > > I am asking is it harmfull to domain?
> >
> > It means that the log-dirty code wasn't able to extend its bitmap and
> > callers have to assume that all pages are dirty. It's bad for
> > performance but should be OK.
> >
> > If you rebase to the latest 4.1 RC, this particular message should go
> > away as log-dirty bitmaps are no longer pulled from common memory.
> >
> > > If so, I might need find a way to reserve some memory for xen, which looks
> > > kinds of difficult.
> >
> > I think you might find you need to do this anyway - there are other
> > dynamic allocations in Xen which might not fail so gracefully (in
> > particular around setting up new domains).
> >
> > Tim.
> >
> > --
> > Tim Deegan <Tim.Deegan@xxxxxxxxxx>
> > Principal Software Engineer, Xen Platform Team
> > Citrix Systems UK Ltd. (Company #02937203, SL9 0BG)

-- 
Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Principal Software Engineer, Xen Platform Team
Citrix Systems UK Ltd.  (Company #02937203, SL9 0BG)

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel