__get_free_pages: can GFP_DMA omit GFP_KERNEL and GFP_ATOMIC?

__get_free_pages: can GFP_DMA omit GFP_KERNEL and GFP_ATOMIC?

[Robert P. J. Day]

a two-parter:

  first, can a call to __get_free_pages to allocate DMA-able memory
omit specifying either of GFP_KERNEL or GFP_ATOMIC?  love's book on
kernel development strongly suggests you need to specify one or the
other, but there are a few instances in the tree like this:

drivers/s390/net/claw.c:                        (void *)__get_free_pages(__GFP_DMA,
drivers/s390/net/claw.c:                   p_buff=(void *)__get_free_pages(__GFP_DMA,

where you can see that the only type flag is __GFP_DMA.  is that
meaningful?

  and, second, i only noticed this as i was going to submit a short
patch to replace __get_free_pages calls for DMA-able memory with the
existing equivalent macro __get_dma_pages.  is that still considered a
worthwhile cleanup?  there's not that many examples of it, and it
would just make things consistent.

rday

-- 
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================

Re: __get_free_pages: can GFP_DMA omit GFP_KERNEL and GFP_ATOMIC?

[Christoph Lameter]

On Sun, 3 Jun 2007, Robert P. J. Day wrote:

>   first, can a call to __get_free_pages to allocate DMA-able memory
> omit specifying either of GFP_KERNEL or GFP_ATOMIC?  love's book on
> kernel development strongly suggests you need to specify one or the
> other, but there are a few instances in the tree like this:

Sure that seems to be equivalent to GFP_ATOMIC with no access to emergency 
pool memory.

>   and, second, i only noticed this as i was going to submit a short
> patch to replace __get_free_pages calls for DMA-able memory with the
> existing equivalent macro __get_dma_pages.  is that still considered a
> worthwhile cleanup?  there's not that many examples of it, and it
> would just make things consistent.

Sure.

Re: __get_free_pages: can GFP_DMA omit GFP_KERNEL and GFP_ATOMIC?

[Robert P. J. Day]

On Mon, 4 Jun 2007, Christoph Lameter wrote:

> On Sun, 3 Jun 2007, Robert P. J. Day wrote:
>
> >   first, can a call to __get_free_pages to allocate DMA-able
> > memory omit specifying either of GFP_KERNEL or GFP_ATOMIC?
> > love's book on kernel development strongly suggests you need to
> > specify one or the other, but there are a few instances in the
> > tree like this:
>
> Sure that seems to be equivalent to GFP_ATOMIC with no access to
> emergency pool memory.
>
> >   and, second, i only noticed this as i was going to submit a
> > short patch to replace __get_free_pages calls for DMA-able memory
> > with the existing equivalent macro __get_dma_pages.  is that still
> > considered a worthwhile cleanup?  there's not that many examples
> > of it, and it would just make things consistent.
>
> Sure.

all right, then some of those __get_free_pages() calls would translate
to calls of the form __get_dma_pages(0, ...) -- is that what you're
saying?  or would it be equivalent and preferable to put GFP_ATOMIC in
there just so it looks not so weird?

rday
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================

Re: __get_free_pages: can GFP_DMA omit GFP_KERNEL and GFP_ATOMIC?

[Christoph Lameter]

On Mon, 4 Jun 2007, Robert P. J. Day wrote:

> all right, then some of those __get_free_pages() calls would translate
> to calls of the form __get_dma_pages(0, ...) -- is that what you're
> saying?  or would it be equivalent and preferable to put GFP_ATOMIC in
> there just so it looks not so weird?

Put GFP_ATOMIC in there so that it does not look weird.

GFP_ATOMIC & ~__GFP_HIGH == GFP_NOWAIT

So these should have GFP_NOWAIT as far as I can tell?

Re: __get_free_pages: can GFP_DMA omit GFP_KERNEL and GFP_ATOMIC?

[Robert P. J. Day]

On Mon, 4 Jun 2007, Christoph Lameter wrote:

> On Mon, 4 Jun 2007, Robert P. J. Day wrote:
>
> > all right, then some of those __get_free_pages() calls would translate
> > to calls of the form __get_dma_pages(0, ...) -- is that what you're
> > saying?  or would it be equivalent and preferable to put GFP_ATOMIC in
> > there just so it looks not so weird?
>
> Put GFP_ATOMIC in there so that it does not look weird.
>
> GFP_ATOMIC & ~__GFP_HIGH == GFP_NOWAIT
>
> So these should have GFP_NOWAIT as far as I can tell?

beats me.  just FYI, it's not like this would be a massive change --
here's the entire collection of candidates for conversion over to
__get_dma_pages():

$ grep -r "get_free.*GFP_DMA" *
arch/s390/kernel/smp.c:                 __get_free_pages(GFP_KERNEL | GFP_DMA,
drivers/net/arm/ep93xx_eth.c:           page = (void *)__get_free_page(GFP_KERNEL | GFP_DMA);
drivers/net/arm/ep93xx_eth.c:           page = (void *)__get_free_page(GFP_KERNEL | GFP_DMA);
drivers/s390/net/qeth_main.c:                   ptr = (void *) __get_free_page(GFP_KERNEL|GFP_DMA);
drivers/s390/net/claw.c:                        (void *)__get_free_pages(__GFP_DMA,
drivers/s390/net/claw.c:                        (void *)__get_free_pages(__GFP_DMA,
drivers/s390/net/claw.c:                   p_buff=(void *)__get_free_pages(__GFP_DMA,
drivers/s390/net/claw.c:                        (void *)__get_free_pages(__GFP_DMA,
drivers/s390/net/claw.c:                        p_buff = (void *)__get_free_pages(__GFP_DMA,
drivers/s390/block/dasd.c:      device->ccw_mem = (void *) __get_free_pages(GFP_ATOMIC | GFP_DMA, 1);
drivers/s390/char/tty3270.c:                    __get_free_pages(GFP_KERNEL|GFP_DMA, 0);
drivers/s390/char/sclp_cpi.c:   sccb = (struct cpi_sccb *) __get_free_page(GFP_KERNEL | GFP_DMA);
drivers/s390/cio/cmf.c:         mem = (void*)__get_free_pages(GFP_KERNEL | GFP_DMA,
lib/swiotlb.c:          io_tlb_start = (char *)__get_free_pages(GFP_DMA | __GFP_NOWARN,
lib/swiotlb.c:  io_tlb_overflow_buffer = (void *)__get_free_pages(GFP_DMA,
sound/oss/sscape.c:             start_addr = (char *) __get_free_pages(GFP_ATOMIC|GFP_DMA, sz);
sound/oss/hal2.c:       codec->buffer = (unsigned char *)__get_free_pages(GFP_KERNEL | GFP_DMA,
sound/oss/dmabuf.c:             start_addr = (char *) __get_free_pages(GFP_ATOMIC|GFP_DMA|__GFP_NOWARN, sz);

  and, obviously, it's not worth doing anything under sound/.  so
we're not talking enormous cleanup or anything.

rday
-- 
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================