All of lore.kernel.org
 help / color / mirror / Atom feed
From: Robert Hancock <hancockr@shaw.ca>
To: linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: 2.6.14-rc5 e1000 and page allocation failures.. still
Date: Sun, 23 Oct 2005 18:40:06 -0600	[thread overview]
Message-ID: <435C2D66.6030708@shaw.ca> (raw)
In-Reply-To: <50tDw-1FH-5@gated-at.bofh.it>

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 
> continues :(". Machine is a 1Ghz Athlon with 256MB RAM. Attached is 
> example dmesg output. The stack traces come in many variants. Killing 
> processes using RAM only seems to help temporarily. Ive also tried 
> setting vm.min_free_kbytes=16384, which used to work pretty well, but 
> this does not help (atleast not in the state the machine is currently 
> in, without rebooting).
> 
> free currently gives:
> 
>              total       used       free     shared    buffers     cached
> Mem:        256520     239128      17392          0       5372      67500
> -/+ buffers/cache:     166256      90264
> Swap:       506036      21248     484788
> 
> 
> I havent yet tried rebooting and using the vm.min_free_kbytes=16384 from 
> scratch, but I think something with the default for this is wrong if it 
> results in this many page allocation errors. The machine is serving 
> files from an encrypted partition with reiserfs on it, and I obivously 
> use the e1000 driver.
> 
> ---
> John Bäckstrand
> 
> 
> ------------------------------------------------------------------------
> 
> [149649.847890] kcryptd/0: page allocation failure. order:3, mode:0x20

..

> [149649.849933] Free pages:       16148kB (0kB HighMem)

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.

-- 
Robert Hancock      Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@nospamshaw.ca
Home Page: http://www.roberthancock.com/


       reply	other threads:[~2005-10-24  0:41 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 ` Robert Hancock [this message]
2005-10-24 22:28   ` 2.6.14-rc5 e1000 and page allocation failures.. still Jesse Brandeburg
2005-10-25 20:40     ` Bill Davidsen
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=435C2D66.6030708@shaw.ca \
    --to=hancockr@shaw.ca \
    --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 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.