[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <52B7EBB9.6050405@redhat.com>
Date: Mon, 23 Dec 2013 15:52:25 +0800
From: Jason Wang <jasowang@...hat.com>
To: Michael Dalton <mwdalton@...gle.com>,
"David S. Miller" <davem@...emloft.net>
CC: 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 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.
--
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
Powered by blists - more mailing lists