linux-kernel - Re: [PATCH] mm: introduce oom_kill

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:   Mon, 9 Nov 2020 07:39:33 -0800
From:   Minchan Kim <minchan@...nel.org>
To:     Michal Hocko <mhocko@...e.com>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        LKML <linux-kernel@...r.kernel.org>,
        linux-mm <linux-mm@...ck.org>
Subject: Re: [PATCH] mm: introduce oom_kill_disable sysctl knob

On Mon, Nov 09, 2020 at 08:37:06AM +0100, Michal Hocko wrote:
> On Fri 06-11-20 12:32:38, Minchan Kim wrote:
> > It's hard to have some tests to be supposed to work under heavy
> > memory pressure(e.g., injecting some memory hogger) because
> > out-of-memory killer easily kicks out one of processes so system
> > is broken or system loses the memory pressure state since it has
> > plenty of free memory soon so.
> 
> I do not follow the reasoning here. So you want to test for a close to
> no memory available situation and the oom killer stands in the way
> because it puts a relief?

Yub, technically, I'd like to have consistent memory pressure to cause
direct reclaims on proesses on the system and swapping in/out.

> 
> > Even though we could mark existing process's oom_adj to -1000,
> > it couldn't cover upcoming processes to be forked for the job.
> 
> Why?

Thing is the system has out-of-control processes created on demand.
so only option to prevent OOM is echo -1000 > `pidof the process`
since they are forked. However, I have no idea when they are forked
so should race with OOM with /proc polling and OOM is frequently
ahead of me.

> 
> > This knob is handy to keep system memory pressure.
> 
> This sounds like a very dubious reason to introduce a knob to cripple
> the system.
> 
> I can see some reason to control the oom handling policy because the
> effect of the oom killer is really disruptive but a global on/off switch
> sounds like a too coarse interface. Really what kind of production
> environment would ever go with oom killer disabled completely?

I don't think shipping production system will use it. It would be
just testing only option.
My intention uses such heavy memory load to see various system behaviors
before the production launching because it usually happens in real workload
once we shipped but hard to generate such a corner case without artificial
memory pressure.

Any suggestion?