Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Date:   Thu, 12 Jan 2023 07:51:45 +0300
Message-Id: <CPPXX7JYJGIE.3F2R53GC3ULGZ@hardclanz>
Subject: [RESEND RFC] SIGOOM Proposal
From:   "Arseniy Lesin" <emptiedsoul@hardclanz.org>
To:     <linux-kernel@vger.kernel.org>
Precedence: bulk


1. Introduction
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

AFAIK, majority of linux-running machines are configured to overcommit
memory -- so, memory needs of every process are always pleased. However,
in the Out-Of-Memory condition we repay cruely -- by _killing_ the most
memory-hungry process.=20

Dealing with OOM was always questionable -- kernel-space OOM-killer
often works as the last resort -- system can hang for a pretty long time
(especially when using swap) before it resolves the OOM condition.

User-space OOM-killers solve this problem _partially_ -- they can _kill_
such processes preventively or even display nice GUI prompt for user.

However, the key problem persists -- we can only _kill_ unaware process,
possibly causing valuable data loss. There is no way to tell process: "You
are causing system OOM, release memory or you will be terminated forcefully=
"!

2. Proposal
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

2.1. The SIGOOM Signal
------------------

I propose the addition of new signal: SIGOOM (Out-Of-Memory SIGnal)=20

This signal is intended to be sent to the most memory-hungry process(es)
in order to give process a chance to release memory used for
non-valuable data (for example, browser can unload tabs, that are
currently not in use, assuming tabs are not separate processes) or to
write down valuable data and exit gracefully (for example, some
graphical editor).

Some applications can even set up a poll for OOM event by using signalfd

Default action: 	IGNORE
Proposed senders: 	kernel- and user-space OOM-killers

The technical detail of this addition is a bit unpleasant: there is
actually no room for new signals!=20

Numbers 1-31 are already assigned, every signal with number > SIGRTMIN=20
(currently 32) is considered realtime and queued accordingly.=20

Adding SIGOOM as signal #32 by shifting SIGRTMIN to 33 can do a trick,
but this will almost certainly break compatibility (namely, with glibc
threading)

I propose adding SIGOOM as signal #65 (after SIGRTMAX), but we should
clarify some checks in kernel/signal.c (possibly in other places too,
where signal number is tested against being realtime) and possibly add a
such-like macro:

#define SIG_IS_REALTIME(signum) (((signum) > SIGRTMIN) && ((signum) < SIGRT=
MAX))

I expect your comments on this topic very much, thanks in advance.

2.2. Adjusting kernel oom-killer to use SIGOOM
----------------------------------------------

Since we now have a way to inform process of it's memory utilization we
can try to send process SIGOOM signal first (if process set up handler
or poll for it) and only then kill it.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

I will try to prepare a patchset for kernel in next couple of weeks.
Also going to create some patches for user-space oom-killers (sd-oomd,
meta's oomd) and propose a new system call for those (it is not as
important, so i decided not to include it for this RFC).

I invite all interested to discuss this RFC here on list, or you can
catch me on #linux IRC channel (libera network) tonight (nick:
emptiedsoul)

THX for reading, and again, thanks in advance for your comments.