On Tue, Aug 07, 2012 at 09:20:08AM -0600, Jim Schutt wrote: > 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<mgor...@suse.de> > >> > >>Reviewed-by: Rik van Riel<r...@redhat.com> > >> > > > >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. >
Grand, good luck with the Ceph bug. > 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? > That is perfectly reasonable, thanks. > 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? > It might. It depends on whether the underlying driver needs contiguous pages to handle jumbo frame, if it can do scatter/gather IO or some combination like trying for a contiguous page but using scatter/gather as a fallback. Certainly it is interesting and I will keep it in mind. -- Mel Gorman SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
