Tim has already answered some of your questions, let me fill in the gaps.
> I assume you are posting this offlist discussion for
> participation and feedback. You moved quickly from
> claiming a vague need into very specific mechanisms,
> so pardon me if I need to take a step back. The
> page sharing code was added very quickly to xen-unstable
> last year without (afaict) much review or iteration,
> so there's probably other developers that could use some
> additional background. I appreciate that you are
> moving this phase into open discussion!
The code got dropped into Xen quite quickly (partly) because I was
leaving Citrix, and therefore we wanted to make the code available,
before I was gone. While I cannot work on it full time any more, I
want to contribute some of my time to the project, to make it more
usable, document it and to smoothen out the rough endges.
> I gather the 'OOM event' occurs when a guest tries to write
> to memory on a page that it thinks it owns, but the page
> is actually transparently shared. As a result, the
> write must fail and instead some hypervisor swapping
> activity must occur, apparently driven by a userland
> process in dom0 to some swap disks that are configured
> and owned by dom0? If this is correct, why is it
> necessary for address/sub-page/translation information
> to be included in the event... it is likely that it
> won't be this specific page that is swapped out,
> correct?
To reiterate Tim's point. The mem-event interface is supposed to be
general enough to send a bunch of different memory management events
through. OOM events are about particular domains, and not about
specific frames/pages. Similarly, sub-page access events should albo
be supported.
> I'm not clear on why/when the "handle invalidate" event
> might occur. Could you explain more?
This is specific to memory sharing, it means that a particular memory
frame (represented by an opaque sharing handle) is no longer sharable.
> I still have to raise a general objection to hypervisor
> swapping in any real world workload. The VMware users I've
> talked to hate it and turn off page sharing because of it.
> While there are definitely some workloads where page
> sharing can have a huge advantage (essentially by being so
> homogeneous and "static" across many guests as to avoid
> any swapping), it is not widely used because of swapping.
I guess this is out of scope of this particular email thread. But to
shed some light on it, the extra memory gained through sharing can be
used in several different ways. Some of them will require the
safeguards against OOM, which implies paging. In my view, the paging
functionality should be supported, and the tools should implement a
policy which provides best performance+predictability.
> I had vaguely thought you had managed to avoid the worst
> of the swapping problems but I don't recall why/how...
> and I had thought that any swapping that did exist was
> solved by the page sharing code as submitted, but
> never had a chance to dig deeper.
My approach relies on PV domains, or at least virtualisation aware
memory management. The current memory sharing code concentrates on HVM
domains though. The long term goal is definitely to optimise the
VM-hypervisor memory management as much as possible.
Thanks
Gregor
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home