From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754887AbcG1K2G (ORCPT ); Thu, 28 Jul 2016 06:28:06 -0400 Received: from outbound-smtp08.blacknight.com ([46.22.139.13]:41496 "EHLO outbound-smtp08.blacknight.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753863AbcG1K14 (ORCPT ); Thu, 28 Jul 2016 06:27:56 -0400 Date: Thu, 28 Jul 2016 11:27:51 +0100 From: Mel Gorman To: Joonsoo Kim Cc: Andrew Morton , Johannes Weiner , Minchan Kim , Michal Hocko , Vlastimil Babka , Linux-MM , LKML Subject: Re: [PATCH 0/5] Candidate fixes for premature OOM kills with node-lru v2 Message-ID: <20160728102751.GB2799@techsingularity.net> References: <1469110261-7365-1-git-send-email-mgorman@techsingularity.net> <20160726081129.GB15721@js1304-P5Q-DELUXE> <20160726125050.GP10438@techsingularity.net> <20160728064432.GA28136@js1304-P5Q-DELUXE> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <20160728064432.GA28136@js1304-P5Q-DELUXE> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jul 28, 2016 at 03:44:33PM +0900, Joonsoo Kim wrote: > > To some extent, it could be "addressed" by immediately reclaiming active > > pages moving to the inactive list at the cost of distorting page age for a > > workload that is genuinely close to OOM. That is similar to what zone-lru > > ended up doing -- fast reclaiming young pages from a zone. > > My expectation on my test case is that reclaimers should kick out > actively used page and make a room for 'fork' because parallel readers > would work even if reading pages are not cached. > > It is sensitive on reclaimers efficiency because parallel readers > read pages repeatedly and disturb reclaim. I thought that it is a > good test for node-lru which changes reclaimers efficiency for lower > zone. However, as you said, this efficiency comes from the cost > distorting page aging so now I'm not sure if it is a problem that we > need to consider. Let's skip it? > I think we should skip it for now. The alterations are too specific to a test case that is very close to being genuinely OOM. Adjusting timing for one OOM case may just lead to complains that OOM is detected too slowly in others. > Anyway, thanks for tracking down the problem. > My pleasure, thanks to both you and Minchan for persisting with this as we got some important fixes out of the discussion. -- Mel Gorman SUSE Labs