linux-kernel - Re: [PATCH] mm:Add watermark slope for high mark

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]

Date:   Fri, 24 Nov 2017 14:27:24 +0100
From:   Michal Hocko <mhocko@...nel.org>
To:     peter enderborg <peter.enderborg@...y.com>
Cc:     linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-mm@...ck.org, linux-fsdevel@...r.kernel.org,
        Jonathan Corbet <corbet@....net>,
        "Luis R . Rodriguez" <mcgrof@...nel.org>,
        Kees Cook <keescook@...omium.org>,
        Alex Deucher <alexander.deucher@....com>,
        "David S . Miller" <davem@...emloft.net>,
        Harry Wentland <Harry.Wentland@....com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Tony Cheng <Tony.Cheng@....com>,
        David Rientjes <rientjes@...gle.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Jan Kara <jack@...e.cz>,
        "Kirill A . Shutemov" <kirill.shutemov@...ux.intel.com>,
        Dave Jiang <dave.jiang@...el.com>,
        Jérôme Glisse <jglisse@...hat.com>,
        Ross Zwisler <ross.zwisler@...ux.intel.com>,
        Matthew Wilcox <willy@...ux.intel.com>,
        Hugh Dickins <hughd@...gle.com>,
        Johannes Weiner <hannes@...xchg.org>,
        Kemi Wang <kemi.wang@...el.com>,
        Vlastimil Babka <vbabka@...e.cz>,
        YASUAKI ISHIMATSU <yasu.isimatu@...il.com>,
        Nikolay Borisov <nborisov@...e.com>,
        Mel Gorman <mgorman@...e.de>,
        Pavel Tatashin <pasha.tatashin@...cle.com>,
        Linux API <linux-api@...r.kernel.org>
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 - https://lkml.org/lkml/2016/2/18/498 - 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
hard/unfeasible.
-- 
Michal Hocko
SUSE Labs