netdev
[Top] [All Lists]

Re: Set truesize in pskb_expand_head

To: "David S. Miller" <davem@xxxxxxxxxxxxx>
Subject: Re: Set truesize in pskb_expand_head
From: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
Date: Sat, 25 Sep 2004 10:05:03 +1000
Cc: netdev@xxxxxxxxxxx
In-reply-to: <20040924164540.2d750572.davem@davemloft.net>
References: <20040924232053.GA7807@gondor.apana.org.au> <20040924163328.7597352c.davem@davemloft.net> <20040924233555.GA7962@gondor.apana.org.au> <20040924233713.GA8001@gondor.apana.org.au> <20040924164540.2d750572.davem@davemloft.net>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: Mutt/1.5.6+20040722i
On Fri, Sep 24, 2004 at 04:45:40PM -0700, David S. Miller wrote:
> 
> I still am hesitant about your idea.

Alright let's talk more about it :)

> You're willing to do a very likely re-alloc every transaction
> where as I'm suggesting a single allocation for the socket at
> creation time which is used for every transaction on that
> socket.

Yes.  However, what we really care about is not how many
reallocations there are, but how likely are they going to fail.

In your scheme, every netlink socket gets a page regardless
of whether it's going to be used (think of a socket for
multicast reception only).  That means at the point just
before the realloc, your scheme would have allocated at least
as much memory as my method, if not more.  Therefore I'd
argue that the realloc is more likely to fail for you.

Let's also consider what happens when it does fail.  In your
scheme you've got to drop the packet.  In mine, you just continue
as we do now.
 
> your scheme:
> 
>    Allocate full PAGE_SIZE SKB for each netlink transaction,
>    reallocate data area at end of building each transaction.

That's not quite true.  Some users (e.g., tcp_diag) can and do
accurately estimate the final message size.  They do not require
a realloc/copy at all.

> So, two data area kmalloc()'s per netlink response compared
> to one for mine.

Now I admit that is one weakness in my scheme.  However, I'd
argue that the performance cost of doing one extra kmalloc is
lost when compared to the rest of the work in filling up the
skb and copying it, no?

> Your scheme doesn't even avoid the copy.  What's the advantage?

Actually, it does avoid the copy for all dumped packets except the
final one as well as those packets that are near the right size already.

> Furthermore my per-socket PAGE_SIZE scratch area is likely to
> get very good cache hit rates making the copy very inexpensive.

True.  But surely it is better to not copy at all where possible?

Here is the real patch.

Signed-off-by: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@xxxxxxxxxxxxxxxxxxx>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Attachment: p
Description: Text document

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