lkml.org 
[lkml]   [2007]   [May]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 2/7] KAMEZAWA Hiroyuki - migration by kernel
On Wed, 30 May 2007, Hugh Dickins wrote:

> I've taken a look at last. It looks like a good fix to a real problem,
> but may I suggest a simpler version? The anon_vma isn't usually held
> by a refcount, but by having a vma on its linked list: why not just
> put a dummy vma into that linked list? No need to add a refcount.
>
> The NUMA shmem_alloc_page already uses a dummy vma on its stack,
> so you can reasonably declare a vm_area_struct on unmap_and_move's
> stack. No need for a special anon_vma_release, anon_vma_unlink
> should do fine. I've not reworked your whole patch, but show
> what I think the mm/rmap.c part would be at the bottom.

Hummm.. shmem_alloc_pages version only uses the vma as a placeholder
for memory policies. So we would put the page on a vma that is on the
stack? That would mean changing the mapping of the page? Is that safe?

And then later we would be changing the mapping back to the old vma?
What guarantees that the old vma is not gone by then?
-
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/

\
 
 \ /
  Last update: 2007-05-30 22:09    [W:1.530 / U:0.936 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site