| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
[Xen-devel] RE: xl features missing
> > > > - xl create doesn't handle the possibility that tmem
> > > > has memory which is freeable (xm create does)
> > >
> > > This appears to be an indicator of a bigger issue unless
> > > there is some code somewhere I am missing.
> > >
> > > Can "xl create" deal with ballooning memory from dom0, as is
> > > done in the free() method in tools/python/xen/xend/balloon.py?
> > > If not, doesn't that mean that xl is useless on systems
> > > where dom0_mem= isn't specified as a boot option?
> > >
> > > Since tmem leverages this method to recover freeable
> > > memory when creating a new guest, tmem also needs this
> > > else xl is also useless on a tmem-enabled system.
> > >
> > > And in either case, it appears that the error handling
> > > for "out of memory" spews meaningless error messages.
> >
> > xl doesn't have an equivalent of the free() method in xend, so it
> > would be useless without dom0_mem= at the moment.
> > However reimplementing that method shouldn't be hard, the only problem
> > is that it would probably require some sort of global locking among
> > all the various xl processes running concurrently.
> > Maybe we need a lockfile?
>
> Another possible course of action would be to implement a libxl funtion
> that calculates the amount of memory that needs to be freed, then call
> a new libxl funtion similar to libxl_set_memory_target but that would
> take a relative amount of memory as argument and would also be "tmem
> enabled".
> Finally the actual implementation of this function must communicate
> relative amounts of memory to the kernel so that we can avoid the
> global lock. Does that make sense?
What xl processes are racy for obtaining memory? Is it possible
that multiple xl processes are doing an "xl create" at the same time?
I'm not sure I understand completely, but one possible issue is
that the function that asks "is there enough memory?" must not
actually tell tmem to surrender the memory. Also, tmem has
a "freeze/thaw" mechanism to ensure additional memory isn't
asynchronously absorbed (search for the instances of "tmem"
in balloon.py to see this code) and they must always be paired,
e.g. a freeze without a thaw is disastrous for tmem.
Note that other dynamic memory mechanisms (even plain ballooning)
don't have this freeze/thaw capability so there
is always the potential for races, e.g. for
- Is there enough memory for a 1G domain?
- Yes, it appears there is enough so I will proceed
- Create the domain with 1G of memory
the last step must be allowed to fail gracefully (preferably
with a decent error message).
Ideally, this should be solved by a lock in the hypervisor but
as long as dom0 ballooning exists (which is by its nature
asynchronous), I'm not sure this is possible.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home