On Thu, 26 Jul 2007 12:27:30 +0200 Ingo Molnar [off-list ref] wrote:

* Andrew Morton [off-list ref] wrote:

quoted

quoted

quoted

quoted

( we _do_ want to baloon the dentry cache otherwise - for things like 
  "find" - having a fast VFS is important. But known-use-once things 
  like the daily updatedb job can clearly be annotated properly. )

Mutter.  /proc/sys/vm/vfs_cache_pressure has been there for what, 
three years?  Are any distros raising it during the updatedb run yet?

but ... that's system-wide, and the 'dont baloon the dcache' is only a 
property of updatedb.

Sure, but it's practical, isn't it?  Who runs (and cares about) 
vfs-intensive workloads during their wee-small-hours updatedb run?

there's another side-effect: it likely results in the zapping of 
thousands of dentries that were cached nicely before. So we might 
exchange 'all my apps are swapped out' experience with 'all file access 
is slow'. The latter is _probably_ still an improvement over the 
balooning, but i'm not sure.

Yup.  Nobody has begun to think about preserving dcache/icache across load
shifts yet, afaik.  Hard.

What we _really_ want is an updatedb that 
does not disturb the dcache.

Well.  Hopefully this time next year you can prep a 16MB container and toss
your updatedb inside that.  Maybe set its peak disk bandwidth utilisation
too.  However that won't work ;) because I don't think anyone is looking
at containerisation of vfs cache memory yet.  Perhaps full-on openvz has it,
dunno.

But updatedb is a special case, because it is so vfs-intensive.  For lots
of other workloads (those which use heaps of pagecache), resource
management via containerisation will work nicely.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>