From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751159AbdAQDo2 (ORCPT ); Mon, 16 Jan 2017 22:44:28 -0500 Received: from out0-139.mail.aliyun.com ([140.205.0.139]:42518 "EHLO out0-139.mail.aliyun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750827AbdAQDoU (ORCPT ); Mon, 16 Jan 2017 22:44:20 -0500 X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R111e4;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e02c03280;MF=hillf.zj@alibaba-inc.com;NM=1;PH=DS;RN=7;SR=0;TI=SMTPD_---.7SjsyPU_1484624539; Reply-To: "Hillf Danton" From: "Hillf Danton" To: "'Michal Hocko'" , "'Johannes Weiner'" Cc: "'Minchan Kim'" , "'Mel Gorman'" , , "'LKML'" , "'Michal Hocko'" References: <20170116160123.GB30300@cmpxchg.org> <20170116193317.20390-1-mhocko@kernel.org> <20170116193317.20390-2-mhocko@kernel.org> In-Reply-To: <20170116193317.20390-2-mhocko@kernel.org> Subject: Re: [PATCH 2/3] mm, vmscan: consider eligible zones in get_scan_count Date: Tue, 17 Jan 2017 11:42:19 +0800 Message-ID: <033c01d27073$b4937bc0$1dba7340$@alibaba-inc.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQMPtJ1U7bkG0NI7kTfQ6eSfedre8AHOwZNfApyAV+SeniOs8A== Content-Language: zh-cn Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tuesday, January 17, 2017 3:33 AM Michal Hocko wrote: > > From: Michal Hocko > > get_scan_count considers the whole node LRU size when > - doing SCAN_FILE due to many page cache inactive pages > - calculating the number of pages to scan > > in both cases this might lead to unexpected behavior especially on 32b > systems where we can expect lowmem memory pressure very often. > > A large highmem zone can easily distort SCAN_FILE heuristic because > there might be only few file pages from the eligible zones on the node > lru and we would still enforce file lru scanning which can lead to > trashing while we could still scan anonymous pages. > > The later use of lruvec_lru_size can be problematic as well. Especially > when there are not many pages from the eligible zones. We would have to > skip over many pages to find anything to reclaim but shrink_node_memcg > would only reduce the remaining number to scan by SWAP_CLUSTER_MAX > at maximum. Therefore we can end up going over a large LRU many times > without actually having chance to reclaim much if anything at all. The > closer we are out of memory on lowmem zone the worse the problem will > be. > > Fix this by filtering out all the ineligible zones when calculating the > lru size for both paths and consider only sc->reclaim_idx zones. > > Acked-by: Minchan Kim > Signed-off-by: Michal Hocko > --- Acked-by: Hillf Danton