On 04/21/2010 03:35 AM, Christian Ehrhardt wrote:
Christian Ehrhardt wrote:
Rik van Riel wrote:
On 04/20/2010 11:32 AM, Johannes Weiner wrote:
The idea is that it pans out on its own. If the workload changes, new
pages get activated and when that set grows too large, we start
shrinking
it again.
Of course, right now this unscanned set is way too large and we can end
up wasting up to 50% of usable page cache on false active pages.
Thing is, changing workloads often change back.
Specifically, think of a desktop system that is doing
work for the user during the day and gets backed up
at night.
You do not want the backup to kick the working set
out of memory, because when the user returns in the
morning the desktop should come back quickly after
the screensaver is unlocked.
IMHO it is fine to prevent that nightly backup job from not being
finished when the user arrives at morning because we didn't give him
some more cache - and e.g. a 30 sec transition from/to both optimized
states is fine.
But eventually I guess the point is that both behaviors are reasonable
to achieve - depending on the users needs.
What we could do is combine all our thoughts we had so far:
a) Rik could create an experimental patch that excludes the in flight
pages
b) Johannes could create one for his suggestion to "always scan active
file pages but only deactivate them when the ratio is off and
otherwise strip buffers of clean pages"
I think you are confusing "buffer heads" with "buffers".
You can strip buffer heads off pages, but that is not
your problem.
"buffers" in /proc/meminfo stands for cached metadata,
eg. the filesystem journal, inodes, directories, etc...
Caching such metadata is legitimate, because it reduces
the number of disk seeks down the line.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxxx For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>