netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Miller <davem@davemloft.net>
To: andy.grover@gmail.com
Cc: netdev@vger.kernel.org
Subject: Re: how expensive are mallocs?
Date: Wed, 25 Nov 2009 15:18:46 -0800 (PST)	[thread overview]
Message-ID: <20091125.151846.106903149.davem@davemloft.net> (raw)
In-Reply-To: <c0a09e5c0911240957x45abfb26k1611e53f435e5179@mail.gmail.com>

From: Andrew Grover <andy.grover@gmail.com>
Date: Tue, 24 Nov 2009 09:57:34 -0800

> How much effort generally makes sense to avoid mallocs? For example,
> rds has a function that does a kmalloc for an array of scatterlist
> entries, which is freed at the bottom of the function. We couldn't
> allocate off the stack in all cases (too big), but we could allocate
> an array of say 8 scatterlists, and use it if that's big enough,
> falling back to kmalloc if it's not.
> 
> Is this a good idea?

This is a poor idea, especially if this function executes frequently.

Better to have a per-socket or per-cpu (softirq protected, if
necessary) work area to do such things if you really can't fit it on
the stack.

> Also, RDS has its own per-cpu page remainder allocator (see
> net/rds/page.c) for kernel send buffers. Would cutting this code and
> just using kmalloc be recommended? Doesn't SL?B already do per-cpu
> pools?
> 
> Does this stuff even matter enough to rise above the noise in benchmarks?

We already have a per-socket page allocation scheme for sendmsg handling.

In general adding more and more specialized allocators is heavily
discouraged.  If the generic kernel facilities don't fit the bill,
fix them.


  reply	other threads:[~2009-11-25 23:18 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-24 17:57 how expensive are mallocs? Andrew Grover
2009-11-25 23:18 ` David Miller [this message]
2009-11-26 22:25 ` Andi Kleen

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=20091125.151846.106903149.davem@davemloft.net \
    --to=davem@davemloft.net \
    --cc=andy.grover@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).