From: Serge A <serge.ayoun@gmail.com>
To: linux-numa@vger.kernel.org
Subject: Memory policy change handling and callbacks for a new HW feature
Date: Wed, 26 Nov 2014 15:12:39 +0000 (UTC) [thread overview]
Message-ID: <loom.20141126T155624-469@post.gmane.org> (raw)
We are trying to see how to adapt a new hardware feature (of our) with NUMA.
This feature takes ownership of an area of kernel memory which, in NUMA
machine, is spread among the different nodes; one in each node. This means
with two nodes -> two areas, four nodes -> four areas...
These areas are managed by a kernel driver.
A user application can make use of this HW feature by allocating (via the
driver by mean of IO_CTRL) a buffer from these areas.
In this case we would have (at the application level) a vma mapped to the
just reserved buffer.
We want to associate these buffers to the right node according to the
memory policy.
The 'mapped vma to the buffer' design is very convenient as changing the
memory policy of the buffer address range (mbind API)
causes a calls to the driver via vm_operations_struct.set_policy callback
and we can then take the right action; moving buffer to other nodes.
A problem occurs when the policy is being changed at the process scope, for
example numa_set_membind() API call. In this case we do not get any
callback and I do not see how we can handle this policy change when it
happens.
We registered to vm_operations_struct.migrate callback, but I could not see
any invocation of it either.
Does anyone have a suggestion about the right way to handle this?
Thanks,
Serge
reply other threads:[~2014-11-26 15:12 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=loom.20141126T155624-469@post.gmane.org \
--to=serge.ayoun@gmail.com \
--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).