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



-- 

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