Re: [uml-devel] Re: [Lhms-devel] [PATCH 0/7] Fragmentation Avoidance V19

[Rob Landley <rob@landley.net>]

On Friday 04 November 2005 17:42, Blaisorblade wrote:
> > That's more configuration on the host that's not really needed.  Doesn't
> > do my case any good.
>
> We'll consider your case too then... for your job the daemon could be done
> by a thread started by UML on the host. The idea (still very preliminar)
> was conceived for hosting providers, to my knowlegde.

If I don't have to run it, I don't mind.  However, keep in mind I get runaway 
UML threads left after UML theoretically exits on a fairly regular basis.  
(Haven't banged on 2.6.14 so much, dunno if it still does that.)  Due to the 
fact the process's name has been replaced with random memory, I can't 
"killall" the bastards, I have to manually go in and track them down by hand, 
which sucks and can't be scripted.  Sometimes they're leftover stopped 
processes that I have to kill -CONT after I kill them to make them go away.  
(Personally, I consider that a kernel bug.  kill -9 will kill anything, 
except a stopped process...)

> > If we get prezeroing, the tunable is useful.  If we haven't got
> > prezeroing, this infrastructure probably won't get in.
>
> Hmm.... yep, prezeroing is useless if you don't keep some prezeroed memory,
> right.... I had answered too much in a hurry.
>
> Btw, indeed I previously planned to use the existing arch_free_pages() hook
> for page freeing, to call madvise() (conditionally I mean)... actually yes,
> you can't make sure that page isn't going to be reused, but if the page is
> _freed_ and you want still the content kept you will _anyway_ loose.
>
> The biggest risk is to madvise() a page uselessly, and that disturbs a bit
> performance, except that in general we should win by letting the host use
> more memory.

Another advantage of prezeroing: it maps really well to what we're trying to 
do here.  It makes a class of not just free but zeroed memory (and madvise 
zeroes the memory for us).  The decision of how _much_ memory to keep away 
from the page cache already has to be dealt with (and if it's tuneable we can 
reap the page cache viciously in UML).  In theory we'd want to keep some 
"free" memory back from being zeroed so we don't thrash with the host OS, but 
that might not be too hard.

Without prezeroing, it's more work.  Not quite sure how much more because the 
vm has changed a lot since I last believed I understood it...

> a Windows client via Putty and Cygwin/X from my laptop. Ah, sorry, I'm
> indeed doing this...

Back under OS/2 I once ran Win/OS2, brought up its dos box, and ran a 
commodore 64 emulator in it.  Because I could.  (Don't remember if I managed 
to shoehorn desqview in there, but if so it wasn't from lack of trying.)

> >  The fact my old
> > ubuntu's on a 2.6.10 kernel might have something to do with it, though...
> >
> > > Yep, I see - it becomes so reluctant to swapping that it prefers
> > > killing. Unintended, but at least a reasonable bug...
> >
> > Triggering the OOM killer when you have _any_ writes pending is silly.
>
> Hey, I said "reasonable bug", but don't forget "bug" in the sentence. It's
> reasonable as opposed to "busybox install doesn't work in UML", which is an
> unreasonable bug.

Busybox install does work in UML, though.  I've done it. :)

Rob


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel