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

[Rob Landley]

On Friday 04 November 2005 11:18, Blaisorblade wrote:
> > Oh well, bench it when it happens.  (And in any case, it needs a tunable
> > to beat the page cache into submission or there's no free memory to give
> > back.
>
> I couldn't parse your sentence. The allocation will free memory like when
> memory is needed.

If you've got a daemon running in the virtual system to hand back memory to 
the host, then you don't need a tuneable.

What I was thinking is that if we get prezeroing infrastructure that can use 
various prezeroing accelerators (as has been discussed but I don't believe 
merged), then a logical prezeroing accelerator for UML would be calling 
madvise on the host system.  This has the advantage of automatically giving 
back to the host system any memory that's not in use, but would require some 
way to tell kswapd or some such that keeping around lots of prezeroed memory 
is preferable to keeping around lots of page cache.

In my case, I have a workload that can mostly work with 32-48 megs of ram, but 
it spikes up to 256 at one point.  Right now, I'm telling UML mem=64 megs and 
the feeding it a 256 swap file on ubd, but this is hideously inefficient when 
it actually tries to use this swap file.  (And since the host system is 
running a 2.6.10 kernel, there's a five minute period during each build where 
things on my desktop actually freeze for 15-30 seconds at a time.  And this 
is on a laptop with 512 megs of ram.  I think it's because the disk is so 
overwhelmed, and some things (like vim's .swp file, and something similar in 
kmail's composer) do a gratuitous fsync...

> However look at /proc/sys/vm/swappiness

Setting swappiness to 0 triggers the OOM killer on 2.6.14 for a load that 
completes with swappiness at 60.  I mentioned this on the list a little while 
ago and some people asked for copies of my test script...

> or use Con Kolivas's patches to find new tunable and policies.

The daemon you mentioned is an alternative, but I'm not quite sure how rapid 
the daemon's reaction is going to be to potential OOM situations when 
something suddenly wants an extra 200 megs...

Rob
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/