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
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to majordomo@vger.kernel.org
This archive was generated by hypermail 2b29 : Fri Sep 15 2000 - 21:00:29 EST