Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp4357032ybi; Tue, 11 Jun 2019 05:27:16 -0700 (PDT) X-Google-Smtp-Source: APXvYqy4vXE9F+fhtH8j0QbYVNx5iZGX+XQThOGzPFTwzRUN6ZC307Hky/TZBEnW1jPJzRguWUnF X-Received: by 2002:a62:ee17:: with SMTP id e23mr82077376pfi.130.1560256036734; Tue, 11 Jun 2019 05:27:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1560256036; cv=none; d=google.com; s=arc-20160816; b=EWVO4I/NsMOikpzaDdyn9UwupC6gnO+zwQ7k2SgwHe8pvL+SZV6wWehpZruOIIdDCj lNIvD8cF2LMxRYQNHqz6lBctss9VCtzYQjkWdMh+k38dPoxyD4EFUWsCy1q34MM/vNj/ zjPe0dq3EW8v+OSwlXAHcVkmuP/LxRZT69R2zDGsOqjU+vB4Hm8/oxzNrLHAZYuPS5+A AE3MsN3bkA17tE81nxVASrB5J7ZSAp2XJUPyX9yOjvonmG6IyO1ZEoy0e/W5DVKyROEn AjHBB3Rkqauy+ZHb2DVHZ+vyH/AVjtv6aebB7aQ34j8p2jyVcjIv749LxwngfmJ2jZRr TDaQ== 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=QrlYqmBDltxK6W7XZ0eUpof6fcu1L6iLQjY1KNgxbuU=; b=jrGEoJRHfCDVZwd8jlUbzwuPREgWbJ1K0Bfm4thV8sCg4z7CHjfi1tRq4uJRf5qLr+ anjqvzQvshwXKPFqwq986X+pm8IX7yQMzZ8a3FViI29LFjwX9Rh4TvQPbiks9G+QrrN7 58trFJhpLWsU+PN+4e0gY3QRJvTq9dodxFbYyReZhCJ+2x6fOPIxujQ1veb53nk5dGhi pDvm4F2jgKJiZ32L2vwi0z+0ZS8phgP3B9kguAhTeg9+4k4JG0vXCzBOTf4bs0hQJ+hz ua/DHFp14546hOaeGM+nFrO7s6tSUnKvXH28bT8aGwt+MH1m2zVhf0dbyNlmXSQpmMf+ O2Hg== 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 j11si2213221pjs.73.2019.06.11.05.27.00; Tue, 11 Jun 2019 05:27:16 -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 S1728308AbfFKMQo convert rfc822-to-8bit (ORCPT + 99 others); Tue, 11 Jun 2019 08:16:44 -0400 Received: from szxga01-in.huawei.com ([45.249.212.187]:6935 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726713AbfFKMQn (ORCPT ); Tue, 11 Jun 2019 08:16:43 -0400 Received: from dggemi403-hub.china.huawei.com (unknown [172.30.72.56]) by Forcepoint Email with ESMTP id 542341CB09A22907BC29; Tue, 11 Jun 2019 20:16:42 +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:16:35 +0800 From: "Chengang (L)" To: Michal Hocko CC: "akpm@linux-foundation.org" , "vbabka@suse.cz" , "osalvador@suse.de" , "pavel.tatashin@microsoft.com" , "mgorman@techsingularity.net" , "rppt@linux.ibm.com" , "richard.weiyang@gmail.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: AdUgTpdGfX4K+yczTYe6f6nhJDDS/w== Date: Tue, 11 Jun 2019 12:16:35 +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 Michal >On Sun 09-06-19 17:10:28, 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, 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. >Could you describe the actual problem? Do we ever generate min_free_kbytes that would lead to unexpected reserves or is this trying to compensate for those values being configured from the userspace? If later why do we care at all? >Have you seen this to be an actual problem or is this mostly motivated by the code reading? I haven't seen an actual problem, and it's motivated by code reading. Users can configure this value through interface /proc/sys/vm/min_free_kbytes, so I think a bit precious is better. >> 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); >> unsigned long lowmem_pages = 0; >> struct zone *zone; >> unsigned long flags; >> -- >> 1.8.5.6 >> >-- >Michal Hocko >SUSE Labs