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:27:24 +0100
From:   Michal Hocko <>
To:     peter enderborg <>
        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 Fri 24-11-17 14:12:56, peter enderborg wrote:
> 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.

How can a poor user know how to tune it when _we_ cannot do a qualified
guess and we do know all the implementation details.

Really, describe problems you are seeing with the current code and we
can talk about a proper fix or a heuristic when the fix is
Michal Hocko

Powered by blists - more mailing lists