Messages in this thread |  | | | Date | Tue, 7 Aug 2012 16:45:26 +0100 | | From | Mel Gorman <> | | Subject | Re: [PATCH 6/6] mm: have order > 0 compaction start near a pageblock with free pages |
| |
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<mgorman@suse.de> > >> > >>Reviewed-by: Rik van Riel<riel@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
|  |