On Wed, Nov 03, 2010 at 07:41:35AM -0400, Rik van Riel wrote: > 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). Fair enough. Only anon reclaim is better than thrashing of code pages. > > If too many reclaimers come in when the page cache is > low and no swap is available, we will OOM kill instead > of stalling. I understand why you use (file < pages_min). We can keep the threshold small value. Otherwise, we can see the many OOM question. "Why OOM happens although my system have enough file LRU pages?" > > After all, the entire point of this patch would be to > avoid minutes-long latencies in triggering the OOM > killer. I got your point. The patch's goal is not protect working set fully, but prevent page cache thrashing in low file LRU. It could make minutes-long latencies by reaching the OOM. Okay. I will look into this idea. Thanks for the good suggestion, Rik. > > -- > All rights reversed -- Kind regards, Minchan Kim -- 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>