[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Proposed XENMEM_claim_pages hypercall: Analysis of problem and alternate solutions



On Tue, 2013-01-22 at 19:22 +0000, Dan Magenheimer wrote:
> > I don't mean that you'd have to do all of that now, but if you were
> > considering moving in that direction, an easy first step would be to add
> > a hook allowing tmem to veto allocations for VMs under its control.
> > That would let tmem have proper control over its client VMs (so it can
> > solve the delayed-failure race for you), while at the same time being a
> > constructive step towards a more complete memory scheduler.
> 
> While you are using different words, you are describing what
> tmem does today.  Tmem does have control and uses the existing
> hypervisor mechanisms and the existing hypervisor lock for memory
> allocation.  That's why it's so clean to solve the "delayed-failure
> race" using the same lock.
> 

So it sounds like it would easily be possible to solve this issue via a
tmem hook as Tim suggests?

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.