Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp4357052ybi; Tue, 11 Jun 2019 05:27:18 -0700 (PDT) X-Google-Smtp-Source: APXvYqyFiLXXTskmOE7nMeJlfxKCWCpJNEu08x8Yeog28ZjU9Q99Cg2rpx7vnNn35r+qD873EZY1 X-Received: by 2002:a17:902:76c6:: with SMTP id j6mr50861563plt.263.1560256038381; Tue, 11 Jun 2019 05:27:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1560256038; cv=none; d=google.com; s=arc-20160816; b=jCiT4zVp5X357mYyyOB51tbb6L2G+H44f/YRuej9ZSocvmEK/KUvpUJytSIlGV2uCS BKgf2rZJLA/xsnU+Htkncv4V2DUHCu8g038IT4UWSbmj+XIHISZpV1I5iy21YAlSI3iS zlx+e/rCrrNTkDJIZ3KzlSz7lgZynn8sZksHdRJUmZPYEkcZ+MDyiBi/W0E11LDDqBye PnR9BMyazUXtA3MzAA2dfYyDAAaSQYNXLi6ltq8QlhiLYsSYI5j/MPl6vRWyvHwtKyfu mY6QuMCPqiBmw64Y3TAhrhMFnlnFRqmH1SCWkFwJ1lnQvij2yX4j4MQk5nc+X3nqEBDY QPLA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:content-transfer-encoding :content-language:accept-language:message-id:date:thread-index :thread-topic:subject:cc:to:from; bh=0nJi3iIY+dGo3/lwOoDxgZpM/YrKAxBWjzbdi3IubQU=; b=Gm+9/nMHYMyx5FT9FHaEk+wiTLAG3XhmQBrx1Dyb+N0/Va6w5jgNs+BeHlhpOOHamA mIb2L1UXDUvvPwKi1PnWNgGNLdIW0z+FWjB4D+7zSPnFMB6hYBPvGNbFd+b6HFc/NlDU SG/QdtB+XBcz7nKJw0N7Yb2HYrI0YehBkGLOynibb11RyxAtZmafROYM53IsnBuuwn/a kWm2F2vDS1032oPyVS7xhoSz49V1l3r6x1UwXgMCs+bxBoIMVuWpEZPHx2IWyu79qY8/ /7vtPXljtOFMO4tSSpuTVRm1ES8iUdaz9JaoCsB7CEG/9TE5v/0NYLafg8ICyN75K9F8 TBEg== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b3si13111486pgd.243.2019.06.11.05.27.01; Tue, 11 Jun 2019 05:27:18 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2404598AbfFKMKt convert rfc822-to-8bit (ORCPT + 99 others); Tue, 11 Jun 2019 08:10:49 -0400 Received: from szxga02-in.huawei.com ([45.249.212.188]:6961 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S2404538AbfFKMKt (ORCPT ); Tue, 11 Jun 2019 08:10:49 -0400 Received: from dggemi403-hub.china.huawei.com (unknown [172.30.72.56]) by Forcepoint Email with ESMTP id 5299EAC9313952D287A7; Tue, 11 Jun 2019 20:10:47 +0800 (CST) Received: from DGGEMI529-MBS.china.huawei.com ([169.254.5.79]) by dggemi403-hub.china.huawei.com ([10.3.17.136]) with mapi id 14.03.0415.000; Tue, 11 Jun 2019 20:10:37 +0800 From: "Chengang (L)" To: Wei Yang CC: "akpm@linux-foundation.org" , "mhocko@suse.com" , "vbabka@suse.cz" , "osalvador@suse.de" , "pavel.tatashin@microsoft.com" , "mgorman@techsingularity.net" , "rppt@linux.ibm.com" , "alexander.h.duyck@linux.intel.com" , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH] mm: align up min_free_kbytes to multipy of 4 Thread-Topic: [PATCH] mm: align up min_free_kbytes to multipy of 4 Thread-Index: AdUgTeBw9ORISFAfQqiB/YjSHqoFpg== Date: Tue, 11 Jun 2019 12:10:36 +0000 Message-ID: Accept-Language: en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.74.216.69] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Wei Yang >On Sun, Jun 09, 2019 at 05:10:28PM +0800, ChenGang wrote: >>Usually the value of min_free_kbytes is multiply of 4, and in this case >>,the right shift is ok. >>But if it's not, the right-shifting operation will lose the low 2 bits, >But PAGE_SHIFT is not always 12. You are right, and this is not the key point, this is just an example. >>and this cause kernel don't reserve enough memory. >>So it's necessary to align the value of min_free_kbytes to multiply of 4. >>For example, if min_free_kbytes is 64, then should keep 16 pages, but >>if min_free_kbytes is 65 or 66, then should keep 17 pages. >> >>Signed-off-by: ChenGang >>--- >> mm/page_alloc.c | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) >> >>diff --git a/mm/page_alloc.c b/mm/page_alloc.c index d66bc8a..1baeeba >>100644 >>--- a/mm/page_alloc.c >>+++ b/mm/page_alloc.c >>@@ -7611,7 +7611,8 @@ static void setup_per_zone_lowmem_reserve(void) >> >> static void __setup_per_zone_wmarks(void) { >>- unsigned long pages_min = min_free_kbytes >> (PAGE_SHIFT - 10); >>+ unsigned long pages_min = >>+ (PAGE_ALIGN(min_free_kbytes * 1024) / 1024) >> (PAGE_SHIFT - 10); >In my mind, pages_min is an estimated value. Do we need to be so precise? This is the key point, user can set this value through interface/proc/sys/vm/min_free_kbytes, so a bit more precise is better. >> unsigned long lowmem_pages = 0; >> struct zone *zone; >> unsigned long flags; >>-- >>1.8.5.6 >-- >Wei Yang >Help you, Help me