From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Marc Singer <elf@buici.com>
Cc: Linux-Kernel <linux-kernel@vger.kernel.org>
Subject: Re: DMA memory, split_page, BUG_ON(PageCompound()), sound
Date: Mon, 10 Jul 2006 16:59:48 +1000 [thread overview]
Message-ID: <44B1FAE4.9070903@yahoo.com.au> (raw)
In-Reply-To: <20060710025103.GC28166@cerise.buici.com>
Marc Singer wrote:
> On Sun, Jul 09, 2006 at 01:26:06PM +1000, Nick Piggin wrote:
>
>>Marc Singer wrote:
>>
>>>I'm investigating why I am triggering a BUG_ON in split_page() when I
>>>use the sound subsystems dma memory allocation aide.
>>>
>>>The crux of the problem appears to be that snd_malloc_dev_pages()
>>>passes __GFP_COMP into dma_alloc_coherent(). On the ARM and several
>>>other architectures, the dma allocation code calls split_page () with
>>>pages allocated with this flag which, in turn, triggers the BUG_ON()
>>>check for the CompoundPage flag.
>>>
>>>So, the questions are these: Who is doing the wrong thing? Should the
>>>snd_malloc_dev_pages() call drop the __GFP_COMP flag? Should
>>>split_page() allow the page to be compound? Should __GFP_COMP be 0 on
>>>ARM and other architectures that don't support compound pages?
>>
>>I personally never liked the explicit __GFP_COMP going in everywhere,
>>and would have much preferred a GFP_USERMAP, which the architecture /
>>allocator could satisfy as they liked.
>
>
> Thus, the __GFP_COMP bit would be part of another flags such that it
> is set on x86 (or any other architecture that supports it) and clear
> on those that don't.
I guess you could do it a number of ways. Maybe having GFP_USERMAP
set __GFP_USERMAP|__GFP_COMP, and the arm dma memory allocator can
strip the __GFP_COMP.
If you get an explicit __GFP_COMP passed down, the allocator doesn't
know whether that was because they want a user mappable area, or
really want a compound page (in which case, stripping __GFP_COMP is
the wrong thing to do).
>
>
>>As a hack, you can make arm's dma_alloc_coherent() drop __GFP_COMP,
>>which should work.
>
>
> There are many architectures that have this problem, so I suspect that
> such a patch would be unappreciated.
>
Hacks usually are ;) It would get you working though.
If you want to write a patch that would be appreciated, that would be
appreciated.
--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com
next prev parent reply other threads:[~2006-07-10 7:10 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-07-09 0:07 DMA memory, split_page, BUG_ON(PageCompound()), sound Marc Singer
2006-07-09 3:26 ` Nick Piggin
2006-07-10 2:51 ` Marc Singer
2006-07-10 6:59 ` Nick Piggin [this message]
2006-07-10 16:26 ` Russell King
2006-07-10 17:34 ` Nick Piggin
2006-07-10 22:27 ` Marc Singer
2006-07-11 2:51 ` Marc Singer
2006-07-12 10:32 ` Russell King
2006-07-13 13:30 ` Takashi Iwai
2006-07-13 13:38 ` Nick Piggin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=44B1FAE4.9070903@yahoo.com.au \
--to=nickpiggin@yahoo.com.au \
--cc=elf@buici.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.