Re: Re: memory dispatch

[Joel CARNAT <joel%carnat.net@localhost>]

Dans l'épisode précédent (Thu, Jan 05 2006 - 21:10), Manuel Bouyer nous 
apprenait que :
> On Thu, Jan 05, 2006 at 06:32:30PM +0100, Joel CARNAT wrote:
> > Hi,
> > 
> > I remember a discussion about how to give bits of physical RAM with Xen
> > 1.2 but just can't find the thread archive... Now I have Xen2 and can't
> > find the answer to :
> > 
> > What is the best way when dealing with RAM (NetBSD 3.0 / Xen 2.0.7) ?
> > 1. Give all the RAM to dom0 (via grub's dom0_mem) ? And then domU will
> > herirate from it (from "memory" option).
> 
> Hum, this may require a working 'baloon' driver, which is not there in
> NetBSD yet.
> 

ok

> > 
> > 2. Give the minimum to dom0 (let say 64Mo) ? And then use domU's memory
> > option.
> > 
> > I'm wondering this because compiling net/wget in NetBSD/dom1 seems slow
> > (NetBSD/dom0 has 64M and NetBSD/dom1 has 128 ; /usr/pkgsrc being NFS
> > exported from dom0 to dom1). So maybe 64M for dom0 is a bit little and
> > it would be nice if dom0 could handle all the RAM and dispatch it to the
> > domUs.
> 
> Run systat vm on both domains, and see if one of them has pagein/pageout
> activity.
> 

there are (a few - less than 10 of each when compiling cyrus-imapd and
deps) on dom0. I tried changing memory for dom0. Giving dom0 256Mo makes
pagein/pageout not appear but compilation don't seem faster (compared to
my P4 w/512Mo workstation on a UDMA 100 disk).

what's "funny" is that dom0 has a load of 1.5 where dom1 is only 0.73.
I suppose this shows NFS impact on CPU (disks are Ultra320 SCSI).
NFS also might explain the slowlyness of the compilation process.