On Wed, 27 Apr 2011 09:10:30 +0900 KAMEZAWA Hiroyuki <kamezawa.hiroyu@xxxxxxxxxxxxxx> wrote: > On Tue, 26 Apr 2011 16:15:04 -0700 > Ying Han <yinghan@xxxxxxxxxx> wrote: > > So, here we fix the amount of work per-memcg, and the performance for those > > jobs will be hurt. If i understand > > correctly, we only have one workitem on the workqueue per memcg. So which > > means we can only reclaim those amount of pages for each iteration. And if > > the queue is big, those jobs(heavy memory allocating, and willing to pay cpu > > to do bg reclaim) will hit direct reclaim more than necessary. > > > > But, from measurements, we cannot reclaim enough memory on time if the work > is busy. Can you think of 'make -j 8' doesn't hit the limit by bgreclaim ? > > 'Working hard' just adds more CPU consumption and results more latency. > From my point of view, if direct reclaim has problematic costs, bgreclaim is > not easy and slow, too. Then, 'work harder' cannot be help. And spike of > memory consumption can be very rapid. If an application exec an application > which does malloc(2G), under 1G limit memcg, we cannot avoid direct reclaim. > > I think the user can set limit higher and distance between limit <-> wmark large. > Then, he can gain more time and avoid hitting direct relcaim. How about enlarging > limit <-> wmark range for performance intensive jobs ? > Amount of work per memcg is limit <-> wmark range, I guess. > BTW, in another idea, I wonder I should limit work iterms by reducing max_active because it may burn cpu. If we need, we can have 2 workqueues of high/low priority. high workqueue has big max_active(0?) and low workqueue has small max_active. Thanks, -Kame -- 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 internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>