Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Thu, 9 Jan 2020 12:56:33 +0100
From:   Michal Hocko <mhocko@kernel.org>
To:     Pavel Machek <pavel@ucw.cz>
Cc:     kernel list <linux-kernel@vger.kernel.org>,
        Andrew Morton <akpm@osdl.org>, linux-mm@kvack.org,
        akpm@linux-foundation.org
Subject: Re: OOM killer not nearly agressive enough?
Message-ID: <20200109115633.GR4951@dhcp22.suse.cz>
References: <20200107204412.GA29562@amd>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200107204412.GA29562@amd>
User-Agent: Mutt/1.12.2 (2019-09-21)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Tue 07-01-20 21:44:12, Pavel Machek wrote:
> Hi!
> 
> I updated my userspace to x86-64, and now chromium likes to eat all
> the memory and bring the system to standstill.
> 
> Unfortunately, OOM killer does not react:
> 
> I'm now running "ps aux", and it prints one line every 20 seconds or
> more. Do we agree that is "unusable" system? I attempted to do kill
> from other session.

Does sysrq+f help?

> Do we agree that OOM killer should have reacted way sooner?

This is impossible to answer without knowing what was going on at the
time. Was the system threshing over page cache/swap? In other words, is
the system completely out of memory or refaulting the working set all
the time because it doesn't fit into memory?

> Is there something I can tweak to make it behave more reasonably?

PSI based early OOM killing might help. See https://github.com/facebookincubator/oomd
-- 
Michal Hocko
SUSE Labs