All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bill Davidsen <davidsen@tmr.com>
To: Jesse Brandeburg <jesse.brandeburg@gmail.com>
Cc: linux-kernel <linux-kernel@vger.kernel.org>,
	Kernel Netdev Mailing List <netdev@vger.kernel.org>
Subject: Re: 2.6.14-rc5 e1000 and page allocation failures.. still
Date: Tue, 25 Oct 2005 16:40:34 -0400	[thread overview]
Message-ID: <435E9842.3010604@tmr.com> (raw)
In-Reply-To: <4807377b0510241528m6afc3501w9d98d66658a38973@mail.gmail.com>

Jesse Brandeburg wrote:
> On 10/23/05, Robert Hancock <hancockr@shaw.ca> wrote:
> 
>>John Bäckstrand wrote:
>>
>>>Im seeing a massive amount of page allocation failures with 2.6.14-rc5,
>>>and also earlier kernels, see "E1000 - page allocation failure - saga
> 
> [snip]
> 
>>It looks like you have enough memory free - the problem is that the
>>driver is allocating a block of memory with order 3, which is 8 pages.
>>Quite likely there are not enough contiguous free pages to satisfy that.
>>
>>That's an awful big buffer size for a packet - I assume you're using
>>jumbo frames or something? Ideally the driver and hardware should be
>>able to allocate a buffer for those packets in multiple chunks, but I
>>have no idea if this is possible.
> 
> 
> the latest e1000 driver (6.2.15) from http://sf.net/projects/e1000
> fixes this by using multiple descriptors for jumbo frames, therefore
> only doing order 0 (single page) page allocations.
> 
> let us know how it goes.
> 
> BTW why is this so much more common with recent kernels?

I don't know why it's more common, but I agree that it seems so. I have 
speculated that it may be related to 4k stack, but I can't even generate 
a credible wild-ass guess on that, much less find any evidence, so I 
doubt that's much if any correlation.

Getting memory a page at a time is ugly, but it will probably work just 
fine.

-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

  reply	other threads:[~2005-10-25 20:39 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <50tDw-1FH-5@gated-at.bofh.it>
2005-10-24  0:40 ` 2.6.14-rc5 e1000 and page allocation failures.. still Robert Hancock
2005-10-24 22:28   ` Jesse Brandeburg
2005-10-25 20:40     ` Bill Davidsen [this message]
2005-10-22 15:29 John Bäckstrand

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=435E9842.3010604@tmr.com \
    --to=davidsen@tmr.com \
    --cc=jesse.brandeburg@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.