On 11/02/2010 11:03 PM, Minchan Kim wrote:
It could. But time based approach would be same, IMHO. First of all, I don't want long latency of direct reclaim process. It could affect response of foreground process directly. If VM limits the number of pages reclaimed per second, direct reclaim process's latency will be affected. so we should avoid throttling in direct reclaim path. Agree?
The idea would be to not throttle the processes trying to reclaim page cache pages, but to only reclaim anonymous pages when the page cache pages are low (and occasionally a few page cache pages, say 128 a second). If too many reclaimers come in when the page cache is low and no swap is available, we will OOM kill instead of stalling. After all, the entire point of this patch would be to avoid minutes-long latencies in triggering the OOM killer. -- All rights reversed -- 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/ . Fight unfair telecom policy in Canada: sign http://dissolvethecrtc.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>