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.4 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,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 24EA9C11F65 for ; Wed, 30 Jun 2021 18:51:50 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id B488B6142C for ; Wed, 30 Jun 2021 18:51:49 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B488B6142C 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 DBB4E8D01C0; Wed, 30 Jun 2021 14:51:48 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D6B498D01A2; Wed, 30 Jun 2021 14:51:48 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C0BD88D01C0; Wed, 30 Jun 2021 14:51:48 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0194.hostedemail.com [216.40.44.194]) by kanga.kvack.org (Postfix) with ESMTP id 99A958D01A2 for ; Wed, 30 Jun 2021 14:51:48 -0400 (EDT) Received: from smtpin32.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 6F1EC1EA0F for ; Wed, 30 Jun 2021 18:51:48 +0000 (UTC) X-FDA: 78311284296.32.F90E9DF Received: from mail-yb1-f177.google.com (mail-yb1-f177.google.com [209.85.219.177]) by imf05.hostedemail.com (Postfix) with ESMTP id 24D2D5000376 for ; Wed, 30 Jun 2021 18:51:48 +0000 (UTC) Received: by mail-yb1-f177.google.com with SMTP id p15so6648810ybe.6 for ; Wed, 30 Jun 2021 11:51:47 -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=OoBBBmTYhX92RzZNabmusTXUOu2aNFXN3aBTat+PLK8=; b=daVFivh6Fo86bv1Wet55ewJd8qrwOGm5ItRJ1EZ981lvQzwAQtcVcr528OLJT0AUrZ uPGqoruHC6FgqMwQmnVIHpZsWdvftIcPQiJTh36OpuWLYufqvDrGcZmo1EriiSuNz4e6 ewBX7MlZFA4irWaGblZqYZZL6XX8cP6V0WPRPIeLkHoOuXvNqH68Y1t2W+60n5UrL1q4 Lec3YL7rigYCRThrHT1oeZV47Av1+9FbORqyDORYJ3Va82PSX3CP1/IyYPkUPB2mxynQ H7zh/GZIicKa7n04VUE/s7aCo9EVClCt7RAs7JZHCQdbpUCf1HZfGEyHMQ6gb2JalHzd t43Q== 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=OoBBBmTYhX92RzZNabmusTXUOu2aNFXN3aBTat+PLK8=; b=d56z4bHoeGDXuiriZWv/CP0BvMw+0j1Vzvls54knrZVvHtxwkrIIpow9P6r4zt3Q2T JeFpom/As0zer91yAKrWvF514E7DD52kJKMsFkPRmUEBvah+iq1/NSMBeLutXl0ls+pK HrHlKzJ34GiLTi34PFI7ihV3MmxnT22Z/HK6J7jqp3GaU0Q5ERH28lOGC/Mfe8wiK4NK OPNsKLF9O6EKPC4qCOoWTO82jij0YFLWpfwqCUx0iiuolgjcq6jHO8BUitYSAZatGIWd 6PSpGnlVG8tzAQkWm/qvX7BJty3Sot+BiXABO/9D+2mlQGwYzmBTZLppZwslm3uuMVfl gklw== X-Gm-Message-State: AOAM530g22c+qjoH4GkX5aGoxALmhF1zL/bWTpdHvJn8jv4jmxC+HlWX UZ+IAvsodZtsGafupbVtLP8MEdRcJpRxU+JA5DYc/g== X-Google-Smtp-Source: ABdhPJyKK+cDCxlBFy6A3X6BxKdCqBpHbAJ2DvVH7Xvrh+mJ3LBI5f4jNcPY6g5WKChTsyfqL2YzAZxR02WbxRbPTiU= X-Received: by 2002:a25:d913:: with SMTP id q19mr48111254ybg.397.1625079107259; Wed, 30 Jun 2021 11:51:47 -0700 (PDT) MIME-Version: 1.0 References: <20210623192822.3072029-1-surenb@google.com> In-Reply-To: From: Suren Baghdasaryan Date: Wed, 30 Jun 2021 11:51:36 -0700 Message-ID: Subject: Re: [PATCH 1/1] mm: introduce process_reap system call To: Andy Lutomirski Cc: Andrew Morton , Michal Hocko , Michal Hocko , David Rientjes , Matthew Wilcox , Johannes Weiner , Roman Gushchin , Rik van Riel , Minchan Kim , Christian Brauner , Christoph Hellwig , Oleg Nesterov , David Hildenbrand , Jann Horn , Shakeel Butt , Tim Murray , Linux API , Linux-MM , LKML , Android Kernel Team Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 24D2D5000376 X-Stat-Signature: yy4kr46bw437apw96s63hrfesj4ohadx Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=google.com header.s=20161025 header.b=daVFivh6; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf05.hostedemail.com: domain of surenb@google.com designates 209.85.219.177 as permitted sender) smtp.mailfrom=surenb@google.com X-HE-Tag: 1625079108-396293 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, Jun 30, 2021 at 11:26 AM Andy Lutomirski wrote: > > On Wed, Jun 23, 2021 at 12:28 PM Suren Baghdasaryan wrote: > > > > In modern systems it's not unusual to have a system component monitoring > > memory conditions of the system and tasked with keeping system memory > > pressure under control. One way to accomplish that is to kill > > non-essential processes to free up memory for more important ones. > > Examples of this are Facebook's OOM killer daemon called oomd and > > Android's low memory killer daemon called lmkd. > > For such system component it's important to be able to free memory > > quickly and efficiently. Unfortunately the time process takes to free > > up its memory after receiving a SIGKILL might vary based on the state > > of the process (uninterruptible sleep), size and OPP level of the core > > the process is running. A mechanism to free resources of the target > > process in a more predictable way would improve system's ability to > > control its memory pressure. > > Introduce process_reap system call that reclaims memory of a dying process > > from the context of the caller. This way the memory in freed in a more > > controllable way with CPU affinity and priority of the caller. The workload > > of freeing the memory will also be charged to the caller. > > The operation is allowed only on a dying process. > > At the risk of asking a potentially silly question, should this just > be a file in procfs? Hmm. I guess it's doable if procfs will not disappear too soon before memory is released... syscall also supports parameters, in this case flags can be used in the future to support PIDs in addition to PIDFDs for example. Before looking more in that direction, a silly question from my side: why procfs interface would be preferable to a syscall? > > Also, please consider removing all mention of the word "reap" from the > user API. For better or for worse, "reap" in UNIX refers to what > happens when a dead task gets wait()ed. I sincerely wish I could go > back in time and gently encourage whomever invented that particular > abomination to change their mind, but my time machine doesn't work. I see. Thanks for the note. How about process_mem_release() and replacing reap with release everywhere? > > --Andy