On Thu, 6 Dec 2007, Lachlan Andrew wrote: > On 04/12/2007, Ilpo Järvinen <[EMAIL PROTECTED]> wrote: > > On Mon, 3 Dec 2007, Lachlan Andrew wrote: > > > > > > When SACK is active, the per-packet processing becomes more involved, > > > tracking the list of lost/SACKed packets. This causes a CPU spike > > > just after a loss, which increases the RTTs, at least in my > > > experience. > > > > I suspect that as long as old code was able to use hint, it wasn't doing > > that bad. But it was seriously lacking ability to take advantage of sack > > processing hint when e.g., a new hole appeared, or cumulative ACK arrived. > > > > ...Code available in net-2.6.25 might cure those. > > We had been using one of your earlier patches, and still had the > problem. I think you've cured the problem with SACK itself, but there > still seems to be something taking a lot of CPU while recovering from > the loss.
I guess if you get a large cumulative ACK, the amount of processing is still overwhelming (added DaveM if he has some idea how to combat it). Even a simple scenario (this isn't anything fancy at all, will occur all the time): Just one loss => rest skbs grow one by one into a single very large SACK block (and we do that efficiently for sure) => then the fast retransmit gets delivered and a cumulative ACK for whole orig_window arrives => clean_rtx_queue has to do a lot of processing. In this case we could optimize RB-tree cleanup away (by just blanking it all) but still getting rid of all those skbs is going to take a larger moment than I'd like to see. That tree blanking could be extended to cover anything which ACK more than half of the tree by just replacing the root (and dealing with potential recolorization of the root). > It is possible that it was to do with web100 which we > have also been running, but I cut out most of the statistics from that > and still had problems. No idea about what it could do, haven't yet looked web100, I was planning at some point of time... -- i.
