mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Dan Noé" <dpn@isomerica.net>
To: Peter Zijlstra <peterz@infradead.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Page alloc failures under network/disk IO load
Date: Thu, 4 Dec 2008 13:54:43 -0500	[thread overview]
Message-ID: <20081204135443.7c24234a@rockhopper.limebrokerage.com> (raw)
In-Reply-To: <1228380128.5092.15.camel@twins>

On Thu, 04 Dec 2008 09:42:08 +0100
Peter Zijlstra <peterz@infradead.org> wrote:

> On Thu, 2008-12-04 at 09:23 +0100, Peter Zijlstra wrote:
> > On Wed, 2008-12-03 at 22:27 -0500, Dan Noé wrote:
> > > This is on Linux 2.6.28-rc7, on a Core 2 Duo.  The system has
> > > plenty of memory:
> > > 
> > >              total       used       free     shared    buffers
> > > cached
> > > Mem:          1893       1822         70          0          0
> > 
> > filled to the brim with data
> > 
> > > 1573
> > > -/+ buffers/cache:        249       1644
> > > Swap:         1906         37       1868
> > > 
> > > I am using rsync to transfer data onto this system.  The
> > > filesystem is XFS, and the target drive is a 1TB Western Digital
> > > on ata_piix.  The system files are on a RAID 1 (Linux md, also on
> > > ata_piix).
> > > 
> > > Periodically I get page allocation failures, from
> > > __netdev_alloc_skb. I suppose this causes the driver to drop
> > > packets and thus hurts performance.
> > 
> > There isn't much we can do about that, memory is filled and your
> > network card tries to allocate memory in a mode that doesn't allow
> > freeing some.
> > 
> > Looking at the timestamps its not very frequent, so it doesn't hurt
> > performance much if anything. If you're really bothered with this,
> > you could quiet it by sticking in a __GFP_NOWARN in
> > __netdev_alloc_skb() or something..
> 
> Another thing you can do is increase /proc/sys/vm/min_free_kbytes

I'm a bit confused because on another system (2.6.26.3) I never see
messages like this despite having the same amount of physical RAM in
each.  The 2.6.26.3 system is also under more active use, and has more
userspace memory usage.  On that system:

             total       used       free     shared    buffers
cached Mem:          2017       1681        335          0
99        603 -/+ buffers/cache:        979       1037
Swap:          972        137        835

dpn@colobus:~$ cat /proc/sys/vm/min_free_kbytes
3816

Yet on the system where I saw the allocation failures:

dpn@trout:~/kernels/linux-2.6$ cat /proc/sys/vm/min_free_kbytes
5711

If I understand it correctly the issue is that __netdev_alloc_skb must
make a GFP_ATOMIC allocation, which fails because the page cache must
evict pages before there is sufficient memory.  And
min_free_kbytes allows tuning of the point where try_to_free_pages is
called and thus the "reserve" memory available.  Is that correct?

Wouldn't a higher min_free_kbytes mean less likelihood of GFP_ATOMIC
allocations failing?  Or are these allocations failing on my 2.6.26.3
system and I don't know it because of different config options?

Why am I seeing this on the system with the *higher* min_free_kbytes?

Cheers,
Dan

-- 
Dan Noé
Software Engineer
Lime Brokerage LLC
781-370-2518

  reply	other threads:[~2008-12-04 18:54 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-04  3:27 Dan Noé
2008-12-04  8:23 ` Peter Zijlstra
2008-12-04  8:42   ` Peter Zijlstra
2008-12-04 18:54     ` Dan Noé [this message]
2008-12-04 22:40       ` Francois Romieu
2008-12-04 23:09         ` Dan Noé
2008-12-05  4:08           ` Robert Hancock
2008-12-05  7:13       ` Peter Zijlstra

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=20081204135443.7c24234a@rockhopper.limebrokerage.com \
    --to=dpn@isomerica.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterz@infradead.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

all inboxes | Powered by JetHome®