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

[Blaisorblade <blaisorblade@yahoo.it>]

On Sunday 06 November 2005 00:44, Rob Landley wrote:
> On Saturday 05 November 2005 05:30, Blaisorblade wrote:
> > I've proposed in fact including (for now) another of Con's patch, which
> > gives some preference to free memory over pagecache (to speed up page
> > allocation)... but I don't quite understand why no Con's patches get
> > merged, at least in -mm (not that I follow that a lot)...
> >
> > Also, using pre-zeroing accelerators would mean that we need to keep some
> > zero-ed memory at hand...
>
> In theory, the state of truly free memory is irrelevant.  The fact madvise
> zeroes it out is nice, but not actually required.  (And I'm not sure
> madvise would actually zero if /tmp isn't tmpfs, so relying on the zeroing
> behavior might not be quite advisable just yet anyway.)
The API for that is not yet implemented, but the idea is "we're going to punch 
a hole in the file", so the zero'ing (which is, actually, implicit, 
especially in this case) is the only correct way.

In fact, the zero-ing is done by remapping read-only to empty_zero_page on the 
next read fault; only when there is a write fault we need to allocate a new 
zeroed page.

> updatedb is mostly reads, but due to our over-eager page cache, reads can
> bloat the page cache to push running programs out of memory.  There was
> some work back in the early 2.4 timeframe to add new page cache pages to
> the 'expired' list or some such, except that under load this fought with
> readahead...  (I lost track of things after Rik's vm got yanked in favor of
> Arcandrea Angeli's because I never _did_ get a clear explanation of what
> the heck a classzone was...)
I've no idea of the "expired" list but I guess current Rik's work on 

> The anticipatory scheduler does stupid things sometimes when both writes
> and reads are under pressure.  There have been a dozen different approaches
> to try to make this all work.  Token based swap thrashing control was the
> most recent, I believe.
Doesn't work well yet, so it's currently disabled... (see linux-mm wiki and/or 
comments in the code).
> I've hit every single bad case out there, under 
> 2.4.4 I once got my desktop so badly into swap city that I went to lunch,
> came back, and it was STILL SWAPPING.  Trying to switch to a different
> konqueror window! (Power cycle time.)
:: LOL ::
To get that I simply needed to run "make -j" on a kernel tree (not "-jN", 
"-j", i.e. without limit).
> I've been able to bring any linux desktop system to its knees (it's easy,
> open 40 konqueror tabs
You'll likely prefer Opera then - I have your same habit, but I'm actively 
trying to switch away.
> and a copy of kmail with 60,000 linux-kernel 
> messages in "threaded" mode, while using vi and kmail's composer. 
> Compiling stuff is an optional extra...)  I thought upgrading to 512 megs
> of ram might make it go away, but apparently not...

> > 3) Have you looked at C. Aker's ubd token limiter?

> The UML instance is legitimately swapping, it's running something with a
> ~200 meg working set in 64 megs of ram and 256 megs of swap.  (This is why
> I'm interested in any "give pages back to the host system" approach that
> would let me just _give_ UML 256 megs of ram without starving my desktop
> because UML has filled itself up with redundant page cache.)
ubd token limiter doesn't interact with VM, it's just a "be nice on the host, 
and auto-limit yourself."

It slows down request submitting, and it's used by Christoph for hosting 
multiple UMLs, but will help you too I guess.

> The dd to create the file on the parent filesystem
> created a sparse file, which UML was happy to loopback mount because hostfs
> hid the sparseness of it.

1) I think that loop-back mount is supposed to work on sparse files too (the 
only thing which is refused is "swapon <sparse file>").
2) How does hostfs hides that? That's interesting (as a bug, I mean).

> > which is
> > an atypical workload and not optimized against fragmentation... we could
> > well have a sequential read in UML become a crazy seek storm in the host.

> You could,
Sorry, "we could" means "it could happen that".
> but I'm not feeding it sparse files, exactly to avoid this 
> possibility.

> > About this, a paper at OLS (Virtualized GNU/Linux testing across
> > distros?) talks about "special I/O elevator setup" for UML, and the
> > authors talked to you for some issues, and IIRC maybe even work at
> > Intel...

> I've configured UML to use the NOP elevator, because all my I/O goes
> through the parent system which should have its own elevator.  I can try
> feeding UML an elevator if you think it'll help...
Dunno... my idea is that nop can make sense, but that paper seemed to hint at 
something smarter than this.
-- 
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade


		
___________________________________ 
Yahoo! Messenger: chiamate gratuite in tutto il mondo 
http://it.messenger.yahoo.com



-------------------------------------------------------
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