[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Ownership of machine pages: Was: [Xen-devel] Essay on an important Xen decision (long)
> Date: Wed, 11 Jan 2006 15:56:43 +0800 > From: "Tian, Kevin" <kevin.tian@xxxxxxxxx> > Subject: RE: [Xen-devel] Essay on an important Xen decision (long) > To: "Magenheimer, Dan \(HP Labs Fort Collins\)" > <dan.magenheimer@xxxxxx>, "xen-devel" > <xen-devel@xxxxxxxxxxxxxxxxxxx>, > <xen-ia64-devel@xxxxxxxxxxxxxxxxxxx> > > Hi, Dan, > Good background for discussion. For some reason, I only got this through xen-devel (which I only receive in digest form) so I couldn't respond directly. But this subtopic -- though highly related -- might deserve a new thread anyway. > I don't think it's a good design choice by complete takeover > to dom0. Moving ownership to dom0 doesn¡¯t mean a simple > move, since memory sub-system is the core/base of Xen Very true. But I expect Xen's memory subsystem will need to evolve considerably to handle things like: - support of different page sizes - cacheable vs uncacheable memory - sparsely populated memory - NUMA - hotplug memory - oversubscription - memory reserved for firmware Now might be a very good time to consider alternative approaches rather than try to hack these one at a time into the existing memory subsystem of core/base Xen. > Extra > context switches are added for any page related operation. Hmmm... not really. Page operations (such as alloc and free) are relatively rare and can be batched (e.g. at domain startup). And domU's are not going to be making policy decisions... If dom0 is making policy decisions (e.g. this stick of RAM is about to die, who do I steal memory from?), dom0 ownership of the pages may even reduce context switches. > Also by P==M model, how do you ensure a scalable allocation > environment after a long run? Any activities within dom0 > which consumes Physical frames, thus actually eats Machine > frames. Just like today's balloon driver, a "machine memory policy driver" would steal all but some fixed number of dom0's pages such that the dom0 kernel cannot use them for other purposes. Dan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |