Re: [Bug 16148] page allocation failure. order:1, mode:0x50d0

[Andrew Morton <akpm@linux-foundation.org>]

(switched to email.  Please respond via emailed reply-to-all, not via the
bugzilla web interface).

(switching back to email, actually)

On Sun, 13 Jun 2010 13:01:57 GMT
bugzilla-daemon@bugzilla.kernel.org wrote:

> https://bugzilla.kernel.org/show_bug.cgi?id=16148
>
>
> Mikko C. <mikko.cal@gmail.com> changed:
>
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                  CC|                            |mikko.cal@gmail.com
>
>
>
>
> --- Comment #8 from Mikko C. <mikko.cal@gmail.com>  2010-06-13 13:01:53 ---
> I have been getting this with 2.6.35-rc2 and rc3.
> Could it be the same problem?
>
>
> X: page allocation failure. order:0, mode:0x4
> Pid: 1514, comm: X Not tainted 2.6.35-rc3 #1
> Call Trace:
>  [<ffffffff8108ce49>] ? __alloc_pages_nodemask+0x629/0x680
>  [<ffffffff8108c920>] ? __alloc_pages_nodemask+0x100/0x680
>  [<ffffffffa00db8f3>] ? ttm_get_pages+0x2c3/0x448 [ttm]
>  [<ffffffffa00d4658>] ? __ttm_tt_get_page+0x98/0xc0 [ttm]
>  [<ffffffffa00d4988>] ? ttm_tt_populate+0x48/0x90 [ttm]
>  [<ffffffffa00d4a26>] ? ttm_tt_bind+0x56/0xa0 [ttm]
>  [<ffffffffa00d5230>] ? ttm_bo_handle_move_mem+0x1d0/0x430 [ttm]
>  [<ffffffffa00d76d6>] ? ttm_bo_move_buffer+0x166/0x180 [ttm]
>  [<ffffffffa00b9736>] ? drm_mm_kmalloc+0x26/0xc0 [drm]
>  [<ffffffff81030ea9>] ? get_parent_ip+0x9/0x20
>  [<ffffffffa00d7786>] ? ttm_bo_validate+0x96/0x130 [ttm]
>  [<ffffffffa00d7b35>] ? ttm_bo_init+0x315/0x390 [ttm]
>  [<ffffffffa0122eb8>] ? radeon_bo_create+0x118/0x210 [radeon]
>  [<ffffffffa0122fb0>] ? radeon_ttm_bo_destroy+0x0/0xb0 [radeon]
>  [<ffffffffa013704c>] ? radeon_gem_object_create+0x8c/0x110 [radeon]
>  [<ffffffffa013711f>] ? radeon_gem_create_ioctl+0x4f/0xe0 [radeon]
>  [<ffffffffa00b10e6>] ? drm_ioctl+0x3d6/0x470 [drm]
>  [<ffffffffa01370d0>] ? radeon_gem_create_ioctl+0x0/0xe0 [radeon]
>  [<ffffffff810b965f>] ? do_sync_read+0xbf/0x100
>  [<ffffffff810c8965>] ? vfs_ioctl+0x35/0xd0
>  [<ffffffff810c8b28>] ? do_vfs_ioctl+0x88/0x530
>  [<ffffffff81031ed7>] ? sub_preempt_count+0x87/0xb0
>  [<ffffffff810c9019>] ? sys_ioctl+0x49/0x80
>  [<ffffffff810ba4fe>] ? sys_read+0x4e/0x90
>  [<ffffffff810024ab>] ? system_call_fastpath+0x16/0x1b

That's different.  ttm_get_pages() looks pretty busted to me.  It's not
using __GFP_WAIT and it's not using __GFP_FS.  It's using a plain
GFP_DMA32 so it's using atomic allocations even though it doesn't need
to.  IOW, it's shooting itself in the head.

Given that it will sometimes use GFP_HIGHUSER which includes __GFP_FS
and __GFP_WAIT, I assume it can always include __GFP_FS and __GFP_WAIT.
If so, it should very much do so.  If not then the function is
misdesigned and should be altered to take a gfp_t argument so the
caller can tell ttm_get_pages() which is the strongest allocation mode
which it may use.

> [TTM] Unable to allocate page.
> radeon 0000:01:05.0: object_init failed for (7827456, 0x00000002)
> [drm:radeon_gem_object_create] *ERROR* Failed to allocate GEM object (7827456,
> 2, 4096, -12)

This bug actually broke stuff for you.

Something like this:

--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c~a
+++ a/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -677,7 +677,7 @@ int ttm_get_pages(struct list_head *page
 	/* No pool for cached pages */
 	if (pool == NULL) {
 		if (flags & TTM_PAGE_FLAG_DMA32)
-			gfp_flags |= GFP_DMA32;
+			gfp_flags |= GFP_KERNEL|GFP_DMA32;
 		else
 			gfp_flags |= GFP_HIGHUSER;
 
_

although I wonder whether it should be using pool->gfp_flags.


It's a shame that this code was developed and merged in secret :( Had
we known, we could have looked at enhancing mempools to cover the
requirement, or at implementing this in some generic fashion rather
than hiding it down in drivers/gpu/drm.