Hello,
I am resending the message below to the list, because it seems to have
gotten lost in transit somehow.
Apologies if you should receive multiple copies of this mail.
Best,
Andreas
On Tue, Jan 11, 2022 at 07:28:37AM +0100, Andreas Grapentin wrote:
> Hello,
>
> I recently wrote out of necessity a small utility to move memory pages
> of a posix named shared memory segment between NUMA nodes. A friend
> pointed out that this utility could make a good addition to numactl,
> maybe as a separate executable alongside migratepages.
>
> The repository of the tools in question is already public and
> available on github:
> https://github.com/oaken-source/move_shmem_pages
>
> Would this be a welcome addition to numactl? If so, I could prepare a
> PR or two to the numactl github repository to add this functionality.
>
> Thanks for your time, and best Regards,
> Andreas Grapentin
On Sat, Jan 15, 2022 at 11:05:42AM +0100, Andreas Grapentin wrote:
> On Tue, Jan 11, 2022 at 07:28:37AM +0100, Andreas Grapentin wrote:
> > Hello,
> >
> > I recently wrote out of necessity a small utility to move memory pages
> > of a posix named shared memory segment between NUMA nodes. A friend
> > pointed out that this utility could make a good addition to numactl,
> > maybe as a separate executable alongside migratepages.
> >
> > The repository of the tools in question is already public and
> > available on github:
> > https://github.com/oaken-source/move_shmem_pages
> >
> > Would this be a welcome addition to numactl? If so, I could prepare a
> > PR or two to the numactl github repository to add this functionality.
Thanks for the offer.
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.
-Andi
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
------------------------------------------------------------------------------
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