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 6BFFFC3DA7D for ; Thu, 5 Jan 2023 17:49:02 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234985AbjAERtB (ORCPT ); Thu, 5 Jan 2023 12:49:01 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57588 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234650AbjAERsz (ORCPT ); Thu, 5 Jan 2023 12:48:55 -0500 X-Greylist: delayed 1229 seconds by postgrey-1.37 at lindbergh.monkeyblade.net; Thu, 05 Jan 2023 09:48:51 PST Received: from sr40.hostlife.net (sr40.hostlife.net [185.43.220.19]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1149B4EC8A for ; Thu, 5 Jan 2023 09:48:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=hardclanz.org; s=default; h=To:From:Subject:Message-Id:Date:Content-Type: Content-Transfer-Encoding:Mime-Version:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=zeOrvwIxvJz40GHeZdY4SXewmPJFYtfrDzHK/M/sG+c=; b=RvYtUxLEwxfLqXkuO5QBwfwjYv Jdm1jPwpyL5K7x0gwRYVoxwPHHEME4QCvtG+hYDXfQjySbv8CLX2Udiv/prODMboyJRUo3ZT9uVAg SeHh8evJKAsAdUtyMZ5QNzByYZNfgbTvDiUHZPqA0I2qOfIr4y9uD98sQFS8JVitWhNh3UCz6MVmW bZTA1Njg5DcvxSAFVyhfROHD4SydtJuQ1kBxTV0VcHWz2MvhsCH8RdV+umuZQFXv6HMOHxqaDKULa +Du1deS5YWcFHlhDwKDOJDLoUcSMWdz8se4+vJofz5/J9T4ubMaColXsxr5BapHhMgKVzZPNDztYM NNRqs70g==; Received: from [109.225.40.181] (port=36788 helo=localhost) by sr40.hostlife.net with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.95) (envelope-from ) id 1pDU2O-006rXo-GY for linux-kernel@vger.kernel.org; Thu, 05 Jan 2023 18:28:19 +0100 Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Thu, 05 Jan 2023 20:28:19 +0300 Message-Id: Subject: [RFC] SIGOOM proposal From: "Arseniy Lesin" To: X-Mailer: aerc 0.12.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sr40.hostlife.net X-AntiAbuse: Original Domain - vger.kernel.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - hardclanz.org X-Get-Message-Sender-Via: sr40.hostlife.net: authenticated_id: emptiedsoul@hardclanz.org X-Authenticated-Sender: sr40.hostlife.net: emptiedsoul@hardclanz.org X-Source: X-Source-Args: X-Source-Dir: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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.