Return-path: Received: from mail-pz0-f46.google.com ([209.85.210.46]:53185 "EHLO mail-pz0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S964983Ab2CSKzR (ORCPT ); Mon, 19 Mar 2012 06:55:17 -0400 Received: by dajr28 with SMTP id r28so9759397daj.19 for ; Mon, 19 Mar 2012 03:55:17 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <4F671009.6070602@openwrt.org> References: <1332025254-5048-1-git-send-email-nbd@openwrt.org> <1332025254-5048-2-git-send-email-nbd@openwrt.org> <1332025254-5048-3-git-send-email-nbd@openwrt.org> <1332065875.3609.3.camel@jlt3.sipsolutions.net> <4F65C374.2060505@openwrt.org> <1332146368.3359.12.camel@jlt3.sipsolutions.net> <4F670C16.9030009@openwrt.org> <4F671009.6070602@openwrt.org> Date: Mon, 19 Mar 2012 11:55:17 +0100 Message-ID: (sfid-20120319_115523_053634_90FD57C1) Subject: Re: [PATCH 3/3] mac80211: optimize aggregation session timeout handling From: Helmut Schaa To: Felix Fietkau Cc: Johannes Berg , linux-wireless@vger.kernel.org, linville@tuxdriver.com Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-wireless-owner@vger.kernel.org List-ID: On Mon, Mar 19, 2012 at 11:52 AM, Felix Fietkau wrote: > On 2012-03-19 11:50 AM, Helmut Schaa wrote: >> On Mon, Mar 19, 2012 at 11:36 AM, Felix Fietkau wrote: >>> On 2012-03-19 10:29 AM, Helmut Schaa wrote: >>>> Hi, >>>> >>>> On Mon, Mar 19, 2012 at 9:39 AM, Johannes Berg >>>> 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. What about just using mod_timer_pinned, that doesn't apply any slack. However, this is mainly intended for not moving the timer to a different CPU. Helmut