From: "Chris Leech" <chris.leech@gmail.com>
To: "Evgeniy Polyakov" <johnpol@2ka.mipt.ru>
Cc: "Herbert Xu" <herbert@gondor.apana.org.au>,
arnd@arndnet.de, olel@ans.pl, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org
Subject: Re: problems with e1000 and jumboframes
Date: Fri, 4 Aug 2006 08:34:46 -0700 [thread overview]
Message-ID: <41b516cb0608040834o1d433f23v2f2ba1a1b05ccbc6@mail.gmail.com> (raw)
In-Reply-To: <20060804061513.GB413@2ka.mipt.ru>
On 8/3/06, Evgeniy Polyakov <johnpol@2ka.mipt.ru> wrote:
> On Fri, Aug 04, 2006 at 03:59:37PM +1000, Herbert Xu (herbert@gondor.apana.org.au) wrote:
> > Interesting. Could you guys post figures on alloc_page speed vs. kmalloc?
>
> They probalby measured kmalloc cache access, which only falls to
> alloc_pages when cache is refilled, so it will be faster for some short
> period of time, but in general (especially for such big-sized
> allocations) it is essencially the same.
I think you're right about that. In particular, I think Jesse was
looking at the impact that changing the drivers buffer allocation
method would have on 1500 byte MTU users. With a running network
driver you should see lots of fixed size allocations hitting the slab
cache, and occasionally causing an alloc_pages. If you replace that
with a call to alloc_pages for every packet that ever gets received
it's a performance hit.
So how many skb allocation schemes do you code into a single driver?
Kmalloc everything, page alloc everything, combination of kmalloc and
page buffers for hardware that does header split? That's three
versions of the drivers receive processing and skb allocation that
need to be maintained.
> > Also, getting memory slower is better than not getting them at all :)
Yep.
- Chris
next prev parent reply other threads:[~2006-08-04 15:34 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-03 13:48 Arnd Hannemann
2006-08-03 13:59 ` Evgeniy Polyakov
2006-08-03 14:37 ` Arnd Hannemann
2006-08-03 15:03 ` Evgeniy Polyakov
2006-08-03 15:08 ` Krzysztof Oledzki
2006-08-03 15:16 ` Evgeniy Polyakov
2006-08-03 15:37 ` Arnd Hannemann
2006-08-03 15:43 ` Evgeniy Polyakov
2006-08-03 15:41 ` Evgeniy Polyakov
2006-08-03 18:09 ` Arnd Hannemann
2006-08-03 18:29 ` Evgeniy Polyakov
2006-08-03 21:40 ` Arnd Hannemann
2006-08-03 15:57 ` Chris Leech
2006-08-03 16:10 ` Evgeniy Polyakov
2006-08-03 20:32 ` Chris Leech
2006-08-04 6:20 ` Evgeniy Polyakov
2006-08-04 15:16 ` Chris Leech
2006-08-03 16:24 ` Arnd Hannemann
2006-08-03 20:34 ` Chris Leech
2006-08-04 5:59 ` Herbert Xu
2006-08-04 6:15 ` Evgeniy Polyakov
2006-08-04 15:34 ` Chris Leech [this message]
2006-08-04 19:42 ` Evgeniy Polyakov
2006-08-04 21:02 ` Jesse Brandeburg
2006-08-05 9:58 ` Evgeniy Polyakov
2006-08-05 10:09 ` Herbert Xu
2006-08-05 10:24 ` Evgeniy Polyakov
2006-08-05 10:33 ` Herbert Xu
2006-08-05 10:41 ` Evgeniy Polyakov
2006-08-03 15:23 ` Evgeniy Polyakov
2006-08-04 5:52 ` Herbert Xu
2006-08-04 5:55 ` David Miller
2006-08-04 5:58 ` Evgeniy Polyakov
2006-08-03 14:24 ` Benjamin LaHaise
2006-08-03 14:49 ` Krzysztof Oledzki
2006-08-03 14:52 ` Benjamin LaHaise
2006-08-03 15:04 ` Krzysztof Oledzki
2006-08-03 15:32 ` Arnd Hannemann
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=41b516cb0608040834o1d433f23v2f2ba1a1b05ccbc6@mail.gmail.com \
--to=chris.leech@gmail.com \
--cc=arnd@arndnet.de \
--cc=herbert@gondor.apana.org.au \
--cc=johnpol@2ka.mipt.ru \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=olel@ans.pl \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®