On Fri, 2005-03-06 at 12:01 -0700, David S. Miller wrote:
> From: jamal <hadi@xxxxxxxxxx>
> Date: Fri, 03 Jun 2005 14:42:30 -0400
>
> > When you reduce the weight, the system is spending less time in the
> > softirq processing packets before softirq yields. If this gives more
> > opportunity to your app to run, then the performance will go up.
> > Is this what you are seeing?
>
> Jamal, this is my current theory as well, we hit the jiffies
> check.
>
I think you are more than likely right. If we can instrument it Mitch
could check it out. Mitch would you like to try something that will
instrument this? I know i have seen this behavior but it was when i was
playing with some system that had a real small HZ.
> It it the only logical explanation I can come up with for the
> single adapter case.
>
> There are some ways we can mitigate this. Here is one idea
> off the top of my head.
>
> When the jiffies check is hit, lower the weight of the most recently
> polled device towards some minimum (perhaps divide by two). If we
> successfully poll without hitting the jiffies check, make a small
> increment of the weight up to some limit.
>
You probably wanna start high up first until you hit congestion
and then start lowering.
> It is Van Jacobson TCP congestion avoidance applied to NAPI :-)
>
> Just a simple AIMD (Additive Increase, Multiplicative Decrease).
> So, hitting the jiffies work limit is congestion, and the cause
> of the congestion is the most recently polled device.
>
> In this regime, what the driver currently specifies as "->weight"
> is actually the maximum we'll use in the congestion control
> algorithm. And we can choose some constant minimum, something
> like "8" ought to work well.
>
> Comments?
>
In theory it looks good - but i think you end up defeating the fairness
factor. If you can narrow it down to which driver is causing congestion,
and only penalize that driver i think it would work well.
cheers,
jamal
|