At 00:12 +0100 on 24 Jun (1277338337), Dan Magenheimer wrote:
> 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?
It would be nice to use the same 'memory event' interface for other
things (like out-of-domain virus scanners and other security stuff) that
might want to operate on sub-page areas. I think it's a good idea to
put that in the interface now even if the initial users (sharing and
swapping) only operate on pages.
So though in this case the address information isn't very useful, in
general it lets us punt policy decisions into the tools, which I like.
> I'm not clear on why/when the "handle invalidate" event
> might occur. Could you explain more?
>
> 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.
Agreed - but there should be more, and more useful, clients of the same
interface.
> 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 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. I gather I was
> wrong and this discussion is the next step toward making
> page sharing functional in real world corner cases?
> (I have had questions about page sharing in 4.0 and
> have said, basically, I don't know and, since we are
> not shipping a 4.0-based hypervisor yet, we will
> have to wait and see.)
>
> Thanks,
> Dan
>
> > -----Original Message-----
> > From: Grzegorz Milos [mailto:grzegorz.milos@xxxxxxxxx]
> > Sent: Wednesday, June 23, 2010 4:19 PM
> > To: Xen-Devel (E-mail); george.dunlap@xxxxxxxxxxxxx; Andrew Peace;
> > Steven Hand; Patrick Colp; Bryan D. Payne
> > Subject: [Xen-devel] Re: mem-event interface
> >
> > [From Gregor]
> >
> > There are two major events that the memory sharing code needs to
> > communicate over the hypervisor/userspace boundary:
> > 1. GFN unsharing failed due to lack of memory. This will be called the
> > 'OOM event' from now on.
> > 2. MFN is no longer sharable (actually an opaque sharing handle would
> > be communicated instead of the MFN). 'Handle invalidate event' from
> > now on.
> >
> > The requirements on the OOM event are relatively similar to the
> > page-in event. The way this should operate is that the faulting VCPU
> > is paused, and the pager is requested to free up some memory. When it
> > does so, it should generate an appropriate response, and wake up the
> > VCPU back again using a domctl. The event is going to be low volume,
> > and since it is going to be handled synchronously, likely in tens of
> > ms, there are no particular requirements on the efficiency.
> >
> > Handle invalidate event type is less important in the short term
> > because the userspace sharing daemon is designed to be resilient to
> > unfresh sharing state. However, if it is missing it will make the
> > sharing progressively less effective as time goes on. The idea is that
> > the hypervisor communicates which sharing handles are no longer valid,
> > such that the sharing daemon only attempts to share pages in the
> > correct state. This would be relatively high volume event, but it
> > doesn't need to be accurate (i.e. events can be dropped if they are
> > not consumed quickly enough). As such this event should be batch
> > delivered, in an asynchronous fashion.
> >
> > The OOM event is coded up in Xen, but it will not be consumed properly
> > in the pager. If I remember correctly, I didn't want to interfere with
> > the page-in events because the event interface assumed that mem-event
> > responses are inserted onto the ring in precisely the same order as
> > the requests. This may not be the case when we start mixing different
> > event types. WRT to the handle invalidation, the relevant hooks exist
> > in Xen, and in the mem sharing daemon, but there is no way to
> > communicate events to two different consumers atm.
> >
> > Since the requirements on the two different sharing event types are
> > substantially different, I think it may be easier if separate channels
> > (i.e. separate rings) were used to transfer them. This would also fix
> > the multiple consumers issue relatively easily. Of course you may know
> > of some other mem events that wouldn't fit in that scheme.
> >
> > I remember that there was someone working on an external anti-virus
> > software, which prompted the whole mem-event work. I don't remember
> > his/hers name or affiliation (could you remind me?), but maybe he/she
> > would be interested in working on some of this?
> >
> > Thanks
> > Gregor
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@xxxxxxxxxxxxxxxxxxx
> > http://lists.xensource.com/xen-devel
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
--
Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Principal Software Engineer, XenServer Engineering
Citrix Systems UK Ltd. (Company #02937203, SL9 0BG)
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home