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 64481C07E9A for ; Mon, 12 Jul 2021 18:39:25 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 4BA07611CB for ; Mon, 12 Jul 2021 18:39:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235978AbhGLSmM (ORCPT ); Mon, 12 Jul 2021 14:42:12 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58024 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230477AbhGLSmL (ORCPT ); Mon, 12 Jul 2021 14:42:11 -0400 Received: from mail-yb1-xb29.google.com (mail-yb1-xb29.google.com [IPv6:2607:f8b0:4864:20::b29]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3596EC0613DD for ; Mon, 12 Jul 2021 11:39:22 -0700 (PDT) Received: by mail-yb1-xb29.google.com with SMTP id a16so30580601ybt.8 for ; Mon, 12 Jul 2021 11:39:22 -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=Ho/Rg+kWQBT3g0s4WUPaNn7FgGVbD55gWWoqdPMQr/Y=; b=cZPpg3JNJSZsY/M2IDNiSomK8Bf2SHwo5L67jNM4nDO+nxG8cUbpV2UP/O1+xGbJJQ N3yHipF+FIfrgTJWdYILf8fxMwvIVBaoaYn+UaFaoIBpviZL0ck9f+OvxI2rj5X6igu2 9MOcR63E99EXetd822cmkj3AislCImB4DqhqpLJQpS1xq4z6p3vJnKixW2tJYI5oCcwR 5Uo+ye3cBtP++OBYZEpkuTZ/vXgj6CkeDTkVV3MXb65iOlqhkGUbYAEA8JlatVoA+wCW 3ifxHwcoVqscoVRkxNZRWTH4HEgOkH/YoxoQVHfm7bIpd/cdTorb/vS+UG9NHgjbZmNd FOqw== 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=Ho/Rg+kWQBT3g0s4WUPaNn7FgGVbD55gWWoqdPMQr/Y=; b=Pldfsh80M/C4bBzqRH/Mxl/YFLfwBv4eK+nG+zkf8E/TqN5Yqw4+a+alQ0GcLb3kmm kiGxBiGHhz3Vsa/+KwNMs8Xdqgs8RisnMPtumvREii40sSBzEheEAx/3/3SxPV7ljBLQ ua8ChhmgBeNsqF8KsYprDq9MNQuYx9nV+CBwLuq+iRDynGTEttAnXoFHDgWPE5HOdR9y opz4bFLDMsNmt2+l7aeqXgUXxGVd51YheMqwLzmdTNq6rQlF1qxICKEJm8ef0K4bXgQg /+7hzPFuL5M263Lznm9MuAgKDfqPebQrRTsJ1IzrrIM5vMtTcJMGpJxJOdKKdEWX38Ml fc6w== X-Gm-Message-State: AOAM532KHwZJss1Tb16BwGjwTa/nctO5aaNGBCvSewzAaTtUcO3EWuzz C9CPtyjMWEeFGKF06rIJ0s0wqmkqOcTwYCdp1k9K7A== X-Google-Smtp-Source: ABdhPJw2Wd3lkFyCSaKE1R+Gmhq+CNRD3Sbcu3fX63Ehl7Ot2KbpAfryBXz7PS6nVCtlP1bo0qoVMzukbaU1xdsEhdc= X-Received: by 2002:a25:71c4:: with SMTP id m187mr414827ybc.397.1626115161245; Mon, 12 Jul 2021 11:39:21 -0700 (PDT) MIME-Version: 1.0 References: <20210623192822.3072029-1-surenb@google.com> <87sg0qa22l.fsf@oldenburg.str.redhat.com> <87wnq1z7kl.fsf@oldenburg.str.redhat.com> In-Reply-To: From: Suren Baghdasaryan Date: Mon, 12 Jul 2021 11:39:10 -0700 Message-ID: Subject: Re: [PATCH 1/1] mm: introduce process_reap system call To: Jan Engelhardt Cc: Florian Weimer , 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 , kernel-team Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jul 12, 2021 at 5:51 AM Jan Engelhardt wrote: > > > On Thursday 2021-07-08 08:05, Suren Baghdasaryan wrote: > >> > >> That explains very clearly the requirement, but it raises the question > >> why this isn't an si_code flag for rt_sigqueueinfo, reusing the existing > >> system call. > > > >I think you are suggesting to use sigqueue() to deliver the signal and > >perform the reaping when a special value accompanies it. This would be > >somewhat similar to my early suggestion to use a flag in > >pidfd_send_signal() (see: > >https://lore.kernel.org/patchwork/patch/1060407) to implement memory > >reaping which has another advantage of operation on PIDFDs instead of > >PIDs which can be recycled. > >kill()/pidfd_send_signal()/sigqueue() are supposed to deliver the > >signal and return without blocking. Changing that behavior was > >considered unacceptable in these discussions. > > The way I understood the request is that a userspace program (or perhaps two, > if so desired) should issue _two_ calls, one to deliver the signal, > one to perform the reap portion: > > uinfo.si_code = SI_QUEUE; > sigqueue(pid, SIGKILL, &uinfo); > uinfo.si_code = SI_REAP; > sigqueue(pid, SIGKILL, &uinfo); This approach would still lead to the same discussion: by design, sigqueue/kill/pidfd_send_signal deliver the signal but do not wait for the signal to be processed by the recipient. Changing that would be a behavior change. Therefore we would have to follow this pattern and implement memory reaping in an asynchronous manner using a kthread/workqueue and it won't be done in the context of the calling process. This is undesirable because we lose the ability to control priority and cpu affinity for this operation and work won't be charged to the caller. That's why the proposed syscall performs memory reaping in the caller's context and blocks until the operation is done. In this proposal, your sequence looks like this: pidfd_send_signal(pidfd, SIGKILL, NULL, 0); process_reap(pidfd, 0); except we decided to rename process_reap() to process_mrelease() in the next revision. 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 C5644C07E99 for ; Mon, 12 Jul 2021 18:39:25 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 467FE61166 for ; Mon, 12 Jul 2021 18:39:25 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 467FE61166 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 3C4566B0092; Mon, 12 Jul 2021 14:39:25 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3748B6B0095; Mon, 12 Jul 2021 14:39:25 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 216146B0096; Mon, 12 Jul 2021 14:39:25 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0166.hostedemail.com [216.40.44.166]) by kanga.kvack.org (Postfix) with ESMTP id EE4536B0092 for ; Mon, 12 Jul 2021 14:39:24 -0400 (EDT) Received: from smtpin08.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 76EB9181D553B for ; Mon, 12 Jul 2021 18:39:22 +0000 (UTC) X-FDA: 78354798564.08.CDDA3B0 Received: from mail-yb1-f172.google.com (mail-yb1-f172.google.com [209.85.219.172]) by imf04.hostedemail.com (Postfix) with ESMTP id 2FEE1500009F for ; Mon, 12 Jul 2021 18:39:22 +0000 (UTC) Received: by mail-yb1-f172.google.com with SMTP id p22so30590668yba.7 for ; Mon, 12 Jul 2021 11:39:22 -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=Ho/Rg+kWQBT3g0s4WUPaNn7FgGVbD55gWWoqdPMQr/Y=; b=cZPpg3JNJSZsY/M2IDNiSomK8Bf2SHwo5L67jNM4nDO+nxG8cUbpV2UP/O1+xGbJJQ N3yHipF+FIfrgTJWdYILf8fxMwvIVBaoaYn+UaFaoIBpviZL0ck9f+OvxI2rj5X6igu2 9MOcR63E99EXetd822cmkj3AislCImB4DqhqpLJQpS1xq4z6p3vJnKixW2tJYI5oCcwR 5Uo+ye3cBtP++OBYZEpkuTZ/vXgj6CkeDTkVV3MXb65iOlqhkGUbYAEA8JlatVoA+wCW 3ifxHwcoVqscoVRkxNZRWTH4HEgOkH/YoxoQVHfm7bIpd/cdTorb/vS+UG9NHgjbZmNd FOqw== 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=Ho/Rg+kWQBT3g0s4WUPaNn7FgGVbD55gWWoqdPMQr/Y=; b=Ee/MkOqFfISZb+brte7sZtBO0f9iubdZ0gpzHSBc0e8FZHrAmBTlZG9QQKIME5OAbV zOJ/updUkrpRK+jPh6nztc7h6MOH5moash2t5WP1565RQvcGeWoR2a1IGIxz7nKsdRsY vg1ADK9q4NHMxmwE0LbH/+bzisLB+fLdPRGryKWe/7v8w7RjljK3uCqhgXk12o7TVcUE 0JS/ONZslNc9R3QXh0Po7M7ZBuCViynKdq2B8zYDEu23fA+GiOcmXbZWTT3dzbAMwXBV jfBRBjvkmVNGd8qajrjXoVD4qJZwVzloQXKwJiY8N7i/g/glfxKUMhvUe1Uy69gAVTo0 qSWw== X-Gm-Message-State: AOAM533/ef1yoWhrjnLbKql2wnto+Y3HC2YJzmnN4C8QgFT5rhhd3CWt HwpayBLHgLPyO6WrrpxNPknmAv+fGXnvr80DIhDroA== X-Google-Smtp-Source: ABdhPJw2Wd3lkFyCSaKE1R+Gmhq+CNRD3Sbcu3fX63Ehl7Ot2KbpAfryBXz7PS6nVCtlP1bo0qoVMzukbaU1xdsEhdc= X-Received: by 2002:a25:71c4:: with SMTP id m187mr414827ybc.397.1626115161245; Mon, 12 Jul 2021 11:39:21 -0700 (PDT) MIME-Version: 1.0 References: <20210623192822.3072029-1-surenb@google.com> <87sg0qa22l.fsf@oldenburg.str.redhat.com> <87wnq1z7kl.fsf@oldenburg.str.redhat.com> In-Reply-To: From: Suren Baghdasaryan Date: Mon, 12 Jul 2021 11:39:10 -0700 Message-ID: Subject: Re: [PATCH 1/1] mm: introduce process_reap system call To: Jan Engelhardt Cc: Florian Weimer , 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 , kernel-team Content-Type: text/plain; charset="UTF-8" Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=google.com header.s=20161025 header.b=cZPpg3JN; spf=pass (imf04.hostedemail.com: domain of surenb@google.com designates 209.85.219.172 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com X-Rspamd-Server: rspam02 X-Stat-Signature: kuak637hrhpbbgabc8u5cdbi536typnu X-Rspamd-Queue-Id: 2FEE1500009F X-HE-Tag: 1626115162-935152 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 Mon, Jul 12, 2021 at 5:51 AM Jan Engelhardt wrote: > > > On Thursday 2021-07-08 08:05, Suren Baghdasaryan wrote: > >> > >> That explains very clearly the requirement, but it raises the question > >> why this isn't an si_code flag for rt_sigqueueinfo, reusing the existing > >> system call. > > > >I think you are suggesting to use sigqueue() to deliver the signal and > >perform the reaping when a special value accompanies it. This would be > >somewhat similar to my early suggestion to use a flag in > >pidfd_send_signal() (see: > >https://lore.kernel.org/patchwork/patch/1060407) to implement memory > >reaping which has another advantage of operation on PIDFDs instead of > >PIDs which can be recycled. > >kill()/pidfd_send_signal()/sigqueue() are supposed to deliver the > >signal and return without blocking. Changing that behavior was > >considered unacceptable in these discussions. > > The way I understood the request is that a userspace program (or perhaps two, > if so desired) should issue _two_ calls, one to deliver the signal, > one to perform the reap portion: > > uinfo.si_code = SI_QUEUE; > sigqueue(pid, SIGKILL, &uinfo); > uinfo.si_code = SI_REAP; > sigqueue(pid, SIGKILL, &uinfo); This approach would still lead to the same discussion: by design, sigqueue/kill/pidfd_send_signal deliver the signal but do not wait for the signal to be processed by the recipient. Changing that would be a behavior change. Therefore we would have to follow this pattern and implement memory reaping in an asynchronous manner using a kthread/workqueue and it won't be done in the context of the calling process. This is undesirable because we lose the ability to control priority and cpu affinity for this operation and work won't be charged to the caller. That's why the proposed syscall performs memory reaping in the caller's context and blocks until the operation is done. In this proposal, your sequence looks like this: pidfd_send_signal(pidfd, SIGKILL, NULL, 0); process_reap(pidfd, 0); except we decided to rename process_reap() to process_mrelease() in the next revision.