On Fri, Sep 08, 2000 at 12:32:52PM -0400, Dennis wrote: > At 09:28 AM 09/08/2000 +0100, you wrote: > >> >The mark_bh is already there. it sounds ot me like you are changing timing > >> >patterns by causing a cpu stall on the memory bus > >> > >> No, its not. > > > >The mark_bh is already there. Its in netif_rx. You are causing additional > delays > >by causing a stall on the memory bus with the mark_bh. > > > >> 1) Set up a box with an eepro100 as a second card and modify the driver by > >> simply replacing netif_rx() with kfree_skb(). My system is a 200Mhz Pentium > > > >You've changed the timing patterns. > > any code change changes the timing. The existing code chokes. So your > solution is that there is no solution? There is probably a solution, just not by adding bogus mark_bh()s to the driver. When you set speedo_debug to 3 does it complain about memory allocation failures ? Does it still occur when you increase the values in /proc/sys/vm/freepages (e.g. quadruple all of them) > > 4000 pps is nothing. But its my fault for trying to make a horse out of a > camel. Shame on me. Alexey told you earlier that the default VM settings do not cope with too high network load. You didn't listen.. -Andi - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org
