Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp2910425ybi; Mon, 10 Jun 2019 00:27:37 -0700 (PDT) X-Google-Smtp-Source: APXvYqyI1u9xSO0ph5irppbFLLLdf5+LaU5yQzMA2NHiTUekEOitglF2z1uyE0/JXMcJjaBzFhIr X-Received: by 2002:aa7:81cc:: with SMTP id c12mr65505868pfn.139.1560151657049; Mon, 10 Jun 2019 00:27:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1560151657; cv=none; d=google.com; s=arc-20160816; b=X1LIR82Dl/v3Di+o0FhgYfAns4pfIZ/CeqOsWVw6uSe6ePl+p09zx18ZwaQDhz3c6R PuHFmY1ozfUiN42/E48L2ZA3lV4gCJijv7l5kTwtamhPKjiyCNaGXs48Z920Hgxkns+y PdPKsOob1eBd8yFIRSmI4b9WPBAUM77fZceBTvEvYrpjRrOcpzqJY4DHUAOF86lKq4f8 O7gj3XktS22T/x4EbuJvpH0Eu9d1nPkstNML5/+W/henrsUBSqkmgPX69Nlrvd0dP8pT 5rnled6dM9GrUGyuFjU6DoBOR5OGJ9UWjZhGouunryxEnw3cCn6f8qqBRHoWtVWtBSwM AjVw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=/ktFxWC8f5VaA3fAqx8/BgVwk4wAVIvuEdrQ3jObty8=; b=WdGXb5gYJBiGDZJhG/lGaFKg7f2HCWb73Ut3mzobvYjjYODqzXo4srhJLk/w5Cjty0 2/Y3B9ateTW90SpXa5SBW7NhpUB1APGLLgdNvoOTyJK7U0CUikQcNAZ8EtiuqD3jU1l0 5kSwTo7GYpq7D9BivEtrDY0bGIWodupazQwWrTf+5DYLpLImcjZ9uOy2wxFmfJevF7W5 3CzPMXVBfedKM/Cp8ZqnlMXkv4Fucfy8OpWZz+FQWcFSMV/DdC2vjXLTOV/u/gLfH2IJ UBv+ADaEOavsB0xWDnvg0ehaqdG/pGOFurRhgVjhSA98rc1oj8qgPTgGp0cAV7/0lco7 192A== 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=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 3si9172037plz.57.2019.06.10.00.27.22; Mon, 10 Jun 2019 00:27:37 -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=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387991AbfFJH1A (ORCPT + 99 others); Mon, 10 Jun 2019 03:27:00 -0400 Received: from mx2.suse.de ([195.135.220.15]:59628 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S2387982AbfFJH06 (ORCPT ); Mon, 10 Jun 2019 03:26:58 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 6B06FAE5A; Mon, 10 Jun 2019 07:26:56 +0000 (UTC) Date: Mon, 10 Jun 2019 09:26:55 +0200 From: Michal Hocko To: ChenGang 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 Message-ID: <20190610072655.GB30967@dhcp22.suse.cz> References: <1560071428-24267-1-git-send-email-cg.chen@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1560071428-24267-1-git-send-email-cg.chen@huawei.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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? > 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