Re: replace "memset(...,0,PAGE_SIZE)" calls with "clear_page()"?

[Robert P. J. Day]

On Mon, 1 Jan 2007, Arjan van de Ven wrote:

> >   Given the above, some basic suggestions for page-based memory management:
> >
> >  (a) If you need to allocate or free a single page, use the single page
> >      version of the routine/macro, rather than calling the multi-page
> >      version with an order value of zero, such as:
> >
> > 	alloc_pages(gfp_mask, 0);	/* no */
> > 	alloc_page(gfp_mask);		/* better */
> >
> >  (b) If you need to allocate a single zeroed page by logical address,
> >      use get_zeroed_page(), rather than __get_free_page() followed
> >      by a call to memset() to clear that page.
>
> both look good... I'd be in favor of this. Maybe also add a part
> about using GFP_KERNEL whenever possible, GFP_NOFS from filesystem
> writeout code and GFP_NOIO from block writeout code (and never doing
> in_interrupt()?GFP_ATOMIC:GFP_KERNEL !)

it strikes me that that latter part is starting to go beyond the scope
of simple coding style aesthetics and getting into actual coding
distinctions.  would that really be appropriate for the CodingStyle
doc?  i'm just asking.

> >  (c) If you need to specifically allocate some DMA pages, use the
> >      __get_dma_pages() macro, as in:
> >
> > 	__get_free_pages(GFP_KERNEL|GFP_DMA, order)	/* no */
> > 	__get_dma_pages(GFP_KERNEL, order)		/* better */
>
> this.. does not really. GFP_DMA is an ancient artifact from the ISA
> days. Better to describe the dma mapping interface (well give a
> pointer to the doc that already exists about that), that one is
> REALLY for allocating dma pages in this century.

ok, i was just trying to make the calls consistent based on what i
could see in the current source code.  i'm still reviewing the
material on DMA -- feel free to suggest better wording.

rday

p.s.  what DMA doc are you referring to above?  DMA-mapping.txt?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/