> > (strange thing is that ethernet irq's reported by procinfo are > > decreasing when the machine is overloaded. It suppose that it > > means either that irq's are not even caught by the kernel/driver, > > which is quite worrying, or either that irq's counters refer to > > 'processessed' interrupts) > > are you using a driver which uses the irq mitigation interface of 2.4.x > or the NAPI of 2.5.x ?
no. (is it available for non Gigabit ethernets?). I'm using 3c905-TX. one explanation could be that, SYN packets are 'lost'/not processed, and there are thus no additional SYN/ACK,ACK (at least), and thus no extra flow (each connection was made of about 10 packets). Since packets don't get forwarded, the same applies for the other interface. It means also that most retransmissions get lost. > > > Harld: could you ask to your kernel specialist what is the weakpoint of > > kmem_cache_alloc()? (locks, allocs, ...), and how we could possibly > > improve it (batch alloc, but isn't it already the case?) > > I don't think that the slab allocator is the bottleneck. please show me > profiling data pointing this out. > yesss, facts... but in the mean time, grabbing info/experience/feelings from 'non involved' people could be instructive. what do they say? > - Harald Welte kr, -jmhe-
