public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Pierre Ossman <drzeus-list@drzeus.cx>
To: LKML <linux-kernel@vger.kernel.org>
Subject: __GFP flags and kmalloc failures
Date: Tue, 02 Nov 2004 16:49:20 +0100	[thread overview]
Message-ID: <4187AC80.6050409@drzeus.cx> (raw)

I'm trying to allocate a buffer to be used for ISA DMA and I'm 
experiencing some difficulties.

I'm allocating a 64kB buffer (max size for low ISA DMA) using:

kmalloc(65536, GFP_KERNEL | GFP_DMA);

The choice of flags are from another driver that does ISA DMA so I 
didn't put too much thought into them at first.

The problem is now that this allocation doesn't always succeed. When it 
fails I get:

insmod: page allocation failure. order:4, mode:0x11

and a nice little stack dump.

Digging around in gfp.h to see if I have the proper flags I find that I 
currently have the following:

* __GFP_WAIT : This seems to indicate that the process should be put to 
sleep until the allocation can succeed. Doesn't seem to work that way 
though.

* __GFP_IO : What is meant with physical IO? PCI DMA? This buffer needs 
only be read by the ISA DMA controller and the driver in kernel space. 
Any useful data is copied to other buffers.

* __GFP_FS : Since the data is copied before use this probably isn't needed.

* __GFP_DMA : From what I've been told, this flags causes the allocator 
to do the magic required for the buffer to end up i memory accessible 
from the ISA DMA controller. So this seems to be the only flag that 
actually does anything useful.

My question is now, why does the allocation fail (sometimes) and what 
should I do about it?

Memory fragmentation and overusage seems like reasons to why but why 
doesn't the kernel throw out cache pages and reorganise user pages so 
that the allocation can succeed?

As for solutions I've tried using __GFP_REPEAT which seems to do the 
trick. But the double underscore indicates (at least to me) that these 
are internal defines that shouldn't be used except for very special 
cases. What is the policy about these?

Rgds
Pierre

             reply	other threads:[~2004-11-02 15:57 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-11-02 15:49 Pierre Ossman [this message]
2004-11-02 14:44 ` __GFP flags and kmalloc failures Marcelo Tosatti
2004-11-02 18:01   ` Pierre Ossman
2004-11-02 15:26     ` Marcelo Tosatti
2004-11-02 18:31       ` Pierre Ossman
2004-11-02 15:55         ` Marcelo Tosatti
2004-11-02 19:06           ` Pierre Ossman

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=4187AC80.6050409@drzeus.cx \
    --to=drzeus-list@drzeus.cx \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox