From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail190.messagelabs.com (mail190.messagelabs.com [216.82.249.51]) by kanga.kvack.org (Postfix) with ESMTP id 899A68D003B for ; Fri, 22 Apr 2011 04:08:58 -0400 (EDT) Received: from m1.gw.fujitsu.co.jp (unknown [10.0.50.71]) by fgwmail6.fujitsu.co.jp (Postfix) with ESMTP id 392F83EE0C2 for ; Fri, 22 Apr 2011 17:08:56 +0900 (JST) Received: from smail (m1 [127.0.0.1]) by outgoing.m1.gw.fujitsu.co.jp (Postfix) with ESMTP id 0C5A545DE62 for ; Fri, 22 Apr 2011 17:08:56 +0900 (JST) Received: from s1.gw.fujitsu.co.jp (s1.gw.fujitsu.co.jp [10.0.50.91]) by m1.gw.fujitsu.co.jp (Postfix) with ESMTP id E550245DE5C for ; Fri, 22 Apr 2011 17:08:55 +0900 (JST) Received: from s1.gw.fujitsu.co.jp (localhost.localdomain [127.0.0.1]) by s1.gw.fujitsu.co.jp (Postfix) with ESMTP id B5F9BE78003 for ; Fri, 22 Apr 2011 17:08:55 +0900 (JST) Received: from ml14.s.css.fujitsu.com (ml14.s.css.fujitsu.com [10.240.81.134]) by s1.gw.fujitsu.co.jp (Postfix) with ESMTP id 7792D1DB8049 for ; Fri, 22 Apr 2011 17:08:55 +0900 (JST) Date: Fri, 22 Apr 2011 17:02:12 +0900 From: KAMEZAWA Hiroyuki Subject: Re: [PATCH V7 4/9] Add memcg kswapd thread pool Message-Id: <20110422170212.b21852ed.kamezawa.hiroyu@jp.fujitsu.com> In-Reply-To: References: <1303446260-21333-1-git-send-email-yinghan@google.com> <1303446260-21333-5-git-send-email-yinghan@google.com> <20110422133643.6a36d838.kamezawa.hiroyu@jp.fujitsu.com> <20110422140023.949e5737.kamezawa.hiroyu@jp.fujitsu.com> <20110422145943.a8f5a4ef.kamezawa.hiroyu@jp.fujitsu.com> <20110422164622.a8350bc5.kamezawa.hiroyu@jp.fujitsu.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Ying Han Cc: KOSAKI Motohiro , Minchan Kim , Daisuke Nishimura , Balbir Singh , Tejun Heo , Pavel Emelyanov , Andrew Morton , Li Zefan , Mel Gorman , Christoph Lameter , Johannes Weiner , Rik van Riel , Hugh Dickins , Michal Hocko , Dave Hansen , Zhu Yanhai , linux-mm@kvack.org On Fri, 22 Apr 2011 00:59:26 -0700 Ying Han wrote: > On Fri, Apr 22, 2011 at 12:46 AM, KAMEZAWA Hiroyuki < > kamezawa.hiroyu@jp.fujitsu.com> wrote: > > > On Thu, 21 Apr 2011 23:10:58 -0700 > > Ying Han wrote: > > > > > On Thu, Apr 21, 2011 at 10:59 PM, KAMEZAWA Hiroyuki < > > > kamezawa.hiroyu@jp.fujitsu.com> wrote: > > > > > > > On Thu, 21 Apr 2011 22:53:19 -0700 > > > > Ying Han wrote: > > > > > > > > > On Thu, Apr 21, 2011 at 10:00 PM, KAMEZAWA Hiroyuki < > > > > > kamezawa.hiroyu@jp.fujitsu.com> wrote: > > > > > > > > > > > On Thu, 21 Apr 2011 21:49:04 -0700 > > > > > > Ying Han wrote: > > > > > > > > > > > > > On Thu, Apr 21, 2011 at 9:36 PM, KAMEZAWA Hiroyuki < > > > > > > > kamezawa.hiroyu@jp.fujitsu.com> wrote: > > > > > > add a counter for kswapd-scan and kswapd-reclaim, kswapd-pickup will > > show > > > > you information, if necessary it's good to show some latecy stat. I > > think > > > > we can add enough information by adding stats (or debug by perf tools.) > > > > I'll consider this a a bit more. > > > > > > > > > > Something like "kswapd_pgscan" and "kswapd_steal" per memcg? If we are > > going > > > to the thread-pool, we definitely need to add more stats to give us > > enough > > > visibility of per-memcg background reclaim activity. Still, not sure > > about > > > the cpu-cycles. > > > > > > > BTW, Kosaki requeted me not to have private thread pool implementation and > > use workqueue. I think he is right. So, I'd like to write a patch to > > enhance > > workqueue for using it for memcg (Of couse, I'll make a private workqueue.) > > > > Hmm. Can you give a bit more details of the logic behind? Kosaki just says please avoid reinventing the wheel. It seems it's used in many places and has rich functions. I think we should do try. With my patch for threadl pools, I think I can avoid starvation problem. > and what's about the private workqueue? Dont use schedule_work() but use queue_work(). > Also, how we plan to solve the better debug-ability issue. > I'll add patch for debug ability. I belive I can record cputime usage for memory reclaim per memcg, both for direct and background. I think it's a good feature for memcg regardless of background reclaim. > > > > == > > 2. regarding to the alternative workqueue, which is more complicated and we > > need to be very careful of work items in the workqueue. We've experienced > > in > > one workitem stucks and the rest of the work item won't proceed. For > > example > > in dirty page writeback, one heavily writer cgroup could starve the other > > cgroups from flushing dirty pages to the same disk. In the kswapd case, I > > can > > imagine we might have similar senario. How to prioritize the workitems is > > another problem. The order of adding the workitems in the queue reflects > > the > > order of cgroups being reclaimed. We don't have that restriction currently > > but > > relying on the cpu scheduler to put kswapd on the right cpu-core to run. We > > "might" introduce priority later for reclaim and how are we gonna deal with > > that. > > == > > > > From this, I feel I need to use unbound workqueue. BTW, with patches for > > current thread pool model, I think starvation problem by dirty pages > > cannot be seen. > > Anyway, I'll give a try. > > > > Then do you suggest me to wait for your patch for my next post? > Feel free to do. But I think it's near to weekend and posting patch right now or posting patch at Monday will not make big changes. Thanks, -Kame -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. 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: email@kvack.org