netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Arnaldo Carvalho de Melo <acme@conectiva.com.br>
To: jt@hpl.hp.com
Cc: "David S. Miller" <davem@davemloft.net>,
	irda-users@lists.sourceforge.net, netdev@oss.sgi.com,
	Stephen Hemminger <shemminger@osdl.org>
Subject: Re: [PATCH 6/9] irda: use sock slab cache
Date: Thu, 20 Jan 2005 01:47:10 -0200	[thread overview]
Message-ID: <41EF29BE.2020807@conectiva.com.br> (raw)
In-Reply-To: <20050120021607.GA11216@bougret.hpl.hp.com>

Jean Tourrilhes escreveu:
> 	I'm just curious about the overhead of adding a specific slab
> for IrDA sockets. Most users never create any (using IrCOMM), or
> maximum one (using Obex), so it's not like it will get a lot of use
> (except here, of course).

Well, lets start with something that may sound funny: when this series
of patches is finished the overhead will _decrease_ for most people.

Why? Today we have in most machines five slab caches of this nature:
udp_sock, raw_sock, tcp_sock, unix_sock (PF_LOCAL) and the generic,
sock, that only is used by the protocols that are using kmalloc(pritave_sock) +
sk_protinfo.

When all protos use private slab caches, the generic slab "sock" is no longer
needed.

So most users will have only the udp, raw, tcp and unix slabs, if they require
another family, say AF_IRDA, they are back to the previous situation, with
5 sock slabs, only when users need two or more extra slabs we get some
overhead wrt the previous situation, but this is compensated by likely
performance gains associated with less cacheline trashing, as noticed when
I first introduced sock slabs, with all the protos converted at that time, i.e.
the 4 most common mentioned above.

And not having two ways to allocate the private area for protos reduces
the networking infrastructure complexity and makes all the networking families
look more similar in its implementation, which facilitates indentifying common
code patterns that can be made generic.

All of this is part of an effort I've been working on for a long time, with the
ultimate goals of reducing the costs associated with maintaining the support
for legacy protocols, taking advantage of the work done on the mainstream
protocols and easing the implementation of new network protocols, such as
DCCP, which I'm working on.

Regards,

- Arnaldo

  reply	other threads:[~2005-01-20  3:47 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-01-20  2:04 [PATCH 6/9] irda: use sock slab cache Arnaldo Carvalho de Melo
2005-01-20  2:16 ` Jean Tourrilhes
2005-01-20  3:47   ` Arnaldo Carvalho de Melo [this message]
2005-01-20  8:54     ` Christoph Hellwig
2005-01-20 14:55       ` Arnaldo Carvalho de Melo
2005-01-20 15:20         ` Arnaldo Carvalho de Melo
2005-01-20 17:25           ` Jean Tourrilhes
2005-01-20 21:08             ` Arnaldo Carvalho de Melo

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=41EF29BE.2020807@conectiva.com.br \
    --to=acme@conectiva.com.br \
    --cc=davem@davemloft.net \
    --cc=irda-users@lists.sourceforge.net \
    --cc=jt@hpl.hp.com \
    --cc=netdev@oss.sgi.com \
    --cc=shemminger@osdl.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).