Sedat Dilek [off-list ref] writes:
On Sun, Feb 27, 2011 at 4:31 PM, Dave Täht [off-list ref] wrote:
quoted
Sedat Dilek [off-list ref] writes:
quoted
On Fri, Feb 25, 2011 at 11:22 PM, John W. Linville
[off-list ref] wrote:
quoted
Announcement
The bufferbloat project [1] is pleased to announce the availability
of the debloat-testing Linux kernel git tree:
git://git.infradead.org/debloat-testing.git
----snip----
quoted
Excellent. At moment I would recommend building "low latency preempt
desktop" kernels with a high HZ value (400 or 1000), enabling highres
timers, and compiling in SFB as a module. (I'd like the default for SFB
to be "m" rather than "n", too)
These "debloat guys" are fast :-). I was just preparing my
build-system (which I normally use to debianize linux-next kernels).
Any other recommendation for kernel-config options? For example:
linux-next has already CONFIG_NET_SCH_CHOKE (but I have unset it).
Enable CHOKe.
The HZ value change is due to my worry that we've smashed latency so
much in the driver/mac layer that it's interacting with the higher
layers somewhat badly... So we need to add more hooks to the servo loops
involved in order to have a normal HZ.
Which commits are in debloat-testing GIT but not in linux-next tree?
The current list was in the release announcement. More on the way
(mostly embedded drivers at this point) git pull early and often!
Are you planning debloat feature for 2.6.39?
Depends on how many testers we get and what the results are.
I feel the eBDP stuff will not be ready during this release cycle. SFB
and CHOKe are in net-next, so, probably. Various driver patches -
particularly those that increase the available dynamic range via
ethtool, (e.g lowering the bottommost TX queue limit to, like, 4,
especially for home gateways) may make it out if people look harder into
the issue.
- Sedat -
--
Dave Taht
http://nex-6.taht.net
On Sun, Feb 27, 2011 at 4:56 PM, Dave Täht [off-list ref] wrote:
Sedat Dilek [off-list ref] writes:
quoted
On Sun, Feb 27, 2011 at 4:31 PM, Dave Täht [off-list ref] wrote:
quoted
Sedat Dilek [off-list ref] writes:
quoted
On Fri, Feb 25, 2011 at 11:22 PM, John W. Linville
[off-list ref] wrote:
quoted
Announcement
The bufferbloat project [1] is pleased to announce the availability
of the debloat-testing Linux kernel git tree:
git://git.infradead.org/debloat-testing.git
----snip----
quoted
quoted
Excellent. At moment I would recommend building "low latency preempt
desktop" kernels with a high HZ value (400 or 1000), enabling highres
timers, and compiling in SFB as a module. (I'd like the default for SFB
to be "m" rather than "n", too)
quoted
These "debloat guys" are fast :-). I was just preparing my
build-system (which I normally use to debianize linux-next kernels).
Any other recommendation for kernel-config options? For example:
linux-next has already CONFIG_NET_SCH_CHOKE (but I have unset it).
Enable CHOKe.
The HZ value change is due to my worry that we've smashed latency so
much in the driver/mac layer that it's interacting with the higher
layers somewhat badly... So we need to add more hooks to the servo loops
involved in order to have a normal HZ.
quoted
Which commits are in debloat-testing GIT but not in linux-next tree?
The current list was in the release announcement. More on the way
(mostly embedded drivers at this point) git pull early and often!
quoted
Are you planning debloat feature for 2.6.39?
Depends on how many testers we get and what the results are.
I feel the eBDP stuff will not be ready during this release cycle. SFB
and CHOKe are in net-next, so, probably. Various driver patches -
particularly those that increase the available dynamic range via
ethtool, (e.g lowering the bottommost TX queue limit to, like, 4,
especially for home gateways) may make it out if people look harder into
the issue.
quoted
- Sedat -
--
Dave Taht
http://nex-6.taht.net
OK, thanks for the explanations.
Concerning "more drivers":
What would I have to do to modify ath5k?
I looked into the ath9k patch in debloat-testing GIT and it was to mod
some (TX/BUF) values only.
Not sure if ath9k is/was "well" prepared or only a good choice by the
testers/committers as they own such a device.
- Sedat -
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html