From: Andrew Morton <akpm@linux-foundation.org>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: "David S. Miller" <davem@davemloft.net>, netdev@vger.kernel.org
Subject: Re: [Bugme-new] [Bug 16083] New: swapper: Page allocation failure
Date: Thu, 3 Jun 2010 15:01:08 -0700 [thread overview]
Message-ID: <20100603150108.38215813.akpm@linux-foundation.org> (raw)
In-Reply-To: <1275601036.2533.63.camel@edumazet-laptop>
On Thu, 03 Jun 2010 23:37:16 +0200
Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le jeudi 03 juin 2010 __ 23:13 +0200, Eric Dumazet a __crit :
>
> > MTU=9000 on a system with 4K pages... Oh well...
> >
> > maybe net/ipv6/mcast.c should cap dev->mtu to PAGE_SIZE-128 or
> > something, so that order-0 allocations are done.
> >
> >
>
> Something like this patch (completely untested) :
>
> [PATCH] ipv6: avoid high order allocations
>
> With mtu=9000, mld_newpack() use order-2 GFP_ATOMIC allocations, that
> are very unreliable, on machines where PAGE_SIZE=4K
>
> Limit allocated skbs to be at most one page. (order-0 allocations)
>
Maybe - I wouldn't know how desirable that is from the
imapct-on-efficiency POV. But I think most failures I've seen are for
regular old tcpipv4. Often with e1000, which does larger-than-needed
allocations for (iirc) weird alignment requirements.
> ---
> net/ipv6/mcast.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/net/ipv6/mcast.c b/net/ipv6/mcast.c
> index 59f1881..3484794 100644
> --- a/net/ipv6/mcast.c
> +++ b/net/ipv6/mcast.c
> @@ -1356,7 +1356,10 @@ static struct sk_buff *mld_newpack(struct net_device *dev, int size)
> IPV6_TLV_PADN, 0 };
>
> /* we assume size > sizeof(ra) here */
> - skb = sock_alloc_send_skb(sk, size + LL_ALLOCATED_SPACE(dev), 1, &err);
> + size += LL_ALLOCATED_SPACE(dev);
> + /* limit our allocations to order-0 page */
> + size = min(size, SKB_MAX_ORDER(0, 0));
> + skb = sock_alloc_send_skb(sk, size, 1, &err);
>
> if (!skb)
> return NULL;
An alternative which retains any performance benefit from the order-2
allocation would be:
p = alloc_pages(__GFP_NOWARN|..., 2);
if (!p)
p = alloc_pages(..., 0);
if you see what I mean.
This would also fix any retry/timeout-related stalls which people might
experience when the order-2 allocation fails, so it might make things
better in general.
next prev parent reply other threads:[~2010-06-03 22:01 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <bug-16083-10286@https.bugzilla.kernel.org/>
2010-06-03 20:02 ` [Bugme-new] [Bug 16083] New: swapper: Page allocation failure Andrew Morton
2010-06-03 21:13 ` Eric Dumazet
2010-06-03 21:37 ` Eric Dumazet
2010-06-03 22:01 ` Andrew Morton [this message]
2010-06-05 10:04 ` David Miller
2010-06-03 21:39 ` Andrew Morton
2010-06-03 21:58 ` Eric Dumazet
2010-06-03 22:11 ` Andrew Morton
2010-06-05 9:59 ` David Miller
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=20100603150108.38215813.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=davem@davemloft.net \
--cc=eric.dumazet@gmail.com \
--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.