Yeah, we are wondering ourselves about that. ?Could you try cherry-picking
commit ad10eb079c97e27b4d27bc755c605226ce1625de (update migrate type on pcp
when isolating) from git://github.com/mina86/linux-2.6.git? ?It probably
won't
apply cleanly but resolving the conflicts should not be hard (alternatively
you can try branch cma from the same repo but it is a work in progress at
the
moment).

I'll try this patch and report back ,,

quoted

is set to MIGRATE_CMA instead of MIGRATE_ISOLATED.

My understanding of that situation is that the page is on pcp list in which
cases it's page_private is not updated. ?Draining and the first patch in
the series (and also the commit I've pointed to above) are designed to fix
that but I'm unsure why they don't work all the time.

Will verify this if the page is found on the pcp list as well .

quoted

I've also had a test case where it failed because (page_count() != 0)

With this, when it failed the page_count()
returned a value of 2. I am not sure why, but I will try and see If I can
reproduce this.

quoted

Have you or anyone else seen this during the CMA testing?

Also, could this be because we are finding a page within (start, end)
that actually belongs to a higher order Buddy block ?

Higher order free buddy blocks are skipped in the ?if (PageBuddy(page))?
path of __test_page_isolated_in_pageblock(). ?Then again, now that I think
of it, something fishy may be happening on the edges. ?Moving the check
outside of __alloc_contig_migrate_range() after outer_start is calculated
in alloc_contig_range() could help. ?I'll take a look at it.

I was going to suggest that, moving the check until after outer_start
is calculated
will definitely help IMO. I am sure I've seen a case where

  page_count(page) = page->private = 0 and PageBuddy(page) was false.

I will try and reproduce this as well.

Thanks,
Sandeep