From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933825Ab2GLNih (ORCPT ); Thu, 12 Jul 2012 09:38:37 -0400 Received: from mail-pb0-f46.google.com ([209.85.160.46]:60899 "EHLO mail-pb0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932480Ab2GLNif (ORCPT ); Thu, 12 Jul 2012 09:38:35 -0400 Date: Thu, 12 Jul 2012 21:38:22 +0800 From: Wanpeng Li To: Michal Hocko Cc: linux-mm@kvack.org, Johannes Weiner , KAMEZAWA Hiroyuki , Andrew Morton , cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, Wanpeng Li Subject: Re: [PATCH RFC] mm/memcg: recalculate chargeable space after waiting migrating charges Message-ID: <20120712133822.GA2432@kernel> Reply-To: Wanpeng Li References: <1342089561-11211-1-git-send-email-liwp.linux@gmail.com> <20120712110838.GE21013@tiehlicka.suse.cz> <20120712115125.GA11103@kernel> <20120712122912.GH21013@tiehlicka.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120712122912.GH21013@tiehlicka.suse.cz> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jul 12, 2012 at 02:29:38PM +0200, Michal Hocko wrote: >On Thu 12-07-12 19:51:25, Wanpeng Li wrote: >> On Thu, Jul 12, 2012 at 01:08:38PM +0200, Michal Hocko wrote: >> >On Thu 12-07-12 18:39:21, Wanpeng Li wrote: >> >> From: Wanpeng Li >> >> >> >> Function mem_cgroup_do_charge will call mem_cgroup_reclaim, >> >> there are two break points in mem_cgroup_reclaim: >> >> if (total && (flag & MEM_CGROUP_RECLAIM_SHIRINK)) >> >> break; >> >> if (mem_cgroup_margin(memcg)) >> >> break; >> >> so mem_cgroup_reclaim can't guarantee reclaim enough pages(nr_pages) >> >> which is requested from mem_cgroup_do_charge, if mem_cgroup_margin >> >> (mem_over_limit) >= nr_pages is not true, the process will go to >> >> mem_cgroup_wait_acct_move to wait doubly charge counted caused by >> >> task move. >> > >> >I am sorry but I have no idea what you are trying to say. The >> >mem_cgroup_wait_acct_move just makes sure that we are waiting until >> >charge is moved (which can potentially free some charges) rather than >> >OOM which should be the last resort so it makes sense to retry them >> >charge. >> > >> >> But this time still can't guarantee enough pages(nr_pages) is >> >> ready, directly return CHARGE_RETRY is incorret. >> > >> >So you think it is better to oom? Why? What prevents you from a race >> >that your mem_cgroup_margin returns true but another CPU consumes those >> >charges right after that. See? The check is pointless. It doesn't >> >> Hmm, if there are a race as you mentioned it can't guarantee enough pages >> is ready. > >And there is no point in guaranteeing anything which I tried to tell you >by the example... The only thing that matters is whether we get the charge >on the next attempt and if not whether we are able to reclaim something. >See? > >> But it also means that available memory is too low if this >> race happen. If available charges still less than nr_pages >> after mem_cgroup_wait_acct_move(which can potentially >> free some charges) return, the CHAGE_RETRY will trigged, >> and then mem_cgroup_do_charge=>meory_cgroup_reclaim >> =>mem_cgroup_wait_acct_move, if available charges still less than >> nr_pages in this round, CHAGE_RETRY..... > >> To avoid this infinite retry when available memory > >I do not see a realistic scenario which would cause this to be infinite loop >withou OOM jumping in. >We would have to hit the wait for move after each reclaim and the move would >have to keep the the usage constant (move is really fast without moving >charges). >So what you are trying to address (if I understand it at all) is to fix >an almost impossible to trigger issue with a bogus change which doesn't >help at all because it is racy as well. OK. Thank you Michal! :-) Thanks & Best Regards, Wanpeng Li > >> in this memcg is very low, go to OOM if mem_cgroup_margin(mem_over_limit) >> < nr_pages is a better way I think. Because the codes have already try >> its best to reclaim some pages. :-) > > >> >[...] >-- >Michal Hocko >SUSE Labs >SUSE LINUX s.r.o. >Lihovarska 1060/12 >190 00 Praha 9 >Czech Republic