Re: [RFC 2.6.11-rc2-mm2 0/7] mm: manual page migration -- overview

Ray Bryant
2005-02-14T23:49:53Z

Andi Kleen wrote:
>>But how do you use mbind() to change the memory placement for an anonymous
>>private mapping used by a vendor provided executable with mbind()?
>
>
> For that you use set_mempolicy.
>
> -Andi
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: aart@kvack.org
>

Andi,

If all processes are guarenteed to use the NUMA api for memory placement,
then AFAIK one could, in principle, imbed the migration of pages into
the NUMA api as you propose. The problem is that AFAIK most programs
that we run are not using the NUMA api. Instead, they are using first-touch
with the knowledge that such pages will be allocated on the node where they
are first referenced.

Since we have to build a migration facility that will migrate jobs that
use both the NUMA API and the first-touch approach, it seems to me the
only plausible soluion is to move the pages via a migration facility
and then if there are NUMA API control structures found associated with
the moved pages to update them to represent the new reality. Whether
this happens as an automatic side effect of the migration call or it
happens by a issuing a new set_mempolicy() is not clear to me. I would
prefer to just issue a new set_mempolicy(), but somehow the migration
code will have to figure out where this call needs to be executed (i. e.
which pages have an associated NUMA policy). [Thus the disclaimer in
the overview note that we have figured all the interaction with
memory policy stuff yet.]

--
-----------------------------------------------
Ray Bryant
512-453-9679 (work) 512-507-7807 (cell)
raybry@sgi.com raybry@austin.rr.com
The box said: "Requires Windows 98 or better",
so I installed Linux.
-----------------------------------------------