[Make-wifi-fast] [PATCH RFC v4 3/4] mac80211: Add airtime accounting and scheduling to TXQs
Rajkumar Manoharan
rmanohar at codeaurora.org
Wed Sep 26 20:09:07 EDT 2018
On 2018-09-26 02:22, Toke Høiland-Jørgensen wrote:
> Rajkumar Manoharan <rmanohar at codeaurora.org> writes:
>
>> On 2018-09-16 10:42, Toke Høiland-Jørgensen wrote:
>>> + if (ret) {
>>> + clear_bit(IEEE80211_TXQ_AIRTIME_THROTTLE, &txqi->flags);
>>> + list_del_init(&txqi->schedule_order);
>>> + } else
>>> + set_bit(IEEE80211_TXQ_AIRTIME_THROTTLE, &txqi->flags);
>>> +
>>>
>> This looks wrong to me. txqi->flags are protected by fq->lock but here
>> it is by active_txq_lock. no?
>
> Both set_bit() and clear_bit() are atomic operations, so they don't
> need
> separate locking. See Documentation/atomic_bitops.txt
>
:( Yeah... I got confused with attached soft lockup in ARM platform.
>>> @@ -3677,6 +3751,7 @@ void ieee80211_txq_schedule_end(struct
>>> ieee80211_hw *hw, u8 ac)
>>> struct ieee80211_local *local = hw_to_local(hw);
>>>
>>> spin_unlock_bh(&local->active_txq_lock[ac]);
>>> + tasklet_schedule(&local->wake_txqs_tasklet);
>>> }
>>>
>> It is an overload to schedule wake_txqs_tasklet for each txq unlock.
>> Instead I would prefer to call __ieee80211_kick_airtime from
>> schedule_end.
>> Thoughts?
>
> Yeah, I realise scheduling the whole wake_txqs_tasklet is maybe a bit
> heavy-handed here. However just calling into __ieee80211_kick_airtime()
> means we'll end up recursing back to the same place, which is not good
> either (we could in theory flip-flop between two queues until we run
> out
> of stack space).
>
IMHO schedule_start/end is needed for tracking first node to break the
loop.
It is not applicable when the driver calls may_transmit(). It would be
better
if active_txq_lock is moved within may_transmit.
> My "backup plan" if the wake_txqs_tasklet turns out to be too heavy was
> to define a new tasklet just for this use; but wanted to see if this
> actually turned out to be a problem first...
>
Instead of adding new tasklet, we can introduce new API to iterate
through
throttled txqs. Driver that make use of may_transmit, have to call this
new API
at the end of irq handler i.e after processing tx/rx.
-Rajkumar
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: crash.txt
URL: <https://lists.bufferbloat.net/pipermail/make-wifi-fast/attachments/20180926/e2441385/attachment.txt>
More information about the Make-wifi-fast
mailing list