[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20080108.231618.133599422.davem@davemloft.net>
Date: Tue, 08 Jan 2008 23:16:18 -0800 (PST)
From: David Miller <davem@...emloft.net>
To: andi@...stfloor.org
Cc: jheffner@....edu, ilpo.jarvinen@...sinki.fi,
lachlan.andrew@...il.com, netdev@...r.kernel.org,
quetchen@...tech.edu
Subject: Re: SACK scoreboard
From: Andi Kleen <andi@...stfloor.org>
Date: Wed, 9 Jan 2008 08:03:18 +0100
> Also even freeing a lot of objects doesn't have to be
> that expensive. I suspect the most cost is in taking
> the slab locks, but that could be batched.
We're touching SKB struct members, doing atomics on them, etc. for
objects we haven't referenced for at least two RTTs so are guarenteed
to be cache cold.
Let's say best case we can get it down to 2 cache line misses, and as
a very aggressive goal we can get the cost down to 100 cycles. For
500,000 packets this is 500 million cpu cycles to free them all up.
That's 1/4 of a second even on a 2 GHZ cpu.
And yes there are inherent costs in handling TCP windows that are
500,000 packets in size. But, that freeing cost should be spread
throughout the handling of the RTT feedback, not handled all at once.
> Your hand waved numbers on inline sizes there were definitely worse
> than mine.
Your primary objective seems to be "being right", and that's fine but
realize that it makes discussing anything with you about as fun as
picking one's toe nails with an ice axe.
Eventually you will be ignored by most folks who get fed up by this
style of argument.
So, have fun being right rather than being pleasant to work with.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists