All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
To: Christoph Lameter <clameter@engr.sgi.com>
Cc: akpm@osdl.org, lhms-devel@lists.sourceforge.net,
	linux-kernel@vger.kernel.org, Cliff Wickman <cpw@sgi.com>
Subject: Re: [Lhms-devel] [PATCH 4/7] Direct Migration V5: migrate_pages() extension
Date: Thu, 01 Dec 2005 02:28:33 +0900	[thread overview]
Message-ID: <438DE141.3030206@jp.fujitsu.com> (raw)
In-Reply-To: <Pine.LNX.4.62.0511300834010.19142@schroedinger.engr.sgi.com>

Christoph Lameter wrote:
> The current page migration functions in mempolicy.c do not migrate shmem 
> vmas to be safe. In the future we surely would like to support migration 
> of shmem. I'd be glad if you could make sure that this works.
> 
Okay, shmem is not problem now.

> 
>>Problem is:
>>1. a page of shmem(tmpfs)'s generic file is in page-cache. assume page is
>>diry.
>>2. When it passed to migrate_page(), it reaches pageout() in the middle of
>>migrate_page().
>>3. pageout calls shmem_writepage(), and the page turns to be swap-cache page.
>>   At this point, page->mapping becomes NULL (see move_to_swapcache())
> 
> 
> A swapcache page would have page->mapping pointing to swapper space. 
> move_to_swap_cache does not set page->mapping == NULL.
> 
int move_to_swap_cache(struct page *page, swp_entry_t entry)
{
         int err = __add_to_swap_cache(page, entry, GFP_ATOMIC);
         if (!err) {
                 remove_from_page_cache(page);<------------------------this
                 page_cache_release(page);       /* pagecache ref */
                 if (!swap_duplicate(entry))
                         BUG();
                 SetPageDirty(page);
                 INC_CACHE_INFO(add_total);
         } else if (err == -EEXIST)
                 INC_CACHE_INFO(exist_race);
         return err;
}

remove_from_page_cache(page) sets page->mapping == NULL.


> 
> If page->mapping would be NULL then migrate_page() could not 
> have been called. The mapping is used to obtain the address of the 
> function to call,
What you say is here.
==
                 /*
                  * Pages are properly locked and writeback is complete.
                  * Try to migrate the page.
                  */
                 mapping = page_mapping(page);
                 if (!mapping) <-------------------------------------------this check.
                         goto unlock_both;

                 if (mapping->a_ops->migratepage) {
                         rc = mapping->a_ops->migratepage(newpage, page);
                         goto unlock_both;
                 }
==
But, see page_mapping() .....
==
static inline struct address_space *page_mapping(struct page *page)
{
         struct address_space *mapping = page->mapping;

         if (unlikely(PageSwapCache(page)))
                 mapping = &swapper_space;
         else if (unlikely((unsigned long)mapping & PAGE_MAPPING_ANON))
                 mapping = NULL;
         return mapping;
}
==

Even if page->mapping == NULL, page_mapping() can return &swapper_space if PageSwapCache()
is true. (Note: a shmem page here is not page-cache, not anon, but swap-cache)

I'm now considering to add a_ops->migrate_page() to shmem is sane way...
But migration doesn't manage shmem, so this is just memory hot-remove's problem.


-- Kame





  reply	other threads:[~2005-11-30 17:29 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-11-28 20:42 [PATCH 0/7] Direct Migration V5: Overview Christoph Lameter
2005-11-28 20:42 ` [PATCH 1/7] Swap Migration: Fix double unlock Christoph Lameter
2005-11-28 20:42 ` [PATCH 2/7] Swap Migration: Consolidate successful migration handling Christoph Lameter
2005-11-28 20:42 ` [PATCH 3/7] Direct Migration V5: PageSwapCache checks Christoph Lameter
2005-11-28 20:43 ` [PATCH 4/7] Direct Migration V5: migrate_pages() extension Christoph Lameter
2005-11-30  8:34   ` [Lhms-devel] " KAMEZAWA Hiroyuki
2005-11-30 16:41     ` Christoph Lameter
2005-11-30 17:28       ` Kamezawa Hiroyuki [this message]
2005-11-30 17:55         ` Christoph Lameter
2005-11-30 23:48           ` KAMEZAWA Hiroyuki
2005-11-28 20:43 ` [PATCH 5/7] Direct Migration V5: remove_from_swap() to remove swap ptes Christoph Lameter
2005-11-30 11:29   ` [Lhms-devel] " KAMEZAWA Hiroyuki
2005-11-30 16:31     ` Christoph Lameter
2005-11-28 20:43 ` [PATCH 6/7] Direct Migration V5: upgrade MPOL_MF_MOVE and sys_migrate_pages() Christoph Lameter
2005-11-28 20:43 ` [PATCH 7/7] Direct Migration V5: Avoid writeback / page_migrate() method Christoph Lameter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=438DE141.3030206@jp.fujitsu.com \
    --to=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=akpm@osdl.org \
    --cc=clameter@engr.sgi.com \
    --cc=cpw@sgi.com \
    --cc=lhms-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.