All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexander Duyck <alexander.duyck@gmail.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Alexander Duyck <alexander.h.duyck@intel.com>,
	netdev@vger.kernel.org, davem@davemloft.net,
	jeffrey.t.kirsher@intel.com
Subject: Re: [PATCH] net: Update netdev_alloc_frag to work more efficiently with TCP and GRO
Date: Wed, 20 Jun 2012 21:07:00 -0700	[thread overview]
Message-ID: <4FE29DE4.1010705@gmail.com> (raw)
In-Reply-To: <1340198514.4604.970.camel@edumazet-glaptop>

On 6/20/2012 6:21 AM, Eric Dumazet wrote:
> On Wed, 2012-06-20 at 10:17 +0200, Eric Dumazet wrote:
>
>> Strange, I did again benchs with order-2 allocations and got good
>> results this time, but with latest net-next, maybe things have changed
>> since last time I did this.
>>
>> (netdev_alloc_frag(), get_page_from_freelist() and put_page() less
>> prevalent in perf results)
>>
> In fact, since SLUB uses order-3 for kmalloc-2048, I felt lucky to try
> this as well, and results are really good, on ixgbe at least.
>
> diff --git a/net/core/skbuff.c b/net/core/skbuff.c
> index 5b21522..ffd2cba 100644
> --- a/net/core/skbuff.c
> +++ b/net/core/skbuff.c
> @@ -299,6 +299,9 @@ struct netdev_alloc_cache {
>   };
>   static DEFINE_PER_CPU(struct netdev_alloc_cache, netdev_alloc_cache);
>
> +#define MAX_NETDEV_FRAGSIZE	max_t(unsigned int, PAGE_SIZE, 32768)
> +#define NETDEV_FRAG_ORDER	get_order(MAX_NETDEV_FRAGSIZE)
> +
>   /**
>    * netdev_alloc_frag - allocate a page fragment
>    * @fragsz: fragment size
> @@ -316,11 +319,13 @@ void *netdev_alloc_frag(unsigned int fragsz)
>   	nc =&__get_cpu_var(netdev_alloc_cache);
>   	if (unlikely(!nc->page)) {
>   refill:
> -		nc->page = alloc_page(GFP_ATOMIC | __GFP_COLD);
> +		nc->page = alloc_pages(GFP_ATOMIC | __GFP_COLD |
> +				       (NETDEV_FRAG_ORDER ? __GFP_COMP : 0),
> +				       NETDEV_FRAG_ORDER);
>   		nc->offset = 0;
>   	}
I was wondering if you needed the check for NETDEV_FRAG_ORDER here.  
 From what I can tell setting __GFP_COMP for an order 0 page has no 
effect since it only seems to get checked in prep_new_page and that is 
after a check to verify if the page is order 0 or not.

Thanks,

Alex

  reply	other threads:[~2012-06-21  4:07 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-20  0:43 [PATCH] net: Update netdev_alloc_frag to work more efficiently with TCP and GRO Alexander Duyck
2012-06-20  1:49 ` Alexander Duyck
2012-06-20  5:36 ` Eric Dumazet
2012-06-20  8:17   ` Eric Dumazet
2012-06-20  8:44     ` Eric Dumazet
2012-06-20  9:04       ` David Miller
2012-06-20  9:14         ` Eric Dumazet
2012-06-20 13:21     ` Eric Dumazet
2012-06-21  4:07       ` Alexander Duyck [this message]
2012-06-21  5:07         ` Eric Dumazet
2012-06-22 12:33           ` Eric Dumazet
2012-06-23  0:17             ` Alexander Duyck
2012-06-29 23:04             ` Alexander Duyck
2012-06-30  8:39               ` Eric Dumazet
2012-06-21  5:56     ` David Miller
2012-06-20 16:30   ` Alexander Duyck
2012-06-20 17:14     ` Alexander Duyck
2012-06-20 18:41       ` Eric Dumazet
2012-06-20 20:10         ` Alexander Duyck

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=4FE29DE4.1010705@gmail.com \
    --to=alexander.duyck@gmail.com \
    --cc=alexander.h.duyck@intel.com \
    --cc=davem@davemloft.net \
    --cc=eric.dumazet@gmail.com \
    --cc=jeffrey.t.kirsher@intel.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.