On 2012-03-19 11:50 AM, Helmut Schaa wrote:
> On Mon, Mar 19, 2012 at 11:36 AM, Felix Fietkau <nbd@xxxxxxxxxxx> wrote:
>> 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.
>
> Indeed, however, I don't know the timer code at all. Seems like the default
> slack for a timer is 0.4%. Setting the slack to 0 with set_timer_slack
> should allow a shorter path through apply_slack. Not sure if that's sufficient
> already.
Looking at the code, it appears that this would not be sufficient.
- 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
