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;
Date:   Thu, 12 Jan 2023 06:13:42 +0100
From:   Willy Tarreau <w@1wt.eu>
To:     Arseniy Lesin <emptiedsoul@hardclanz.org>
Cc:     linux-kernel@vger.kernel.org
Subject: Re: [RESEND RFC] SIGOOM Proposal
Message-ID: <20230112051342.GB19712@1wt.eu>
References: <CPPXX7JYJGIE.3F2R53GC3ULGZ@hardclanz>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CPPXX7JYJGIE.3F2R53GC3ULGZ@hardclanz>
User-Agent: Mutt/1.10.1 (2018-07-13)
Precedence: bulk

Hello,

On Thu, Jan 12, 2023 at 07:51:45AM +0300, Arseniy Lesin wrote:
> 2.1. The SIGOOM Signal
> ------------------
> 
> I propose the addition of new signal: SIGOOM (Out-Of-Memory SIGnal) 
> 
> 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! 

Do this simpler, let userspace configure the signal it wants to
receive for this via a new prctl(PR_SET_OOMSIG) and this would allow
each process to voluntarily declare this intended behavior and the
associated signal at the same time. There are already other comparable
mechanisms existing there (signal to receive on parent's death, or on
memory error for example).

Willy