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

Andi Kleen
2005-02-15T11:53:11Z

> (1) You really don't want to migrate the code pages of shared libraries
> that are mapped into the process address space. This causes a
> useless shuffling of pages which really doesn't help system
> performance. On the other hand, if a shared library is some
> private thing that is only used by the processes being migrated,
> then you should move that.

I think the better solution for this would be to finally integrate Steve L.'s
file attribute code (and find some solution to make it persistent,
e.g. using xattrs with a new inode flag) and then "lock" the shared
libraries to their policy using a new attribute flag.

>
> (2) You really only want to migrate pages once. If a file is mapped
> into several of the pid's that are being migrated, then you want
> to figure this out and issue one call to have it moved wrt one of
> the pid's.
> (The page migration code from the memory hotplug patch will handle
> updating the pte's of the other processs (thank goodness for
> rmap...))

I don't get this. Surely the migration code will check if a page
is already in the target node, and when that is the case do nothing.

How could this "double migration" happen?

>
> (3) In the case where a particular file is mapped into different
> processes at different file offsets (and we are migrating both
> of the processes), one has to examine the file offsets to figure
> out if the mappings overlap or not. If they overlap, then you've
> got to issue two calls, each of which describes a non-overlapping
> region; both calls taken together would cover the entire range
> of pages mapped to the file. Similarly if the ranges do not
> overlap.

That sounds like a quite obscure corner case which I'm not sure
is worth all the complexity.

-Andi