Date:	Mon, 1 Oct 2012 16:24:29 +0200
From:	Thierry Reding <thierry.reding@...onic-design.de>
To:	Mel Gorman <mgorman@...e.de>
Cc:	Peter Ujfalusi <peter.ujfalusi@...com>,
	Minchan Kim <minchan@...nel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Marek Szyprowski <m.szyprowski@...sung.com>,
	Michal Nazarewicz <mina86@...a86.com>,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org,
	Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>,
	Kyungmin Park <kyungmin.park@...sung.com>,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>
Subject: Re: CMA broken in next-20120926

On Fri, Sep 28, 2012 at 01:43:32PM +0100, Mel Gorman wrote:
> On Fri, Sep 28, 2012 at 01:39:24PM +0200, Thierry Reding wrote:
> > On Fri, Sep 28, 2012 at 12:07:12PM +0100, Mel Gorman wrote:
> > > On Fri, Sep 28, 2012 at 12:51:13PM +0200, Thierry Reding wrote:
> > > > On Fri, Sep 28, 2012 at 12:38:15PM +0200, Thierry Reding wrote:
> > > > > On Fri, Sep 28, 2012 at 12:32:07PM +0200, Thierry Reding wrote:
> > > > > > On Fri, Sep 28, 2012 at 11:27:28AM +0100, Mel Gorman wrote:
> > > > > > > On Fri, Sep 28, 2012 at 11:48:25AM +0300, Peter Ujfalusi wrote:
> > > > > > > > Hi,
> > > > > > > > 
> > > > > > > > On 09/28/2012 11:37 AM, Mel Gorman wrote:
> > > > > > > > >> I hope this patch fixes the bug. If this patch fixes the problem
> > > > > > > > >> but has some problem about description or someone has better idea,
> > > > > > > > >> feel free to modify and resend to akpm, Please.
> > > > > > > > >>
> > > > > > > > > 
> > > > > > > > > A full revert is overkill. Can the following patch be tested as a
> > > > > > > > > potential replacement please?
> > > > > > > > > 
> > > > > > > > > ---8<---
> > > > > > > > > mm: compaction: Iron out isolate_freepages_block() and isolate_freepages_range() -fix1
> > > > > > > > > 
> > > > > > > > > CMA is reported to be broken in next-20120926. Minchan Kim pointed out
> > > > > > > > > that this was due to nr_scanned != total_isolated in the case of CMA
> > > > > > > > > because PageBuddy pages are one scan but many isolations in CMA. This
> > > > > > > > > patch should address the problem.
> > > > > > > > > 
> > > > > > > > > This patch is a fix for
> > > > > > > > > mm-compaction-acquire-the-zone-lock-as-late-as-possible-fix-2.patch
> > > > > > > > > 
> > > > > > > > > Signed-off-by: Mel Gorman <mgorman@...e.de>
> > > > > > > > 
> > > > > > > > linux-next + this patch alone also works for me.
> > > > > > > > 
> > > > > > > > Tested-by: Peter Ujfalusi <peter.ujfalusi@...com>
> > > > > > > 
> > > > > > > Thanks Peter. I expect it also works for Thierry as I expect you were
> > > > > > > suffering the same problem but obviously confirmation of that would be nice.
> > > > > > 
> > > > > > I've been running a few tests and indeed this solves the obvious problem
> > > > > > that the coherent pool cannot be created at boot (which in turn caused
> > > > > > the ethernet adapter to fail on Tegra).
> > > > > > 
> > > > > > However I've been working on the Tegra DRM driver, which uses CMA to
> > > > > > allocate large chunks of framebuffer memory and these are now failing.
> > > > > > I'll need to check if Minchan's patch solves that problem as well.
> > > > > 
> > > > > Indeed, with Minchan's patch the DRM can allocate the framebuffer
> > > > > without a problem. Something else must be wrong then.
> > > > 
> > > > However, depending on the size of the allocation it also happens with
> > > > Minchan's patch. What I see is this:
> > > > 
> > > > [   60.736729] alloc_contig_range test_pages_isolated(1e900, 1f0e9) failed
> > > > [   60.743572] alloc_contig_range test_pages_isolated(1ea00, 1f1e9) failed
> > > > [   60.750424] alloc_contig_range test_pages_isolated(1ea00, 1f2e9) failed
> > > > [   60.757239] alloc_contig_range test_pages_isolated(1ec00, 1f3e9) failed
> > > > [   60.764066] alloc_contig_range test_pages_isolated(1ec00, 1f4e9) failed
> > > > [   60.770893] alloc_contig_range test_pages_isolated(1ec00, 1f5e9) failed
> > > > [   60.777698] alloc_contig_range test_pages_isolated(1ec00, 1f6e9) failed
> > > > [   60.784526] alloc_contig_range test_pages_isolated(1f000, 1f7e9) failed
> > > > [   60.791148] drm tegra: Failed to alloc buffer: 8294400
> > > > 
> > > > I'm pretty sure this did work before next-20120926.
> > > > 
> > > 
> > > Can you double check this please?
> > > 
> > > This is a separate bug but may be related to the same series. However, CMA should
> > > be ignoring the "skip" hints and because it's sync compaction it should
> > > not be exiting due to lock contention. Maybe Marek will spot it.
> > 
> > I've written a small test module that tries to allocate growing blocks
> > of contiguous memory and it seems like with your patch this always fails
> > at 8 MiB.
> 
> You earlier said it also happens with Minchan's but your statment here
> is less clear. Does Minchan's also fail on the 8MiB boundary? Second,
> did the test module work with next-20120926?

The cmatest module that I use tries to allocate blocks from 4 KiB to 256
MiB (in increments of powers of two). With next-20120926 this always
fails at 8 MiB, independent of the CMA size setting (though I didn't
test setting the CMA size to <= 8 MiB, I assumed that would make the 8
MiB allocation fail anyway). Note that I had to apply the attached patch
which fixes a build failure on next-20120926. I believe that Mark Brown
posted a similar fix a few days ago. I'm also attaching a log from the
module's test run. There's also an interesting page allocation failure
at the very end of that log which I have not seen with next-20120925.

I've run the same tests on next-20120925 with the CMA size set to 256
MiB and only the 256 MiB allocation fails. This is normal since there
are other modules that already allocate smaller buffers from CMA, so a
whole 256 MiB won't be available.

Vanilla 3.6-rc6 shows the same behaviour as next-20120925. I will try
3.6-rc7 next since that's what next-20120926 is based on. If that
succeeds I'll try to bisect between 3.6-rc7 and next-20120926 to find
the culprit, but that will probably take some more time as I need to
apply at least one other commit on top to get the board to boot at all.

So this really isn't all that new, but I just wanted to confirm my
results from last week. We'll see if bisection shows up something
interesting.

Thierry

View attachment "mm-compaction-buildfix.patch" of type "text/plain" (918 bytes)

View attachment "cmatest.log" of type "text/plain" (182198 bytes)

Content of type "application/pgp-signature" skipped

Powered by blists - more mailing lists