Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp1581012yba; Thu, 9 May 2019 20:05:44 -0700 (PDT) X-Google-Smtp-Source: APXvYqwOFjDdfs3x+ruitEzl9ZQLNMxJfVuynZkFFjvMju9kJVtsdPOt32OkIndL4y1umIScHZRq X-Received: by 2002:a17:902:2ae6:: with SMTP id j93mr1973129plb.115.1557457544292; Thu, 09 May 2019 20:05:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1557457544; cv=none; d=google.com; s=arc-20160816; b=xmoUzfYSb7/iCtlHukjIYhKE3Wc7UVvRWk8543ra2NbejwLgzGg0YgiWJeknqn5Rfr fj0J87M7tZuiVFKb2CffjiVtXSDPlcq8Q+mg9pr0L8/hLyNPeaCuIQ545HWTrCLyW4SD SvaUsBt8npsysdcsQUZdz3UZ7TNt9NFclVYPvE4mKONS1XTPRXFES+WhxOcMV0uXjsOq RVe1PT7D4i9MVpl8V/J/Es2g3vCliyRbnhPugtMucHA7rF9gitCQmZfFlCwYNiWAIEJE RoqA365PBlCOg+nM1R1ite4S6+bQNeBgolFCAYLDryPYaxNkz8zjgtxCo108mVBhM0DQ oouA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:message-id :in-reply-to:date:references:subject:cc:to:from; bh=4X/GbgMsSIhCwQ6jqGE96QTIgxr7vrCRrYAFUpt6EBE=; b=PECj/Wv3GIcrUonEUYgSd+LMJ2MlgbOyCCqhx6rCjV4oC1/iA5uTSaPhqcGy95O2Dk TJ+QNqeq/Iyc/Qkv7BblOxZlKajOe4Pd6uwhTQdjI6DML2DHzV6fY3Lc8pSb72n1bv9m NvgVGPJPIaocT37V65v9fOSRvT2AKKxj1RjqA4KGli3+RQMU4xhryMmfFffiqUi3nlJc 8WqU5EXCSSNB9gLivRA3pSSWCvSBNjd8VZQZpFNDQJ0d6n37iO0xU3uQ9ISGko01c2ak /CcAO0/u3XydC/MHTNl9ggFzZkafPemZYPIXGCRNi0M6ellV0AcszbtziYgl90LKLX6L M0gw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id s17si5761947pfm.170.2019.05.09.20.05.27; Thu, 09 May 2019 20:05:44 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727037AbfEJDDT (ORCPT + 99 others); Thu, 9 May 2019 23:03:19 -0400 Received: from mga14.intel.com ([192.55.52.115]:56872 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726842AbfEJDDT (ORCPT ); Thu, 9 May 2019 23:03:19 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 May 2019 20:03:18 -0700 X-ExtLoop1: 1 Received: from yhuang-dev.sh.intel.com (HELO yhuang-dev) ([10.239.159.29]) by fmsmga001.fm.intel.com with ESMTP; 09 May 2019 20:03:17 -0700 From: "Huang\, Ying" To: Yang Shi Cc: , , , , , , , Subject: Re: [PATCH] mm: vmscan: correct nr_reclaimed for THP References: <1557447392-61607-1-git-send-email-yang.shi@linux.alibaba.com> <87y33fjbvr.fsf@yhuang-dev.intel.com> <1fb73973-f409-1411-423b-c48895d3dde8@linux.alibaba.com> Date: Fri, 10 May 2019 11:03:16 +0800 In-Reply-To: <1fb73973-f409-1411-423b-c48895d3dde8@linux.alibaba.com> (Yang Shi's message of "Thu, 9 May 2019 19:25:20 -0700") Message-ID: <87tve3j9jf.fsf@yhuang-dev.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=ascii Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Yang Shi writes: > On 5/9/19 7:12 PM, Huang, Ying wrote: >> Yang Shi writes: >> >>> Since commit bd4c82c22c36 ("mm, THP, swap: delay splitting THP after >>> swapped out"), THP can be swapped out in a whole. But, nr_reclaimed >>> still gets inc'ed by one even though a whole THP (512 pages) gets >>> swapped out. >>> >>> This doesn't make too much sense to memory reclaim. For example, direct >>> reclaim may just need reclaim SWAP_CLUSTER_MAX pages, reclaiming one THP >>> could fulfill it. But, if nr_reclaimed is not increased correctly, >>> direct reclaim may just waste time to reclaim more pages, >>> SWAP_CLUSTER_MAX * 512 pages in worst case. >>> >>> This change may result in more reclaimed pages than scanned pages showed >>> by /proc/vmstat since scanning one head page would reclaim 512 base pages. >>> >>> Cc: "Huang, Ying" >>> Cc: Johannes Weiner >>> Cc: Michal Hocko >>> Cc: Mel Gorman >>> Cc: "Kirill A . Shutemov" >>> Cc: Hugh Dickins >>> Signed-off-by: Yang Shi >>> --- >>> I'm not quite sure if it was the intended behavior or just omission. I tried >>> to dig into the review history, but didn't find any clue. I may miss some >>> discussion. >>> >>> mm/vmscan.c | 6 +++++- >>> 1 file changed, 5 insertions(+), 1 deletion(-) >>> >>> diff --git a/mm/vmscan.c b/mm/vmscan.c >>> index fd9de50..7e026ec 100644 >>> --- a/mm/vmscan.c >>> +++ b/mm/vmscan.c >>> @@ -1446,7 +1446,11 @@ static unsigned long shrink_page_list(struct list_head *page_list, >>> unlock_page(page); >>> free_it: >>> - nr_reclaimed++; >>> + /* >>> + * THP may get swapped out in a whole, need account >>> + * all base pages. >>> + */ >>> + nr_reclaimed += (1 << compound_order(page)); >>> /* >>> * Is there need to periodically free_page_list? It would >> Good catch! Thanks! >> >> How about to change this to >> >> >> nr_reclaimed += hpage_nr_pages(page); > > Either is fine to me. Is this faster than "1 << compound_order(page)"? I think the readability is a little better. And this will become nr_reclaimed += 1 if CONFIG_TRANSPARENT_HUAGEPAGE is disabled. Best Regards, Huang, Ying >> >> Best Regards, >> Huang, Ying