linux-kernel - Re: How to make warn

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]

Message-ID: <20161020193034.GD27342@dhcp22.suse.cz>
Date:   Thu, 20 Oct 2016 21:30:34 +0200
From:   Michal Hocko <mhocko@...nel.org>
To:     Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
Cc:     akpm@...ux-foundation.org, hannes@...xchg.org, mgorman@...e.de,
        dave.hansen@...el.com, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org
Subject: Re: How to make warn_alloc() reliable?

On Thu 20-10-16 21:07:49, Tetsuo Handa wrote:
[...]
> By the way, regarding "making the direct reclaim path more deterministic"
> part, I wish that we can
> 
>   (1) introduce phased watermarks which varies based on stage of reclaim
>       operation (e.g. watermark_lower()/watermark_higher() which resembles
>       preempt_disable()/preempt_enable() but is propagated to other threads
>       when delegating operations needed for reclaim to other threads).
> 
>   (2) introduce dedicated kernel threads which perform only specific
>       reclaim operation, using watermark propagated from other threads
>       which performs different reclaim operation.
> 
>   (3) remove direct reclaim which bothers callers with managing correct
>       GFP_NOIO / GFP_NOFS / GFP_KERNEL distinction. Then, normal
>       ___GFP_DIRECT_RECLAIM callers can simply wait for
>       wait_event(get_pages_from_freelist() succeeds) rather than polling
>       with complicated short sleep. This will significantly save CPU
>       resource (especially when oom_lock is held) which is wasted by
>       activities by multiple concurrent direct reclaim.

As always, you are free to come up with patches with the proper
justification and convince people that those steps will help both the
regular case as well of those you are bothered with.
-- 
Michal Hocko
SUSE Labs