From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757534Ab2ARNk5 (ORCPT ); Wed, 18 Jan 2012 08:40:57 -0500 Received: from cantor2.suse.de ([195.135.220.15]:59474 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757499Ab2ARNk4 (ORCPT ); Wed, 18 Jan 2012 08:40:56 -0500 Date: Wed, 18 Jan 2012 14:40:53 +0100 From: Michal Hocko To: Hillf Danton Cc: linux-mm@kvack.org, Johannes Weiner , KAMEZAWA Hiroyuki , Hugh Dickins , Andrew Morton , LKML , Balbir Singh Subject: Re: [PATCH] mm: memcg: remove checking reclaim order in soft limit reclaim Message-ID: <20120118134053.GD31112@tiehlicka.suse.cz> References: <20120117131601.GB14907@tiehlicka.suse.cz> <20120117140712.GC14907@tiehlicka.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 Wed 18-01-12 20:30:41, Hillf Danton wrote: > On Tue, Jan 17, 2012 at 10:07 PM, Michal Hocko wrote: > > On Tue 17-01-12 21:29:52, Hillf Danton wrote: > >> On Tue, Jan 17, 2012 at 9:16 PM, Michal Hocko wrote: > >> > Hi, > >> > > >> > On Tue 17-01-12 20:47:59, Hillf Danton wrote: > >> >> If async order-O reclaim expected here, it is settled down when setting up scan > >> >> control, with scan priority hacked to be zero. Other than that, deny of reclaim > >> >> should be removed. > >> > > >> > Maybe I have misunderstood you but this is not right. The check is to > >> > protect from the _global_ reclaim with order > 0 when we prevent from > >> > memcg soft reclaim. > >> > > >> need to bear mm hog in this way? > > > > Could you be more specific? Are you trying to fix any particular > > problem? > > > My thought is simple, the outcome of softlimit reclaim depends little on the > value of reclaim order, zero or not, and only exceeding is reclaimed, so > selective response to swapd's request is incorrect. OK, got your point, finally. Let's add Balbir (the proposed patch can be found at https://lkml.org/lkml/2012/1/17/166) to the CC list because this seems to be a design decision. I always thought that this is because we want non-userspace (high order) mem pressure to be handled by the global reclaim only. And it makes some sense to me because it is little bit strange to reclaim for order-0 while the request is for an higher order. I guess this might lead to an extensive and pointless reclaiming because we might end up with many free pages which cannot satisfy higher order allocation. On the other hand, it is true that the documentation says that the soft limit is considered when "the system detects memory contention or low memory" which doesn't say that the contention comes from memcg accounted memory. Anyway this changes the current behavior so it would better come with much better justification which shows that over reclaim doesn't happen and that we will not see higher latencies with higher order allocations. Thanks -- Michal Hocko SUSE Labs SUSE LINUX s.r.o. Lihovarska 1060/12 190 00 Praha 9 Czech Republic