user-mode-linux-user

user@... said:
> my assumption has always been that when I run a UML instance on my
> computer (or two or three) that swapping, if it is needed, will be taken
> care of by the underlying machine
If the host needs to swap, it will swap out UMLs if it decides they need
to go.
> So the question is, am I correct ?
Basically, yess.
> Does my UML instance (and the
> other two running on the same machine) have swap, or do I have to
> explicitly define internal UML swap for each of them ?
It will swap if it's short of memory even if you don't configure swap for it.
It will drop clean pages (i.e. code) which are known to be in sync with their
backing store (the binary on disk in the case of code).
If you configure swap, it will obviously use it for dirty pages as well.
a.phillips@... said:
> It would seem to me that (as with vmware) you would give the uml as
> much memory as you think it would need but no swap and let the host
> linux handle the swapping issues.
That's the normal way of doing it. The host has the global view of things,
so it makes sense to let it handle swapping.
> On the other hand, perhaps in some
> situations giving UML access to a raw device for swapping would be
> better ?
Giving a UML access to a raw device for swap has some advantages. It can
swap without loading the host's memory with dirty pages. But you can't give
an arbitrary number of UMLs their own raw swap devices like you can give them
files to swap in.
A better case where you'd want to limit the memory a UML has is when you
want to limit its resource consumption for some reason. If you're running
a virtual colo, you probably want to limit the total host memory each
customer's UML is allowed to have, so if one runs wild, it starts swapping
itself to death rather than taking the host's and the other UML's performance
down the drain.
Another case is if you've isolated a bunch of services in their own UMLs.
You give each one more memory than you think it should ever need. And if
it runs wild somehow, it hurts itself rather than the host.
> I don't know how this would work with caching though, presumably you
> would want to sync in the uml relatively often so that the host can
> sync the uml's file(s) otherwise you'll have files in the uml's
> filesystem taking up to twice as long to sync to disk. For some reason
> I though there was an option to do syncing in uml but I can't find it
> now or perhaps it just mentioned mounting with sync in the uml ?
Stick a 's' on the ubd argument, i.e. 'ubd0s=/path/to/root'. That will
make disk IO O_SYNC. It will not prevent the UML caching.
There's been some discussion of avoiding the double caching of data. The
best suggestion that will work now (for recent-enough host kernels) is
for the ubd driver to use O_DIRECT to its files. That will avoid caching
on the host.
Further out, and probably the best idea, is to allow the ubd driver to mmap
its files. This would let the host and UML share page caches, giving everyone
the benefit of caching without multiple caching.
> It would be good to get some "tuning" points in the HOWTO by the way;
> I'd be certainly willing to write something (in plain text at least)
> about swap if we can clarify what is deemed sensible.
That would be great. The stuff on the site is under the FDL, so your additions
would have to be released under the FDL as well.
Howard@... said:
> 1) Is memory allocated to a UML locked out from the host?
> ex. If you run UML with mem=512M option and the UML is just running
> an ftp server how much memory will the UML allocate
It will allocate memory on demand up to the 512M. Your little ftp server
won't actually use anywhere near 512M.
> 2) If you have several UML's on a host would it be preferable to
> prevent one UML from taking too much memory?
> ex. Host has 1GB and you have four UML's
> -- If each UML is run with mem=512M it seems that two of the
> machines could hog all of the memory from the host and starve the
> other two machines and the host as well.
If two of them use 512M, and a third starts up, then the host will start
swapping out pieces of the two hogs to make room for it.
> -- If you instead configured each UML with mem=200M and a 300M
> swap file, it seems each of the machines would always be guaranteed
> it's 200M and the host would always be left with at least 200M.
Yes.
> 3) Is it a good idea to tell a machine it has "fast" memory (aka.
> RAM) when in fact it has "slow" memory (aka. Disk)?
> Does the following make sense or am I missing something?
> -- Linux seems to like to use all available "extra" memory for
> disk cache so I would suspect that over time, a UML would end up
> trying to use all of the RAM it thinks it has as disk cache.
This is a problem. There's been some discussion of this on the kernel list
over the last few days. It's also a problem for Linux/s390.
> If this
> "RAM Cache" is in-fact swapped out to the host's hard drive, then it
> seems like you would be hurting your disk performance in the UML.
> When it read a sector from the ubd device and attempted to cache it
> it would trigger a disk write on the host.
This too. What we want (and don't have) is a way to say to the host
"free these pages without swapping them if you have to, but if you do,
let me know when I access them".
> -- I think I am assuming that a kernel (UML or otherwise) is
> smart enough to not try to use swap memory to cache hard drive
> information but a UML would not be able to know if using what it had
> been told was RAM would actually cause a memory swap to disk.
Yup.
a.phillips@... said:
> This seems like something for the HOWTO : "Configuring memory needs
> for your UMLs"
OK, write it up and send it in...
Jeff

Community

Help

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

CountryState

JavaScript is required for this form.

I agree to receive quotes, newsletters and other information from sourceforge.net and its partners regarding IT services and products. I understand that I can withdraw my consent at any time. Please refer to our Privacy Policy or Contact Us for more details