netdev
[Top] [All Lists]

Re: [PATCH 6/9] irda: use sock slab cache

To: jt@xxxxxxxxxx
Subject: Re: [PATCH 6/9] irda: use sock slab cache
From: Arnaldo Carvalho de Melo <acme@xxxxxxxxxxxxxxxx>
Date: Thu, 20 Jan 2005 01:47:10 -0200
Cc: "David S. Miller" <davem@xxxxxxxxxxxxx>, irda-users@xxxxxxxxxxxxxxxxxxxxx, netdev@xxxxxxxxxxx, Stephen Hemminger <shemminger@xxxxxxxx>
In-reply-to: <20050120021607.GA11216@xxxxxxxxxxxxxxxxxx>
Organization: Conectiva S.A.
References: <41EF11AF.70203@xxxxxxxxxxxxxxxx> <20050120021607.GA11216@xxxxxxxxxxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: Mozilla Thunderbird 1.0 (X11/20041220)
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

<Prev in Thread] Current Thread [Next in Thread>