Re: migration cache, updated

[Marcelo Tosatti <marcelo.tosatti@cyclades.com>]

Hi Hirokazu,

On Wed, Dec 08, 2004 at 10:23:07PM +0900, Hirokazu Takahashi wrote:
> Hi Marcelo,
> > > > Sorry for the delay, been busy with other things.
> > > 
> > > No problem. Everyone knows you're doing hard work!
> 
> > > > > Therefore, I made pages removed from the migration cache
> > > > > at the end of generic_migrate_page() if they remain in the cache.
> > 
> > OK, removing migration pages at end of generic_migrate_page() should 
> > avoid the leak - that part of your patch is fine to me!
> > 
> > > > > The another is a fork() related problem. If fork() has occurred
> > > > > during page migrationa, the previous work may not go well.
> > > > > pages may not be removed from the migration cache.
> > 
> > Can you please expand on that one? I assume it works fine because 
> > copy_page_range() duplicates the migration page reference (and the 
> > migration pte), meaning that on exit (zap_pte_range) the migration
> > pages should be removed through migration_remove_entry(). 
> 
> Yes, that's true.
> 
> > I dont see the problem - please correct me.
> 
> However, once the page is moved into the migration cache,
> no one can make it swapped out. This problem may be solved
> by your approach described below.
> 
> > > > > So I made the swapcode ignore pages in the migration cache.
> > > > > However, as you know this is just a workaround and not a correct
> > > > > way to fix it.
> > 
> > What this has to do with fork()? I can't understand.
> 
> fork() may leave some pages in the migration cache with my
> latest implementation, though the memory migration code
> tries to remove them from the migration cache by forcible
> pagefault in touch_unmapped_address().

Why are record_unmapped_address/touch_unmapped_address needed ? 

I started investigating the issue which migration pages couldnt 
be swapped out, but found out that migration pages are never left 
in the cache because touch_unmapped_address recreates the ptes removing
the pages from the migration cache.

That means we have no problem with migration cache pages left pinned 
(unswappable) in memory, which means it is fully functional AFAICT.

However, I thought the intent was to fault the pages on demand? 

I even wrote this to be called at vmscan() time but touch_unmapped_address 
already has similar functionality at migration time.

int try_to_faultin(struct page *page)
{
        struct anon_vma *anon_vma;
        struct vm_area_struct *vma;
        unsigned long address;
        int ret = 0;

restart:
        anon_vma = page_lock_anon_vma(page);
        if (!anon_vma)
                return ret;

        list_for_each_entry(vma, &anon_vma->head, anon_vma_node) {
                address = vma_address(page, vma);
                // handle if (address = -EFAULT) ? 
                if (!follow_and_check_present(vma->vm_mm, address))
                        continue;

                spin_unlock(&anon_vma->lock);
                switch (handle_mm_fault(vma->vm_mm, vma, address, 0)) {
                case VM_FAULT_MINOR:
                        goto restart;
                case VM_FAULT_MAJOR:
                        BUG();
                case VM_FAULT_SIGBUS:
                case VM_FAULT_OOM:
                        goto out_unlock;
                }
        }
        ret = 1;
        printk(KERN_ERR "faulted migration page in!\n");

out_unlock:
        spin_unlock(&anon_vma->lock);
        return ret;

}


> 
> However, touch_unmapped_address() doesn't know that the
> migration page has been duplicated.
> 
> > Your patch is correct here also - we can't reclaim migration cache 
> > pages.
> > 
> > +	if (PageMigration(page)) {
> > +		write_unlock_irq(&mapping->tree_lock);
> > +		goto keep_locked;
> > +	}
> > 
> > An enhancement would be to force pagefault of all pte's
> > mapping to a migration cache page on shrink_list.  
> >
> > similar to rmap.c's try_to_unmap_anon() but intented to create the pte 
> > instead of unmapping it
> 
> If it works as we expect, this code can be called at the end of
> generic_migrate_page() I guess.
--
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>