From: "Toke Høiland-Jørgensen" <toke@toke.dk>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: make-wifi-fast@lists.bufferbloat.net,
linux-wireless@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: [PATCH 3/3] mac80211: Set lower memory limit for non-VHT devices
Date: Fri, 30 Sep 2016 14:41:42 +0200 [thread overview]
Message-ID: <87twcx5zll.fsf@toke.dk> (raw)
In-Reply-To: <1475235230.17481.43.camel@sipsolutions.net> (Johannes Berg's message of "Fri, 30 Sep 2016 13:33:50 +0200")
Johannes Berg <johannes@sipsolutions.net> writes:
> On Fri, 2016-09-23 at 21:59 +0200, Toke H=C3=B8iland-J=C3=B8rgensen wrote:
>> Small devices can run out of memory from queueing too many packets.
>> If VHT is not supported by the PHY, having more than 4 MBytes of
>> total queue in the TXQ intermediate queues is not needed, and so we
>> can safely limit the memory usage in these cases and avoid OOM.
>
> I kinda see the logic here - we really don't need to queue as much if
> we can't possibly transmit it out quickly - but it seems to me we
> should also throw in some kind of limit that's relative to the amount
> of memory you have on the system?
Yes, ideally. That goes for FQ-CoDel as well, BTW. LEDE currently
carries a patch for that which just changes the hard-coded default to
another hard-coded default. Not sure how to get a good value to use,
though; and deciding on how large a fraction of memory to use for
packets starts smelling an awful lot like setting policy in the kernel,
doesn't it?
> I've applied these anyway though. I just don't like your assumption (b)
> much as the rationale for it.
Right, thanks. I'll come up with a better rationale next time ;)
-Toke
WARNING: multiple messages have this Message-ID (diff)
From: "Toke Høiland-Jørgensen" <toke@toke.dk>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: make-wifi-fast@lists.bufferbloat.net,
linux-wireless@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: [PATCH 3/3] mac80211: Set lower memory limit for non-VHT devices
Date: Fri, 30 Sep 2016 14:41:42 +0200 [thread overview]
Message-ID: <87twcx5zll.fsf@toke.dk> (raw)
In-Reply-To: <1475235230.17481.43.camel@sipsolutions.net> (Johannes Berg's message of "Fri, 30 Sep 2016 13:33:50 +0200")
Johannes Berg <johannes@sipsolutions.net> writes:
> On Fri, 2016-09-23 at 21:59 +0200, Toke Høiland-Jørgensen wrote:
>> Small devices can run out of memory from queueing too many packets.
>> If VHT is not supported by the PHY, having more than 4 MBytes of
>> total queue in the TXQ intermediate queues is not needed, and so we
>> can safely limit the memory usage in these cases and avoid OOM.
>
> I kinda see the logic here - we really don't need to queue as much if
> we can't possibly transmit it out quickly - but it seems to me we
> should also throw in some kind of limit that's relative to the amount
> of memory you have on the system?
Yes, ideally. That goes for FQ-CoDel as well, BTW. LEDE currently
carries a patch for that which just changes the hard-coded default to
another hard-coded default. Not sure how to get a good value to use,
though; and deciding on how large a fraction of memory to use for
packets starts smelling an awful lot like setting policy in the kernel,
doesn't it?
> I've applied these anyway though. I just don't like your assumption (b)
> much as the rationale for it.
Right, thanks. I'll come up with a better rationale next time ;)
-Toke
next prev parent reply other threads:[~2016-09-30 12:41 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-23 19:59 [PATCH 0/3] Add memory limits to fq.h and mac80211 TXQ Toke Høiland-Jørgensen
2016-09-23 19:59 ` Toke Høiland-Jørgensen
2016-09-23 19:59 ` [PATCH 1/3] fq.h: Port memory limit mechanism from fq_codel Toke Høiland-Jørgensen
2016-09-23 19:59 ` Toke Høiland-Jørgensen
2016-09-23 19:59 ` [PATCH 2/3] mac80211: Export fq memory limit information in debugfs Toke Høiland-Jørgensen
2016-09-23 19:59 ` Toke Høiland-Jørgensen
2016-09-23 19:59 ` [PATCH 3/3] mac80211: Set lower memory limit for non-VHT devices Toke Høiland-Jørgensen
2016-09-23 19:59 ` Toke Høiland-Jørgensen
2016-09-30 11:33 ` Johannes Berg
2016-09-30 12:41 ` Toke Høiland-Jørgensen [this message]
2016-09-30 12:41 ` Toke Høiland-Jørgensen
2016-09-30 12:51 ` Johannes Berg
2016-09-30 14:35 ` Toke Høiland-Jørgensen
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=87twcx5zll.fsf@toke.dk \
--to=toke@toke.dk \
--cc=johannes@sipsolutions.net \
--cc=linux-wireless@vger.kernel.org \
--cc=make-wifi-fast@lists.bufferbloat.net \
--cc=netdev@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.