Bryan O'Sullivan wrote:
On Fri, 2006-03-17 at 11:37 +1100, Nick Piggin wrote:
But it doesn't look like dma_alloc_coherent is guaranteed to return
memory allocated from the regular page allocator, nor even memory
backed by a struct page.
Hmm. Which of the implementations that you've seen will return
something not backed by a struct page? On the half dozen arches I've
looked at (i386/x86_64, powerpc, sparc64, ia64, mips), every one uses
either kmalloc, __get_free_pages, or __alloc_pages at some point, and I
think they all have struct pages behind them.
Well I was mainly just looking at the interface definition and that it
only returns an address. i386 specifically looks like it can return
ioremap memory in some cases, right? (which I don't think needs to have
a struct page behind it)
For example, I see one that returns kmalloc()ed memory. If the pages
for the slab are already allocated then __GFP_COMP will not do anything
there.
Bleh. Perhaps I'm being dense here, but if I'm making a request of
non-zero order and the slab has already been allocated, won't it be
populated with compound pages anyway? Or will it have been allocated as
a single giant compound page, just handing me back individual hunks of
the appropriate size?
By the looks of the slab implementation, it will vary depending on
whether or not the slab was already allocated and whether that was using
__GFP_COMP or not.
I ask this because I seemed to be getting compound pages out of
dma_alloc_coherent even when I *wasn't* passing in __GFP_COMP. This is
apparently why PG_private was set on the individual pages I was getting
back.
I think the reason was a little different: you're getting a higher order
page. This can either be compound or non-compound. If it is not compound,
then you (or the VM) can easily end up freeing one of its constituent
pages (and PagePrivate is set when that page is free in the allocator).
Then when you go to free the whole higher-order page, it finds that one
of its constituent pages has PagePrivate set (which is a bug).
--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]