Re: question on page-migration code

Ray Bryant
2005-04-11T14:20:06Z

Marcelo Tosatti wrote:
> On Thu, Apr 07, 2005 at 05:16:30PM -0500, Ray Bryant wrote:
>
>>Hirokazu (and Marcelo),
>>
>>In testing my manual page migration code, I've run up against a situation
>>where the migrations are occasionally very slow. They work ok, but they
>>can take minutes to migrate a few megabytes of memory.
>>
>>Dropping into kdb shows that the migration code is waiting in msleep() in
>>migrate_page_common() due to an -EAGAIN return from page_migratable().
>>A little further digging shows that the specific return in page_migratable()
>>is the very last one there at the bottom of the routine.
>>
>>I'm puzzled as to why the page is still busy in this case. Previous code
>>in page_migratable() has unmapped the page, its not in PageWriteback()
>>because we would have taken a different return statement in that case.
>>
>>According to /proc/meminfo, there are no pages in either SwapCache or
>>Dirty state, and the system has been sync'd before the migrate_pages()
>>call was issued.
>
>
> Who is using the page?
>
> A little debugging might help similar to what bad_page does can help:
>
> printk(KERN_EMERG "flags:0x%0*lx mapping:%p mapcount:%d count:%d\n",
> (int)(2*sizeof(page_flags_t)), (unsigned long)page->flags,
> page->mapping, page_mapcount(page), page_count(page));
> --

The suspect pages all have flags field of 105d and mapcount of 0, pagecount
of 3. If I'm decoding the bits correctly, we've got the following bits
set:

Locked
Referenced
Uptodate
Dirty
Active
PG_arch_1

Doesn't tell me much. Anything spring to mind when you look at these
bits, Marcelo?

--
Best Regards,
Ray