lkml.org 
[lkml]   [2006]   [Mar]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH 10 of 20] ipath - support for userspace apps using core driver
From
Date
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.

> 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?

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.

<b

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-03-17 17:13    [W:0.432 / U:0.496 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site