linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "Chengang (L)" <cg.chen@huawei.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: "akpm@linux-foundation.org" <akpm@linux-foundation.org>,
	"vbabka@suse.cz" <vbabka@suse.cz>,
	"osalvador@suse.de" <osalvador@suse.de>,
	"pavel.tatashin@microsoft.com" <pavel.tatashin@microsoft.com>,
	"mgorman@techsingularity.net" <mgorman@techsingularity.net>,
	"rppt@linux.ibm.com" <rppt@linux.ibm.com>,
	"richard.weiyang@gmail.com" <richard.weiyang@gmail.com>,
	"alexander.h.duyck@linux.intel.com"
	<alexander.h.duyck@linux.intel.com>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] mm: align up min_free_kbytes to multipy of 4
Date: Tue, 11 Jun 2019 12:16:35 +0000	[thread overview]
Message-ID: <D27E5778F399414A8B5D5F672064BAD8B3E5FB7B@dggemi529-mbs.china.huawei.com> (raw)

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 <cg.chen@huawei.com>
>> ---
>>  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


             reply	other threads:[~2019-06-11 12:17 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-11 12:16 Chengang (L) [this message]
2019-06-11 13:08 ` Michal Hocko
  -- strict thread matches above, loose matches on Subject: below --
2019-06-11 12:10 Chengang (L)
2019-06-09  9:10 ChenGang
2019-06-09 14:53 ` Wei Yang
2019-06-10  7:26 ` Michal Hocko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=D27E5778F399414A8B5D5F672064BAD8B3E5FB7B@dggemi529-mbs.china.huawei.com \
    --to=cg.chen@huawei.com \
    --cc=akpm@linux-foundation.org \
    --cc=alexander.h.duyck@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@techsingularity.net \
    --cc=mhocko@kernel.org \
    --cc=osalvador@suse.de \
    --cc=pavel.tatashin@microsoft.com \
    --cc=richard.weiyang@gmail.com \
    --cc=rppt@linux.ibm.com \
    --cc=vbabka@suse.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox