I have been using Xen on a daily basis on a production (but not critical) machine for a number of months now. It''s looking really good. One thing that I have not yet seen anyone mention as a feature that I would really like to see is the ability to overcommit memory. I have 2G of RAM in my machine. I would like to give a developer his own virtual domain to sandbox his application development without having to dedicate a whole piece of hardware to just him. But I know he won''t really log in and use it all that often. If I give him 512M of my 2G that''s 25% of my memory that will likely be unutilized most of the time. It would be great if I could assign more memory to domains than I actually have and just let it swap out idle pages. I bet there are a lot of boxes out there, especially in webserver colo''s, that really don''t get much traffic and really don''t need as much RAM as they have in them for normal day to day operations. Just let them swap everything back in and use up to the maximum RAM configured for that domain if they get busy and need it but let it swap out the rest of the time so other busier domains can use the physical RAM. This is feature #1 on my Xen wishlist. Is there any work going into this area? -- Tracy R Reed http://copilotconsulting.com 1-877-MY-COPILOT _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
The balloon driver provides a mechanism for reducing a guest's memory allocation at run-time. At least in principle, it would not be difficult to write a small app that provided policy to slim down idle domUs. -Kip On 12/9/05, Tracy R Reed <treed@copilotconsulting.com> wrote:> > I have been using Xen on a daily basis on a production (but not > critical) machine for a number of months now. It's looking really good. > > One thing that I have not yet seen anyone mention as a feature that I > would really like to see is the ability to overcommit memory. I have 2G > of RAM in my machine. I would like to give a developer his own virtual > domain to sandbox his application development without having to dedicate > a whole piece of hardware to just him. But I know he won't really log in > and use it all that often. If I give him 512M of my 2G that's 25% of my > memory that will likely be unutilized most of the time. It would be > great if I could assign more memory to domains than I actually have and > just let it swap out idle pages. I bet there are a lot of boxes out > there, especially in webserver colo's, that really don't get much > traffic and really don't need as much RAM as they have in them for > normal day to day operations. Just let them swap everything back in and > use up to the maximum RAM configured for that domain if they get busy > and need it but let it swap out the rest of the time so other busier > domains can use the physical RAM. > > This is feature #1 on my Xen wishlist. Is there any work going into this > area? > > -- > Tracy R Reed > http://copilotconsulting.com > 1-877-MY-COPILOT > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Even better, if each domain is only used occasionally, then you could save them to disc and restore them on demand. Then they consume no memory when not in use. You could combine this with use of the balloon driver to implement an allocation policy for in-use domains (as Kip suggests) --- e.g., if X domains are active, each gets 1/X of available memory. -- Keir On 11 Dec 2005, at 02:00, Kip Macy wrote:> The balloon driver provides a mechanism for reducing a guest''s memory > allocation at run-time. At least in principle, it would not be > difficult to write a small app that provided policy to slim down idle > domUs. > > -Kip > > On 12/9/05, Tracy R Reed <treed@copilotconsulting.com > wrote: >> critical) machine for a number of months now. It''s looking really >> good. >> >> One thing that I have not yet seen anyone mention as a feature that I >> would really like to see is the ability to overcommit memory. I have >> 2G >> of RAM in my machine. I would like to give a developer his own virtual >> domain to sandbox his application development without having to >> dedicate >> a whole piece of hardware to just him. But I know he won''t really log >> in >> and use it all that often. If I give him 512M of my 2G that''s 25% of >> my >> memory that will likely be unutilized most of the time. It would be >> great if I could assign more memory to domains than I actually have >> and >> just let it swap out idle pages. I bet there are a lot of boxes out >> there, especially in webserver colo''s, that really don''t get much >> traffic and really don''t need as much RAM as they have in them for >> normal day to day operations. Just let them swap everything back in >> and >> use up to the maximum RAM configured for that domain if they get busy >> and need it but let it swap out the rest of the time so other busier >> domains can use the physical RAM. >> >> This is feature #1 on my Xen wishlist. Is there any work going into >> this >> area? >> >> -- >> Tracy R Reed >> http://copilotconsulting.com >> 1-877-MY-COPILOT >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xensource.com >> http://lists.xensource.com/xen-devel > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Sun, 11 Dec 2005, Keir Fraser wrote:> Even better, if each domain is only used occasionally, then you could > save them to disc and restore them on demand.How would one implement such a "wake on LAN" functionality for Xen domains ?> You could combine this with use of the balloon driver to implement an > allocation policy for in-use domains (as Kip suggests)Better yet, balloon a domain down to something really small before swapping it out. Then the latency to get it running again when activity happens can be kept to a minimum. -- All Rights Reversed _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 11 Dec 2005, at 19:59, Rik van Riel wrote:>> Even better, if each domain is only used occasionally, then you could >> save them to disc and restore them on demand. > > How would one implement such a "wake on LAN" functionality > for Xen domains ?There are various ways. Maybe require explicit signalling from the user via some command to the control-plane tools (start up my domain / shut down my domain). You could also do it implicitly (although it may require some iptables hacking) by tracking network connections to the domain''s IP address -- start it up on first connection / shut it down when last connection finishes. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 12/13/05, Keir Fraser <Keir.Fraser@cl.cam.ac.uk> wrote:> > On 11 Dec 2005, at 19:59, Rik van Riel wrote: > > >> Even better, if each domain is only used occasionally, then you could > >> save them to disc and restore them on demand. > > > > How would one implement such a "wake on LAN" functionality > > for Xen domains ? > > There are various ways. Maybe require explicit signalling from the user > via some command to the control-plane tools (start up my domain / shut > down my domain). You could also do it implicitly (although it may > require some iptables hacking) by tracking network connections to the > domain''s IP address -- start it up on first connection / shut it down > when last connection finishes.Or you could use my self-checkpointing code to have the domain save itself, then free most of its pages, except for a small stub that would listen for some ''wake up'' event on the network interface (e.g. a TCP SYN packet). The stub could then allocate new pages and resume the checkpoint from disk. Jacob _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel