"Martin J. Bligh" [off-list ref] wrote:

quoted

quoted

Currently the VM decides to start doing background writeback of pages if 
 10% of the systems pages are dirty, and starts doing synchronous 
 writeback of pages if 40% are dirty.  This is great for smaller memory 
 systems, but in larger memory systems (>2GB or so), a process can dirty 
 ALL of lowmem (ZONE_NORMAL, 896MB) without hitting the 40% dirty page 
 ratio needed to force the process to do writeback. 

Yes, it has been that way for a year or so.  I was wondering if anyone
would hit any problems in practice.  Have you hit any problem in practice?

I agree that the per-zonification of this part of the VM/VFS makes some
sense, although not _complete_ sense, because as you've seen, we need to
perform writeout against all zones' pages if _any_ zone exceeds dirty
limits.  This could do nasty things on a 1G highmem machine, due to the
tiny highmem zone.  So maybe that zone should not trigger writeback.

However the simplest fix is of course to decrease the default value of the
dirty thresholds - put them back to the 2.4 levels.  It all depends upon
the nature of the problems which you have been observing?

I'm not sure that'll fix the problem for NUMA boxes, which is where we 
started.

What problems?

When any node fills up completely with dirty pages (which would
only require one process doing a streaming write (eg an ftp download),
it seems we'll get into trouble.

What trouble?

If we change the thresholds from 40% to
20%, that just means you need a slightly larger system to trigger it,
it never fixes the problem ;-(

What problem?


If we make the dirty threshold a proportion of the initial amount of free
memory in ZONE_NORMAL, as is done in 2.4 it will not be possible to fill
any node with dirty pages.

--
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:"aart@kvack.org"> aart@kvack.org </a>