[uml-devel] Re: [uml-user] Network lags

["David Cannings" <lists@edeca.net>]

> >I like the sound of the more dynamic memory arrangement and manager
daemon for
> >UMLs, sounds like a good way to squeeze more customers onto a host
machine.
> >But if for the moment the only thing it should do is to keep the host
from
> >swapping, I know from a few our customers that mlocking has given more
> >predictable behaviour from guest kernels, especially if the host load
spikes
> >for a few minutes.

mlocking would have the effect of being able to "squeeze" less customers
onto a physical machine.  Without mlocking, pages can be swapped out of
memory onto disk thus your available memory is limited only by whatever size
swap partition you can afford.  This way, even if you only have 256MB
physical memory you can run ten UMLs with 64MB each, as an untested example
figure.  If you mlock those 64MB for each UML you can only physically run
four, not including space for host kernel and user space memory.  Obviously
there are huge performance penalties by constantly swapping out pages so
more physical memory or faster swap do help.

> >Anyone else who's running lots of UMLs with interactive sessions may have
> >noticed the following symptoms which this patch cures:
> >
> >   * irregular ping times to UMLs-- huge delay for the first ping, a few
> >       normal, a couple of long delays etc.;

The huge delay is often related to ARP, a fundamental part of 802.3/true
ethernet.

> as far as i remember this problems have been reported repeatedly - so all
users who experience
> weird uml lags could probably fix their problem just by activating that
option.

The problem with "just activating that option" is that many people will do
it blindly, unaware of the serious implications it could have to their host.
Whilst mlocking an area of memory may not affect you now, or in the next ten
minutes, it could cause trouble in three weeks when you start doing
something on the host that is memory intensive.  In the last three years of
running a remote server I have only had to turn up on site to fix it twice.
Both were very silly things, one that I'd "just activated" to see what it
would do.  It cost me a rather expensive journey half way across the country
to fix.

> furthermore inclusion
> of the patch would "honour" the work of the person, who did that patch.
personally, i find such thing
> important for an opensource project, because it is some form of
"encouragement" to develop patches and
> giving credits to others. :)

It is definitely good to see a community working on patches for a project
but it must be recognised that the end result should be a professional,
stable and reliable product.  I am sure nobody has any problem with people
posting patches on their own sites or on the mailing list to allow people to
carry out certain tasks but modifications that contain potentially unstable
code should, in my opinion, be left out of a mainstream release.  Note that
I speak for myself here, not UML or Jeff Dike.

> >It can put the host at risk.
> i think someone who runs a uml KNOWS what he does - and is able to
calculate the amount of ram on his host
> and reserve free ram for i/o buffering or whatelse....

The idea behind UML is to create a separate environment from the host,
constructing a UML kernel that can interfere so badly with the host is the
total opposite.

> furthermore - that patch doesn`t seem to be such "big issue" because it`s
just some lines of code being changed
> in uml.....

That statement is asinine.  I could just change "some lines" in my shell
scripts to read "rm -rf /" instead.  Is that not a big issue?  I do not
understand kernel design very well at all but changing "some lines" of
source can have serious implications.

I agree with Jeff, mlocking is bad.

David



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel