On Tue, Jan 24, 2012 at 5:47 PM, Hillf Danton <dhillf@xxxxxxxxx> wrote: > On Wed, Jan 25, 2012 at 7:22 AM, Ying Han <yinghan@xxxxxxxxxx> wrote: >> On Mon, Jan 23, 2012 at 7:45 PM, Hillf Danton <dhillf@xxxxxxxxx> wrote: >>> With soft limit available, what if nr_to_reclaim set to be the number of >>> pages exceeding soft limit? With over reclaim abused, what are the targets >>> of soft limit? >> >> The nr_to_reclaim is set to SWAP_CLUSTER_MAX (32) for direct reclaim >> and ULONG_MAX for background reclaim. Not sure we can set it, but it >> is possible the res_counter_soft_limit_excess equal to that target >> value. The current soft limit mechanism provides a clue of WHERE to >> reclaim pages when there is memory pressure, it doesn't change the >> reclaim target as it was before. >> > > Decrement in sc->nr_to_reclaim was tried in another patch, you already saw it. > >> Overreclaim a cgroup under its softlimit is bad, but we should be >> careful not introducing side effect before providing the guarantee. > > Yes 8-) > >> Here, the should_continue_reclaim() has logic of freeing a bit more >> order-0 pages for compaction. The logic got changed after this. >> > > Compaction is to increase the successful rate of THP allocation, and in turn > to back up higher performance. In soft limit, performance guarantee is not > extra request but treated with less care. > > Which one you prefer, compaction or guarantee? The compaction is something we already supporting, while the softlimit implementation is a new design. I would say that we need to guarantee no regression introduced by any new code. --Ying > Thanks > Hillf -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>