On Tue, Aug 29, 2006 at 08:12:21PM -0400, Jed Davis wrote:
> Chuck Cranor <chuck@ece.cmu.edu> writes:
> 
> > that's a bug in the !VM_PHYSSEG_NOADD case.  but all ports 
> > define VM_PHYSSEG_NOADD because the "ADD" case was never completed.
> > (see the XXXCDC comment in uvm_page.c --- you need to update uvmexp
> > and somehow sync the pmap in order to do a uvm_page_physload() after
> > the VM has been inited.)
> >
> > that (incomplete) code is there because I was thinking about
> > the case where you have a memory board that you want to add
> > to the VM at autoconfig time.  [must have been thinking about
> > mvme147 at the time...]
> 
> Xen, as I understand it, provides hot-pluggable memory -- arbitrary
> page-aligned parts of the pseudo-physical address space can be
> populated or released, provided that the total amount of machine
> memory used doesn't exceed the domain's current memory limit.

Yes, but the way it works in linux is that the kernel thinks
it has the maximum amount of RAM, and a special driver ("baloon")
will malloc() memory and give it back to Xen to release memory
(or get back memory from Xen and free() it). Would be nice if we could
dynamically change the size of mamaged memory in UVM instead.

-- 
Manuel Bouyer, LIP6, Universite Paris VI.           Manuel.Bouyer@lip6.fr
     NetBSD: 26 ans d'experience feront toujours la difference
--