From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id DCA8AC54EBC for ; Thu, 12 Jan 2023 05:14:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236794AbjALFOc (ORCPT ); Thu, 12 Jan 2023 00:14:32 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47006 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235111AbjALFO1 (ORCPT ); Thu, 12 Jan 2023 00:14:27 -0500 Received: from 1wt.eu (wtarreau.pck.nerim.net [62.212.114.60]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id C940042E3C for ; Wed, 11 Jan 2023 21:14:25 -0800 (PST) Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id 30C5Dguk020122; Thu, 12 Jan 2023 06:13:42 +0100 Date: Thu, 12 Jan 2023 06:13:42 +0100 From: Willy Tarreau To: Arseniy Lesin Cc: linux-kernel@vger.kernel.org Subject: Re: [RESEND RFC] SIGOOM Proposal Message-ID: <20230112051342.GB19712@1wt.eu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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