Re: [RFC][PATCH 0/1] Node-based reclaim/migration

["Paul Menage" <menage@google.com>]

On 11/29/06, Christoph Lameter <clameter@sgi.com> wrote:
>
> You do not have a problem as long as you hold a mmap_sem lock on any of
> the vmas in which the page appears. Kame and I discussed several
> approached on how to avoid the issue in the past but so far there was no
> need to resolve the issue.
>

It sounds like this would be useful for memory hot-unplug too, though.
A problem worth solving?

Why isn't page_lock_anon_vma() safe to use in this case? Because after
we've established migration ptes, page_mapped() will be false and so
page_lock_anon_vma() will return NULL?
How does kswapd do this safely?

Possible approach (apologies if you've already considered and rejected this):

- add a migration_count field to anon_vma

- use page_lock_anon_vma() to get the anon_vma for a page, assuming
it's mapped; if it's unmapped or if the anon_vma that we get has no
linked vmas then we ignore it - the chances are that the page is in
the process of being freed anyway, and if someone happens to remap it
just before it's freed then we can catch it next time around.

- isolate_lru_page() can bump this for every page that it isolates

- unlink_anon_vma() won't free the anon_vma if its migration_count is >0.

- remove_anon_migration_ptes() can free the anon_vma if
migration_count is 0 and the vma list is empty.


Paul

--
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:"dont@kvack.org"> email@kvack.org </a>