[lkml]   [2009]   [Oct]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Subject[PATCH 0/5] Candidate fix for increased number of GFP_ATOMIC failures V2
Sorry for the large cc list. Variations of this bug have cropped up in a
number of different places and so there are a fair few people that should
be vaguely aware of what's going on.

Since 2.6.31-rc1, there have been an increasing number of GFP_ATOMIC
failures. A significant number of these have been high-order GFP_ATOMIC
failures and while they are generally brushed away, there has been a large
increase in them recently and there are a number of possible areas the
problem could be in - core vm, page writeback and a specific driver. The
bugs affected by this that I am aware of are;

[Bug #14141] order 2 page allocation failures in iwlagn
Commit 4752c93c30441f98f7ed723001b1a5e3e5619829 introduced GFP_ATOMIC
allocations within the wireless driver. This has caused large numbers
of failure reports to occur as reported by Frans Pop. Fixing this
requires changes to the driver if it wants to use GFP_ATOMIC which
is in the hands of Mohamed Abbas and Reinette Chatre. However,
it is very likely that it has being compounded by core mm changes
that this series is aimed at.

[Bug #14141] order 2 page allocation failures (generic)
This problem is being tracked under bug #14141 but chances are it's
unrelated to the wireless change. Tobi Oetiker has reported that a
virtualised machine using a bridged interface is reporting a small
number of order-5 GFP_ATOMIC failures. He has reported that the
errors can be suppressed with kswapd patches in this series. However,
I would like to confirm they are necessary.

[Bug #14265] ifconfig: page allocation failure. order:5, mode:0x8020 w/ e100
Karol Lewandows reported that e100 fails to allocate order-5
GFP_ATOMIC when loading firmware during resume. This has started
happening relatively recent.

[No BZ ID] Kernel crash on 2.6.31.x (kcryptd: page allocation failure..)
This apparently is easily reproducible, particular in comparison to
the other reports. The point of greatest interest is that this is
order-0 GFP_ATOMIC failures. Sven, I'm hoping that you in particular
will be able to follow the tests below as you are the most likely
person to have an easily reproducible situation.

[No BZ ID] page allocation failure message kernel (tty-related)
reported at: Looks the same
as the order-2 failures.

There are 5 patches in this series. For people affected by this bug,
I'm afraid there is a lot of legwork involved to help pin down which of
these patches are relevant. These patches are all against 2.6.32-rc5 and
have been tested on X86 and X86-64 by running the sysbench benchmark to
completion. I'll post against where necessary.

Test 1: Verify your problem occurs on 2.6.32-rc5 if you can

Test 2: Apply the following two patches and test again

1/5 page allocator: Always wake kswapd when restarting an allocation attempt after direct reclaim failed
2/5 page allocator: Do not allow interrupts to use ALLOC_HARDER

These patches correct problems introduced by me during the 2.6.31-rc1
merge window. The patches were not meant to introduce any functional
changes but two were missed.

If your problem goes away with just these two patches applied,
please tell me.

Test 3: If you are getting allocation failures, try with the following patch

3/5 vmscan: Force kswapd to take notice faster when high-order watermarks are being hit

This is a functional change that causes kswapd to notice sooner
when high-order watermarks have been hit. There have been a number
of changes in page reclaim since 2.6.30 that might have delayed
when kswapd kicks in for higher orders

If your problem goes away with these three patches applied, please
tell me

Test 4: If you are still getting failures, apply the following
4/5 page allocator: Pre-emptively wake kswapd when high-order watermarks are hit

This patch is very heavy handed and pre-emptively kicks kswapd when
watermarks are hit. It should only be necessary if there has been
significant changes in the timing and density of page allocations
from an unknown source. Tobias, this patch is largely aimed at you.
You reported that with patches 3+4 applied that your problems went
away. I need to know if patch 3 on its own is enough or if both
are required

If your problem goes away with these four patches applied, please
tell me

Test 5: If things are still screwed, apply the following
5/5 Revert 373c0a7e, 8aa7e847: Fix congestion_wait() sync/async vs read/write confusion

Frans Pop reports that the bulk of his problems go away when this
patch is reverted on 2.6.31. There has been some confusion on why
exactly this patch was wrong but apparently the conversion was not
complete and further work was required. It's unknown if all the
necessary work exists in 2.6.31-rc5 or not. If there are still
allocation failures and applying this patch fixes the problem,
there are still snags that need to be ironed out.

Test 6: If only testing, test with patches 1, 2 and 5 as posted for that kernel
Even if patches 3, 4 or both are necessary against mainline, I'm
hoping they are unnecessary against -stable.

Thanks to all that reported problems and are testing this. The major bulk of
the work was done by Frans Pop so a big thanks to him in particular. I/we owe
him beers.

arch/x86/lib/usercopy_32.c | 2 +-
drivers/block/pktcdvd.c | 10 ++++------
drivers/md/dm-crypt.c | 2 +-
fs/fat/file.c | 2 +-
fs/fuse/dev.c | 8 ++++----
fs/nfs/write.c | 8 +++-----
fs/reiserfs/journal.c | 2 +-
fs/xfs/linux-2.6/kmem.c | 4 ++--
fs/xfs/linux-2.6/xfs_buf.c | 2 +-
include/linux/backing-dev.h | 11 +++--------
include/linux/blkdev.h | 13 +++++++++----
mm/backing-dev.c | 7 ++++---
mm/memcontrol.c | 2 +-
mm/page-writeback.c | 2 +-
mm/page_alloc.c | 41 ++++++++++++++++++++++++++---------------
mm/vmscan.c | 17 +++++++++++++----
16 files changed, 75 insertions(+), 58 deletions(-)

 \ /
  Last update: 2009-10-22 16:25    [W:0.301 / U:16.280 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site