linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Felix Fietkau <nbd@openwrt.org>
To: Helmut Schaa <helmut.schaa@googlemail.com>
Cc: Johannes Berg <johannes@sipsolutions.net>,
	linux-wireless@vger.kernel.org, linville@tuxdriver.com
Subject: Re: [PATCH 3/3] mac80211: optimize aggregation session timeout handling
Date: Mon, 19 Mar 2012 11:36:06 +0100	[thread overview]
Message-ID: <4F670C16.9030009@openwrt.org> (raw)
In-Reply-To: <CAGXE3d8P1r+DRv4UKbzSMXaf4fRB4cXAyz8+a1pf3RsfeAKOvQ@mail.gmail.com>

On 2012-03-19 10:29 AM, Helmut Schaa wrote:
> Hi,
> 
> On Mon, Mar 19, 2012 at 9:39 AM, Johannes Berg
> <johannes@sipsolutions.net> 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

  parent reply	other threads:[~2012-03-19 10:36 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-17 23:00 [PATCH 1/3] cfg80211: use compare_ether_addr on MAC addresses instead of memcmp Felix Fietkau
2012-03-17 23:00 ` [PATCH 2/3] mac80211: reduce code duplication in debugfs code Felix Fietkau
2012-03-17 23:00   ` [PATCH 3/3] mac80211: optimize aggregation session timeout handling Felix Fietkau
2012-03-18 10:17     ` Johannes Berg
2012-03-18 11:13       ` Felix Fietkau
2012-03-19  8:39         ` Johannes Berg
2012-03-19  9:29           ` Helmut Schaa
2012-03-19  9:39             ` Johannes Berg
2012-03-19 10:36             ` Felix Fietkau [this message]
2012-03-19 10:50               ` Helmut Schaa
2012-03-19 10:52                 ` Felix Fietkau
2012-03-19 10:55                   ` Helmut Schaa
2012-03-19 10:58                     ` Felix Fietkau
2012-03-19 10:01           ` Felix Fietkau
2012-03-19 10:05             ` Johannes Berg
2012-03-19 10:34               ` Felix Fietkau

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F670C16.9030009@openwrt.org \
    --to=nbd@openwrt.org \
    --cc=helmut.schaa@googlemail.com \
    --cc=johannes@sipsolutions.net \
    --cc=linux-wireless@vger.kernel.org \
    --cc=linville@tuxdriver.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).