netdev - Re: [PATCH net-next 1/3] net: allow > 0 order atomic page alloc in skb_page_frag

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1387819497.12212.1.camel@edumazet-glaptop2.roam.corp.google.com>
Date:	Mon, 23 Dec 2013 09:24:57 -0800
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Jason Wang <jasowang@...hat.com>
Cc:	Michael Dalton <mwdalton@...gle.com>,
	"David S. Miller" <davem@...emloft.net>, netdev@...r.kernel.org,
	Eric Dumazet <edumazet@...gle.com>,
	Rusty Russell <rusty@...tcorp.com.au>,
	"Michael S. Tsirkin" <mst@...hat.com>,
	virtualization@...ts.linux-foundation.org
Subject: Re: [PATCH net-next 1/3] net: allow > 0 order atomic page alloc in
 skb_page_frag_refill

On Mon, 2013-12-23 at 15:52 +0800, Jason Wang wrote:
> On 12/17/2013 08:16 AM, Michael Dalton wrote:
> > skb_page_frag_refill currently permits only order-0 page allocs
> > unless GFP_WAIT is used. Change skb_page_frag_refill to attempt
> > higher-order page allocations whether or not GFP_WAIT is used. If
> > memory cannot be allocated, the allocator will fall back to
> > successively smaller page allocs (down to order-0 page allocs).
> >
> > This change brings skb_page_frag_refill in line with the existing
> > page allocation strategy employed by netdev_alloc_frag, which attempts
> > higher-order page allocations whether or not GFP_WAIT is set, falling
> > back to successively lower-order page allocations on failure. Part
> > of migration of virtio-net to per-receive queue page frag allocators.
> >
> > Signed-off-by: Michael Dalton <mwdalton@...gle.com>
> > ---
> >  net/core/sock.c | 4 +---
> >  1 file changed, 1 insertion(+), 3 deletions(-)
> >
> > diff --git a/net/core/sock.c b/net/core/sock.c
> > index ab20ed9..7383d23 100644
> > --- a/net/core/sock.c
> > +++ b/net/core/sock.c
> > @@ -1865,9 +1865,7 @@ bool skb_page_frag_refill(unsigned int sz, struct page_frag *pfrag, gfp_t prio)
> >  		put_page(pfrag->page);
> >  	}
> >  
> > -	/* We restrict high order allocations to users that can afford to wait */
> > -	order = (prio & __GFP_WAIT) ? SKB_FRAG_PAGE_ORDER : 0;
> > -
> > +	order = SKB_FRAG_PAGE_ORDER;
> >  	do {
> >  		gfp_t gfp = prio;
> >  
> 
> The original code seems try to avoid the high order allocation for
> atomic allocation. This patch changes this, and looks like it will
> introduce some extra cost when the memory is highly fragmented.

No noticeable extra cost that I could measure.

We use the same strategy in RX path nowadays.

Acked-by: Eric Dumazet <edumazet@...gle.com>



--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html