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  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]
Date:   Fri, 24 Nov 2017 14:12:56 +0100
From:   peter enderborg <>
To:     Michal Hocko <>
CC:     <>, <>,
        <>, <>,
        Jonathan Corbet <>,
        "Luis R . Rodriguez" <>,
        Kees Cook <>,
        Alex Deucher <>,
        "David S . Miller" <>,
        Harry Wentland <>,
        "Greg Kroah-Hartman" <>,
        Tony Cheng <>,
        David Rientjes <>,
        Andrew Morton <>,
        Jan Kara <>,
        "Kirill A . Shutemov" <>,
        Dave Jiang <>,
        Jérôme Glisse <>,
        Ross Zwisler <>,
        Matthew Wilcox <>,
        "Hugh Dickins" <>,
        Johannes Weiner <>,
        Kemi Wang <>,
        Vlastimil Babka <>,
        Nikolay Borisov <>,
        Mel Gorman <>,
        Pavel Tatashin <>,
        Linux API <>
Subject: Re: [PATCH] mm:Add watermark slope for high mark

On 11/24/2017 11:14 AM, Michal Hocko wrote:
> On Fri 24-11-17 11:07:07, Peter Enderborg wrote:
>> When tuning the watermark_scale_factor to reduce stalls and compactions
>> the high mark is also changed, it changed a bit too much. So this
>> patch introduces a slope that can reduce this overhead a bit, or
>> increase it if needed.
> This doesn't explain what is the problem, why it is a problem and why we
> need yet another tuning to address it. Users shouldn't really care about
> internal stuff like watermark tuning for each watermark independently.
> This looks like a gross hack. Please start over with the problem
> description and then we can move on to an approapriate fix. Piling up
> tuning knobs to workaround problems is simply not acceptable.

In the original patch - - had a

discussion about small systems with 8GB RAM. In the handheld world, that's
a lot of RAM. However, the magic number 2 used in the present algorithm
is out of the blue. Compaction problems are the same for both small and
big. So small devices also need to increase watermark to
get compaction to work and reduce direct reclaims. Changing the low watermark
makes direct reclaim rate drop a lot. But it will cause kswap to work more,
and that has a negative impact. Lowering the gap will smooth out the kswap
workload to suite embedded devices a lot better. This can be addressed by
reducing the high watermark using the slope patch herein. Im sort of understand
your opinion on user knobs, but hard-coded magic numbers are even worse.

Powered by blists - more mailing lists