linux-kernel - Re: [PATCH 3/5] mm/vmalloc.c: correct lazy_max

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20160922123736.GA11204@dhcp22.suse.cz>
Date:   Thu, 22 Sep 2016 14:37:36 +0200
From:   Michal Hocko <mhocko@...nel.org>
To:     zijun_hu <zijun_hu@...o.com>
Cc:     David Rientjes <rientjes@...gle.com>, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org, zijun_hu@....com,
        Andrew Morton <akpm@...ux-foundation.org>, tj@...nel.org,
        mingo@...nel.org, iamjoonsoo.kim@....com,
        mgorman@...hsingularity.net
Subject: Re: [PATCH 3/5] mm/vmalloc.c: correct lazy_max_pages() return value

On Thu 22-09-16 09:13:50, zijun_hu wrote:
> On 09/22/2016 08:35 AM, David Rientjes wrote:
[...]
> > The intent is as it is implemented; with your change, lazy_max_pages() is 
> > potentially increased depending on the number of online cpus.  This is 
> > only a heuristic, changing it would need justification on why the new 
> > value is better.  It is opposite to what the comment says: "to be 
> > conservative and not introduce a big latency on huge systems, so go with
> > a less aggressive log scale."  NACK to the patch.
> > 
> my change potentially make lazy_max_pages() decreased not increased, i seems
> conform with the comment
> 
> if the number of online CPUs is not power of 2, both have no any difference
> otherwise, my change remain power of 2 value, and the original code rounds up
> to next power of 2 value, for instance
> 
> my change : (32, 64] -> 64
> 	     32 -> 32, 64 -> 64
> the original code: [32, 63) -> 64
>                    32 -> 64, 64 -> 128

You still completely failed to explain _why_ this is an improvement/fix
or why it matters. This all should be in the changelog.

-- 
Michal Hocko
SUSE Labs