Received-SPF: pass (google.com: domain of linux-numa-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Tue, 18 Jan 2022 13:23:16 -0800
From:   Andi Kleen <andi@firstfloor.org>
To:     Andreas Grapentin <andreas@grapentin.org>
Cc:     linux-numa@vger.kernel.org, Andi Kleen <andi@firstfloor.org>
Subject: Re: utility for numa placement of POSIX shared memory segments
Message-ID: <20220118212315.g6tksukstq7wqhxm@two.firstfloor.org>
References: <D6DA3DAD-286C-4D15-A394-447546711B79@grapentin.org>
 <20220115100542.qanbvb6dhz27sdyj@parabolabook-BM15.localdomain>
 <20220115160946.uwur26u3zyzcwvzo@two.firstfloor.org>
 <20220117080436.ay2ep2hqxe5fe2yf@parabolabook-BM15.localdomain>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20220117080436.ay2ep2hqxe5fe2yf@parabolabook-BM15.localdomain>
User-Agent: NeoMutt/20170113 (1.7.2)
Precedence: bulk

Sorry for the late answer

On Mon, Jan 17, 2022 at 09:04:36AM +0100, Andreas Grapentin wrote:
> It seems to me that until now, the main numactl binary is limited to
> functionality to query and control the policies that determine the
> placement of future pages. Physically moving already placed pages from a
> process' resident set had been implemented in the separate binary
> migratepages, which seemed like a good separation of concerns to me.
> That's why I initially suggested having a separate binary for the moving
> of shared memory pages.

migratepages is separate because it deals with the private address
space of a process, not because it moves pages.

> 
> That being said, it is definitely possible to integrate that
> functionality into the numactl binary, if this is the preferred
> approach. What do you suggest would be a good integration into the
> command line parameter setup?

I would add a --move-pages

> 
> Secondly, lookig at the command line parameters of numactl, it seems to
> only be compatible with SysV shared memory segments (ftok, shmget), not
> posix shared memory segments (shm_open) is this correct?

shm_open is just a wrapper around mmap on a file.

You can specify the underlying file of shm_open with --file

-Andi