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
Date: Mon, 17 Jan 2022 09:04:36 +0100 [thread overview]
Message-ID: <20220117080436.ay2ep2hqxe5fe2yf@parabolabook-BM15.localdomain> (raw)
In-Reply-To: <20220115160946.uwur26u3zyzcwvzo@two.firstfloor.org>
[-- Attachment #1: Type: text/plain, Size: 1773 bytes --]
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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2022-01-17 8:04 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <D6DA3DAD-286C-4D15-A394-447546711B79@grapentin.org>
2022-01-15 10:05 ` utility for numa placement of POSIX shared memory segments Andreas Grapentin
2022-01-15 16:09 ` Andi Kleen
2022-01-17 8:04 ` Andreas Grapentin [this message]
2022-01-18 21:23 ` Andi Kleen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220117080436.ay2ep2hqxe5fe2yf@parabolabook-BM15.localdomain \
--to=andreas@grapentin.org \
--cc=andi@firstfloor.org \
--cc=linux-numa@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).