On Sun, 2012-03-18 at 12:13 +0100, Felix Fietkau wrote:
> On 2012-03-18 11:17 AM, Johannes Berg wrote:
> > On Sun, 2012-03-18 at 00:00 +0100, Felix Fietkau wrote:
> >> Calling mod_timer from the rx/tx hotpath is somewhat expensive, and the
> >> timeout doesn't need to be so precise.
> >>
> >> Switch to a different strategy: Schedule the timer initially, store jiffies
> >> of all last rx/tx activity which would previously modify the timer, and
> >> let the timer re-arm itself after checking the last rx/tx timestamp.
> >
> > I don't like this. It's not the optimisation you think it is on other
> > ("embedded") systems where firing a timer is more expensive.
> >
> > You're trading power consumption against CPU utilisation by causing the
> > timer to wake up.
> I considered that was well, but didn't think one wakeup every 5 seconds
> or so would be significant. Would you take the patch if I change the
> timer to be deferrable, so that it doesn't cause wakeups by itself?
I'm not really convinced, for making them deferrable we should analyse
the consequences of that more carefully, for example it seems possible
that the system wakes up to send a packet, and then the first thing that
happens is a few aggregation handshakes ... that wastes a lot of time
and power.
Also, at least for TX aggregation, you don't even give them a timeout in
ath9k so that wouldn't really be an issue?
johannes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
