Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) client-ip=2620:137:e000::3:7;
Date:   Tue, 28 Nov 2023 10:45:02 +0100
From:   Michal Hocko <mhocko@suse.com>
To:     Gregory Price <gregory.price@memverge.com>
Cc:     Andrew Morton <akpm@linux-foundation.org>,
        Gregory Price <gourry.memverge@gmail.com>, linux-mm@kvack.org,
        linux-doc@vger.kernel.org, linux-fsdevel@vger.kernel.org,
        linux-api@vger.kernel.org, linux-arch@vger.kernel.org,
        linux-kernel@vger.kernel.org, arnd@arndb.de, tglx@linutronix.de,
        luto@kernel.org, mingo@redhat.com, bp@alien8.de,
        dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com,
        tj@kernel.org, ying.huang@intel.com
Subject: Re: [RFC PATCH 00/11] mm/mempolicy: Make task->mempolicy externally
 modifiable via syscall and procfs
Message-ID: <ZWW2ngGhM9af5qJW@tiehlicka>
References: <20231122211200.31620-1-gregory.price@memverge.com>
 <20231122133348.d27c09a90bce755dc1c0f251@linux-foundation.org>
 <ZV5/ilfUoqC2PW0D@memverge.com>
 <ZWS19JFHm_LFSsFd@tiehlicka>
 <ZWTAdKnBVO0+5bbR@memverge.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <ZWTAdKnBVO0+5bbR@memverge.com>
Precedence: bulk

On Mon 27-11-23 11:14:44, Gregory Price wrote:
> On Mon, Nov 27, 2023 at 04:29:56PM +0100, Michal Hocko wrote:
> > Sorry, didn't have much time to do a proper review. Couple of points
> > here at least.
> > 
> > > 
> > > So... yeah... the is one area I think the community very much needs to
> > > comment:  set/get_mempolicy2, many new mempolicy syscalls, procfs? All
> > > of the above?
> > 
> > I think we should actively avoid using proc interface. The most
> > reasonable way would be to add get_mempolicy2 interface that would allow
> > extensions and then create a pidfd counterpart to allow acting on a
> > remote task. The latter would require some changes to make mempolicy
> > code less current oriented.
> 
> Sounds good, I'll pull my get/set_mempolicy2 RFC on top of this.
> 
> Just context: patches 1-6 refactor mempolicy to allow remote task
> twiddling (fixing the current-oriented issues), and patch 7 adds the pidfd
> interfaces you describe above.
> 
> 
> Couple Questions
> 
> 1) Should we consider simply adding a pidfd arg to set/get_mempolicy2,
>    where if (pidfd == 0), then it operates on current, otherwise it
>    operates on the target task?  That would mitigate the need for what
>    amounts to the exact same interface.

This wouldn't fit into existing pidfd interfaces I am aware of. We
assume pidfd to be real fd, no special cases.

> 2) Should we combine all the existing operations into set_mempolicy2 and
>    add an operation arg.
> 
>    set_mempolicy2(pidfd, arg_struct, len)
> 
>    struct {
>      int pidfd; /* optional */
>      int operation; /* describe which op_args to use */
>      union {
>        struct {
>        } set_mempolicy;
>        struct {
>        } set_vma_home_node;
>        struct {
>        } mbind;
>        ...
>      } op_args;
>    } args;
> 
>    capturing:
>      sys_set_mempolicy
>      sys_set_mempolicy_home_node
>      sys_mbind
> 
>    or should we just make a separate interface for mbind/home_node to
>    limit complexity of the single syscall?

My preference would be to go with specific syscalls. Multiplexing
syscalls have turned much more complex and less flexible over time.
Just have a look at futex.
-- 
Michal Hocko
SUSE Labs