Messages in this thread | | | Date | Mon, 14 Feb 2005 17:49:53 -0600 | From | Ray Bryant <> | Subject | Re: [RFC 2.6.11-rc2-mm2 0/7] mm: manual page migration -- overview |
| |
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: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a> >
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. ----------------------------------------------- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |