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:   Mon, 17 Jan 2022 09:04:36 +0100
From:   Andreas Grapentin <andreas@grapentin.org>
To:     linux-numa@vger.kernel.org
Cc:     Andi Kleen <andi@firstfloor.org>
Subject: Re: utility for numa placement of POSIX shared memory segments
Message-ID: <20220117080436.ay2ep2hqxe5fe2yf@parabolabook-BM15.localdomain>
References: <D6DA3DAD-286C-4D15-A394-447546711B79@grapentin.org>
 <20220115100542.qanbvb6dhz27sdyj@parabolabook-BM15.localdomain>
 <20220115160946.uwur26u3zyzcwvzo@two.firstfloor.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
        protocol="application/pgp-signature"; boundary="gciwnia7zx2zq3b5"
Content-Disposition: inline
In-Reply-To: <20220115160946.uwur26u3zyzcwvzo@two.firstfloor.org>
Precedence: bulk


--gciwnia7zx2zq3b5
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable


Hello,

On Sat, Jan 15, 2022 at 08:09:48AM -0800, Andi Kleen wrote:
> It could be useful, but numactl itself already has file shared memory
> policy support, just not support for moving (and migrate_pages only
> supports pid). So if it was added I would prefer having it as a new
> argument to numactl instead of proliferating commands with different
> syntax. It should be fairly straight forward there because
> all the infrastructure to parse the arguments and map the pages is
> already there.

I have taken a bit of time to think about your suggestion, and I would
like to ask a few questions :)

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.

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?

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?

Thanks,
Andreas


--=20

---------------------------------------------------------------------------=
---
my GPG Public Key:                 https://files.grapentin.org/.gpg/public.=
key
---------------------------------------------------------------------------=
---

--gciwnia7zx2zq3b5
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAABCAAdFiEEv6gAioJlZ3BjsRv0cXGYbkt0VTYFAmHlIxIACgkQcXGYbkt0
VTbKpAgAnRT6aC5EyHyu6pr4CzWLMXa+AhoP2iZnpDeeMQApZ7wdmu283lWKbTVF
GuxlvpTTfVlIgSEgXT/QGUyQdyIV/H5LVyx9qK2lhg7jB37+Mlx+HhiS06K/U82i
rw1eIoUl1tQMwtq46GA2Vwze3OqtLRsrLpUMVbvlhkctjSBXo6+4vib37qczpvrU
pFKFu774bkXp+fpc8ytTB12eNiUXs3FB4MMw0+y8zFz93OsCZrAUaJm0RlrbJ1cX
trZJszoOrbgt6IGQ/1rsVCtgqUZR94K8ZYGooqlS+0ao3QEtvQuGAVql5a1FUIXd
QxxvXVyfRU0M7RQEihTX9hA4kd0OjQ==
=pEwN
-----END PGP SIGNATURE-----

--gciwnia7zx2zq3b5--