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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id E0B8BC433FE for ; Tue, 11 Oct 2022 17:22:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6240C6B0071; Tue, 11 Oct 2022 13:22:37 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5D38E6B0073; Tue, 11 Oct 2022 13:22:37 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 427166B0074; Tue, 11 Oct 2022 13:22:37 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 2AC936B0071 for ; Tue, 11 Oct 2022 13:22:37 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id D63791A06BD for ; Tue, 11 Oct 2022 17:22:36 +0000 (UTC) X-FDA: 80009337912.29.C34AFC0 Received: from mail-ej1-f47.google.com (mail-ej1-f47.google.com [209.85.218.47]) by imf03.hostedemail.com (Postfix) with ESMTP id 6EEAE20018 for ; Tue, 11 Oct 2022 17:22:36 +0000 (UTC) Received: by mail-ej1-f47.google.com with SMTP id qw20so32324826ejc.8 for ; Tue, 11 Oct 2022 10:22:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=tD9jR7qHoo8YjCPFAxtMgRghcsI0I3euLcmHX/AlDvk=; b=EG3pijXaCZAx0z7+DzNm/ASYYg3E5j3bCUvD9D1vXPg0vGbv7rSmWRFf+49wNrOjPC XgB9u2o/1y2tnzLsdca6ebyRx8nNHH+TcgbL4bosKJZBi3Q6JBHOnWZhuWd3TMiGpK0W qUqplH1WfiIV27fsfHUt9ko6yhHMZp32J6NLnAYkBDd4AQSkHidIiGKvs5DCXkvBO5hF subwyAFDVEt33ulB4j6S8wDFl/z7aH4H73nqR0aPqy/DSs/DCwi98lV5QH3cvDLQMMft zGXv1Z3V2aDk5tyMCO22+B1TZ7WjzVHijfIx/Ek4rbzQXt0uvboaMorpjZHSA/OP/KNt 8VNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=tD9jR7qHoo8YjCPFAxtMgRghcsI0I3euLcmHX/AlDvk=; b=tQif7A8PyaY/IwK62vMIfSygyyo4iheH1QMJWjzosXML8TF55AHU2Gw83o6HFtv/aU CPVoORrPKnyRsIX5AmE74Dw1tulVbU1EySRSOuVYaSa/MN5oN0cxV1rjpCyHEmAN5vG9 o9bRFWIY14ISImmvsYoTPh5wx2ewtfS62G/X0XNnkMfotVvOfYPTmBpvWlBdoPaQkRfu 9eBh2WnlHur8CkgbEjX/mnkGOiPNd31kapJBP1mFC2Ab8NCkGmwKOL7rx8B/ZYAy1X2A LZtCk0A/YPq2Ukwv0Xic6tlGpUVkhbHlGk9GDxyRDzCRJaLj/owB4RB5cujw+gjoUAV0 1QGw== X-Gm-Message-State: ACrzQf2oogtAfRYvjrG16i9hRov6/hD8VIjig58OJ3WHbTsGBuXVPxYv UrhtVPxFUXTCgEVQ8eaKxsDPZ5t6o02B9qcNPWZX+w== X-Google-Smtp-Source: AMsMyM5ZC8bySD0ur+e6jyv+eDlRBwAazeHKoD2ZcGUoZbIE0AMED9AS38/kZXKX5FECDsvvfbQ8I6W0UQAoyEgijY4= X-Received: by 2002:a17:906:4fca:b0:78d:b042:eeca with SMTP id i10-20020a1709064fca00b0078db042eecamr9869193ejw.685.1665508955072; Tue, 11 Oct 2022 10:22:35 -0700 (PDT) MIME-Version: 1.0 References: <20221010094842.4123037-1-hezhongkun.hzk@bytedance.com> In-Reply-To: From: Frank van der Linden Date: Tue, 11 Oct 2022 10:22:23 -0700 Message-ID: Subject: Re: [RFC] mm: add new syscall pidfd_set_mempolicy() To: Michal Hocko Cc: Zhongkun He , corbet@lwn.net, akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-api@vger.kernel.org, linux-doc@vger.kernel.org, wuyun.abel@bytedance.com Content-Type: text/plain; charset="UTF-8" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1665508956; a=rsa-sha256; cv=none; b=ctCP+Wwo3hy+zzDDZAJfhRdjAP8f/bOpiXUuD6YbBvg/Gk/Wxflo/4Hc9MGIg0Q5bF/GYP ccFyUwmsuxooX7/DXBea3DAqpmxHUh7Q0rJiktSwBI7cKdgV6pVsP5EYMChti4DF2r6UY7 r5K/DeHoTcerLbml/9dkodq8z7mwWt0= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=EG3pijXa; spf=pass (imf03.hostedemail.com: domain of fvdl@google.com designates 209.85.218.47 as permitted sender) smtp.mailfrom=fvdl@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1665508956; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=tD9jR7qHoo8YjCPFAxtMgRghcsI0I3euLcmHX/AlDvk=; b=uAFwFbiMFCFsgTX/9edHTAUhtJqYkeRE4X0QDGBiseYJsysiC+UonNS32WpKfHp+NpkuDr c4ODmWlq0EgK8ctyY5GDg/C7owXVPskc3R8Lui06Wz93jNuqrMTUcF0vCcumjsuBXoSnMW 6MixliDoTd8iDnPI434zBEfuGFT6DEQ= X-Rspam-User: X-Stat-Signature: 9tccg7uufyi1xizxt7iysi5wnj1y6gc8 X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 6EEAE20018 Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=EG3pijXa; spf=pass (imf03.hostedemail.com: domain of fvdl@google.com designates 209.85.218.47 as permitted sender) smtp.mailfrom=fvdl@google.com; dmarc=pass (policy=reject) header.from=google.com X-HE-Tag: 1665508956-862213 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000017, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, Oct 11, 2022 at 8:00 AM Michal Hocko wrote: > > On Mon 10-10-22 09:22:13, Frank van der Linden wrote: > > For consistency with process_madvise(), I would suggest calling it > > process_set_mempolicy. > > This operation has per-thread rather than per-process semantic so I do > not think your proposed naming is better. True. I suppose you could argue that it should have been pidfd_madvise() then for consistency, but that ship has sailed. > > > Other than that, this makes sense. To complete > > the set, perhaps a process_mbind() should be added as well. What do > > you think? > > Is there any real usecase for this interface? How is the caller supposed > to make per-range decisions without a very involved coordination with > the target process? The use case for a potential pidfd_mbind() is basically a combination of what is described for in the process_madvise proposal ( https://lore.kernel.org/lkml/20200901000633.1920247-1-minchan@kernel.org/ ), and what this proposal describes: system management software acting as an orchestrator that has a better overview of the system as a whole (NUMA nodes, memory tiering), and has knowledge of the layout of the processes involved. pidfd_mbind() makes sense to me, since the notion of an external agent with knowledge of the VM layout is already there with process_madvise(). And since set_mempolicy and mbind are closely related, it would seem logical to add an mbind variant as well as pidfd_set_mempolicy(). Having said that, I'm fine with leaving that discussion for another time. - Frank