Messages in this thread | | | Date | Tue, 11 Nov 2008 00:06:52 -0800 | From | Andrew Morton <> | Subject | Re: allocation failure in b43/ssb |
| |
On Fri, 7 Nov 2008 14:54:03 -0500 "John W. Linville" <linville@tuxdriver.com> wrote:
> On Fri, Nov 07, 2008 at 02:09:44PM -0500, Dave Jones wrote: > > We just had a report from a user who spotted a bunch of messages > > of the form below in his logs.. > > <snip> > > > The kernel is a little old (2.6.26). > > > > Looking at it though, I'm puzzled.. > > > > It seems we failed to allocate an order-1 allocation, even though > > we had memory available in the DMA and normal zones. > > > > What am I missing? > > > > Full logs at https://bugzilla.redhat.com/attachment.cgi?id=322882 > > Most of those traces look a little scrambled, but as best as I can > tell that call to setup_rx_descbuffer comes from dma_rx. That means > that the call to __dev_alloc_skb is done with GFP_ATOMIC. I don't > know if that factors into the answer to what is happening or not. >
It does. If there were not any two physically-contiguous free pages in the page allocator reserves, __alloc_pages() will not be able to satisfy that order-1 allocation request.
You can have plenty of free memory, but if it's all fragmented, non-order-0 atomic allocations can still fail.
GFP_KERNEL allocations can run page reclaim to _make_ the allocation request succeed in this situation.
| |