Re: Kernel 2.6.9 Multiple Page Allocation Failures

[Andrew Morton]

Stefan Schmidt <zaphodb@xxxxxxxxxxx> wrote:
>
> On Thu, Dec 02, 2004 at 10:03:48PM +0100, Lukas Hejtmanek wrote:
> > > > I found out that 2.6.6-bk4 kernel is OK. 
> > > That kernel didn't have the TSO thing.  Pretty much all of these reports
> > > have been against e1000_alloc_rx_buffers() since the TSO changes went in.
> > > Did you try disabling TSO, btw?
> > I did it. Allocation failure is still there :(
> I had no luck with/without TSO either but on tg3.
> I disabled the on-disk-caching component of the application and it now runs
> without page allocation errors. Currently it is running smoothly at ~500mbit/s
> and ~80kpps in each direction at ~44k interrupts/s, so the problematic
> combination seems to be many open files, high i/o transaction rate or
> troughput and heavy networking load. (tso currently on)
> Caching on ext2-fs in general seemed to generate less page allocation errors
> than on xfs and none of the traces i looked over so far showed involvement
> of the filesystem i.e. were all triggered by alloc_skb.

hm, OK, interesting.

It's quite possible that XFS is performing rather too many GFP_ATOMIC
allocations and is depleting the page reserves.  Although increasing
/proc/sys/vm/min_free_kbytes should help there.

Nathan, it would be a worthwhile exercise to consider replacing GFP_ATOMIC
with (GFP_ATOMIC & ~ __GFP_HIGH) where appropriate.  This is because
GFP_ATOMIC does two distinct things:

a) Don't sleep, so we can call it from within-spinlock and interrupt contexts.

b) Dip further into the page reserves.

If there are places in XFS where it only needs one of these two behaviours,
it would be good to select just that one.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/