On 2012-03-19 10:29 AM, Helmut Schaa wrote:
> Hi,
>
> On Mon, Mar 19, 2012 at 9:39 AM, Johannes Berg
> <johannes@xxxxxxxxxxxxxxxx> wrote:
>> 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.
>
> I like the idea of getting rid of the mod_timer overhead. Looking at the timer
> code, if the timer value is unchanged mod_timer is not that expensive.
>
> So, instead of calling mod_timer for every successive frame with a slightly
> different timeout we could just use round_jiffies to round the timeout to the
> next full second. This would in most cases take the quick path through
> mod_timer and only update the timer once every second.
>
> See code (untested, not even compile tested) below.
I would still like to avoid the overhead of apply_slack(), which is
called early by mod_timer(). It was visible in both CPU cycles and
icache misses when I did some profiling under high tx load.
- Felix
--
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
