Re: [PATCH 6/6] mm: have order > 0 compaction start near apageblock with free pages

[Jim Schutt]

On 08/07/2012 08:52 AM, Mel Gorman wrote:
> On Tue, Aug 07, 2012 at 10:45:25AM -0400, Rik van Riel wrote:
> > On 08/07/2012 08:31 AM, Mel Gorman wrote:
> > > commit [7db8889a: mm: have order>   0 compaction start off where it left]
> > > introduced a caching mechanism to reduce the amount work the free page
> > > scanner does in compaction. However, it has a problem. Consider two process
> > > simultaneously scanning free pages
> > >
> > > 				    			C
> > > Process A		M     S     			F
> > > 		|---------------------------------------|
> > > Process B		M 	FS
> >
> > Argh. Good spotting.
> >
> > > This is not optimal and it can still race but the compact_cached_free_pfn
> > > will be pointing to or very near a pageblock with free pages.
> >
> > Agreed on the "not optimal", but I also cannot think of a better
> > idea right now. Getting this fixed for 3.6 is important, we can
> > think of future optimizations in San Diego.
>
> Sounds like a plan.
>
> > > Signed-off-by: Mel Gorman<mgorman@xxxxxxx>
> >
> > Reviewed-by: Rik van Riel<riel@xxxxxxxxxx>
>
> Thanks very much.
>
> Jim, what are the chances of getting this series tested with your large
> data workload? As it's on top of 3.5, it should be less scary than
> testing 3.6-rc1 but if you are comfortable testing 3.6-rc1 then please
> test with just this patch on top.

As it turns out I'm already testing 3.6-rc1, as I'm on
the trail of a Ceph client messaging bug.  I think I've
about got that figured out, and am working on a patch, but
I need it fixed in order to generate enough load to trigger
the problem that your patch addresses.

Which is a long-winded way of saying:  no problem, I'll
roll this into my current testing, but I'll need another
day or two before I'm likely to be able to generate a
high enough load to test effectively.  OK?

Also FWIW, it occurs to me that you might be interested
to know that my load also involves lots of network load
where I'm using jumbo frames.  I suspect that puts even
more stress on higher page order allocations, right?

-- Jim

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/