linux-kernel - Re: [PATCH 0/3 staging-next] android: Lowmemmorykiller task tree

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] [day] [month] [year] [list]

Date:   Mon, 20 Feb 2017 11:21:22 +0100
From:   Michal Hocko <mhocko@...nel.org>
To:     peter enderborg <peter.enderborg@...ymobile.com>
Cc:     devel@...verdev.osuosl.org,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-kernel@...r.kernel.org,
        Arve Hjønnevåg <arve@...roid.com>,
        Riley Andrews <riandrews@...roid.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        linux-mm@...ck.org
Subject: Re: [PATCH 0/3 staging-next] android: Lowmemmorykiller task tree

On Mon 13-02-17 16:42:42, peter enderborg wrote:
> On 02/10/2017 11:27 AM, Michal Hocko wrote:
> > [I have only now see this cover - it answers some of the questions I've
> >  had to specific patches. It would be really great if you could use git
> >  send-email to post patch series - it just does the right thing(tm)]
> >
> > On Thu 09-02-17 14:21:40, peter enderborg wrote:
> >> Lowmemorykiller efficiency problem and a solution.
> >>
> >> Lowmemorykiller in android has a severe efficiency problem. The basic
> >> problem is that the registered shrinker gets called very often without
> >>  anything actually happening.
> > Which is an inherent problem because lkml doesn't belong to shrinkers
> > infrastructure.
> 
> Not really what this patch address.  I see it as a problem with shrinker
> that there no slow-path-free (scan/count) where it should belong.
> This patch address a specific problem where lot of cpu are wasted
> in low memory conditions.

Let me repeat. The specific problem you are trying to solve is
_inherent_ to how the lmk is designed. Full stop.

-- 
Michal Hocko
SUSE Labs