On Mon, 1 Mar 2010, Mel Gorman wrote: > > When kswapd is awoken due to reclaim by a running task, set the priority > > of kswapd to that of the task allocating pages thus making memory reclaim > > cpu activity affected by nice level. > > > > Why? > > When a process kicks kswapd, the watermark at which a process enters > direct reclaim has not been reached yet. In other words, there is no > guarantee that a process will stall due to memory pressure. > > The exception would be if there are many high-priority processes allocating > pages at a steady rate that are starving kswapd of CPU time and > consequently entering direct reclaim. They don't necessarily need to be allocating pages, they may simply be starving kswapd of cputime which increases the liklihood of subsequently entering direct reclaim because of a low watermark on a later allocation. Without this patch, it's trivial especially on smaller desktop machines or servers using cpusets to preempt kswapd from running by setting nice levels for processes from userspace to have high priority. If we're going to be doing background reclaim, it should not be done slower than one or more processes allocating pages; otherwise, we bias high priority tasks trying to allocate pages and favor lower priority. > My main concern is that in the case there are a mix of high and low processes > with kswapd towards the higher priority as a result of this patch, kswapd > could be keeping CPU time from low-priority processes that are well behaved > that would would make less forward progress as a result of this patch. > That would only be the case if we constantly follow the slowpath in the page allocator, in which case we want kswapd to run and reclaim memory so that all processes can use the fastpath. -- 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>