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 X-Spam-Level: X-Spam-Status: No, score=-13.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 849E0C433ED for ; Wed, 5 May 2021 00:37:47 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 38603613CB for ; Wed, 5 May 2021 00:37:47 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 38603613CB Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 5F69E6B008A; Tue, 4 May 2021 20:37:46 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5A64F6B008C; Tue, 4 May 2021 20:37:46 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3D2B66B0092; Tue, 4 May 2021 20:37:46 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0156.hostedemail.com [216.40.44.156]) by kanga.kvack.org (Postfix) with ESMTP id 1CF526B008A for ; Tue, 4 May 2021 20:37:46 -0400 (EDT) Received: from smtpin10.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id D62A9A748 for ; Wed, 5 May 2021 00:37:45 +0000 (UTC) X-FDA: 78105314490.10.CA69425 Received: from mail-lf1-f44.google.com (mail-lf1-f44.google.com [209.85.167.44]) by imf05.hostedemail.com (Postfix) with ESMTP id 6FB58E000105 for ; Wed, 5 May 2021 00:37:41 +0000 (UTC) Received: by mail-lf1-f44.google.com with SMTP id x19so129358lfa.2 for ; Tue, 04 May 2021 17:37:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rE+67pf/2itGCrXRDqOt78tityf8/56CzXmtqalTs7Y=; b=oPjqJycdh906u/NKD96OF/32I8GkIKXWJvImxBVe8Uoi5eQH0eCxEmU1C14OFp77Bh 7Q0cLGd/hOMzojqrDn4N+h/krRVmuvkI/846O1BZJG6acacCSK6qRvH8kWCAw0IgRM2o tW70LTDJPlXiFxn+Onp+XUen2V3IVkqMFUZ7B20neSLbTJyPlWuIJLgM+YpmiPQ3zIUA kc8idKtZ5R86Yp4837IQvSnAO/r8OkY3shl3v0ueAglTxveiZ600ewUj216ssOQDZoWi COcs6/4gvKgeap02wOQj5e0w7c0XRY4BL7JWx7btEdKvqUOorT11BgEN8oY2OwmENhV1 yMtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rE+67pf/2itGCrXRDqOt78tityf8/56CzXmtqalTs7Y=; b=gs+bgolEMJknlRjnfQWZ7B0ksJZNTydbQnceacOfdeRxuWIP6OYrG9FAfHPRFU2fr9 Hev+6bwCI+ieSIZtQMTphzccyXIyNJ10sQ/a/ylQaSl0d6Jzz3XJURAGnl8rWTE6pX+H ii27NbmA/UsCgYuRnuEnT/Fh0kHgpjmLR4rHUp5cAzvQTkZHkYF3RghhVU0J50L6LZI9 dswiIxWtwn8UdMQ1ppHoraO97v3+lT3YEwBpadnru8q3A7tVOcIeatAKDWHjcBYLEfJ7 Rnx4APrggLF8f7NiGTMFd0tG3zDbll+N4rnlklZ5wRXWQL0qmhsg0TzH1z3taaqbNnRl 7FWA== X-Gm-Message-State: AOAM5302/BV+gD3eiEkyIkkstAw2O6CqbfEDoDSekowiKcKDf46WS9R1 KzpMqtcdkakEXYtDZn15m+G0NwJ2ko96dp9UNPTXNA== X-Google-Smtp-Source: ABdhPJzcggYN+sQarkF2p9KMUd3IdfrvBTmP3Ycic01HaxyCcS1xXBgbGOrpUlrf3u49WLTtzDu+21oBxRurC6ywBew= X-Received: by 2002:a05:6512:208b:: with SMTP id t11mr16611191lfr.358.1620175063595; Tue, 04 May 2021 17:37:43 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Shakeel Butt Date: Tue, 4 May 2021 17:37:32 -0700 Message-ID: Subject: Re: [RFC] memory reserve for userspace oom-killer To: Michal Hocko Cc: Johannes Weiner , Roman Gushchin , Linux MM , Andrew Morton , Cgroups , David Rientjes , LKML , Suren Baghdasaryan , Greg Thelen , Dragos Sbirlea , Priya Duraisamy Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 6FB58E000105 Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=google.com header.s=20161025 header.b=oPjqJycd; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf05.hostedemail.com: domain of shakeelb@google.com designates 209.85.167.44 as permitted sender) smtp.mailfrom=shakeelb@google.com X-Rspamd-Server: rspam04 X-Stat-Signature: yt6qc85dcitop4xkjun5gg71m1uywrow Received-SPF: none (google.com>: No applicable sender policy available) receiver=imf05; identity=mailfrom; envelope-from=""; helo=mail-lf1-f44.google.com; client-ip=209.85.167.44 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1620175061-400462 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, Apr 21, 2021 at 7:29 AM Michal Hocko wrote: > [...] > > > What if the pool is depleted? > > > > This would mean that either the estimate of mempool size is bad or > > oom-killer is buggy and leaking memory. > > > > I am open to any design directions for mempool or some other way where > > we can provide a notion of memory guarantee to oom-killer. > > OK, thanks for clarification. There will certainly be hard problems to > sort out[1] but the overall idea makes sense to me and it sounds like a > much better approach than a OOM specific solution. > > > [1] - how the pool is going to be replenished without hitting all > potential reclaim problems (thus dependencies on other all tasks > directly/indirectly) yet to not rely on any background workers to do > that on the task behalf without a proper accounting etc... > -- I am currently contemplating between two paths here: First, the mempool, exposed through either prctl or a new syscall. Users would need to trace their userspace oom-killer (or whatever their use case is) to find an appropriate mempool size they would need and periodically refill the mempools if allowed by the state of the machine. The challenge here is to find a good value for the mempool size and coordinating the refilling of mempools. Second is a mix of Roman and Peter's suggestions but much more simplified. A very simple watchdog with a kill-list of processes and if userspace didn't pet the watchdog within a specified time, it will kill all the processes in the kill-list. The challenge here is to maintain/update the kill-list. I would prefer the direction which oomd and lmkd are open to adopt. Any suggestions?