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 ------------------------------------------------------------------------------
Attachment:
signature.asc
Description: PGP signature
