Messages in this thread | | | Date | Sun, 27 Feb 2011 17:01:27 +0100 | Subject | Re: ANNOUNCE: debloat-testing kernel git tree | From | Sedat Dilek <> |
| |
On Sun, Feb 27, 2011 at 4:56 PM, Dave Täht <d@taht.net> wrote: > Sedat Dilek <sedat.dilek@googlemail.com> writes: > >> On Sun, Feb 27, 2011 at 4:31 PM, Dave Täht <d@taht.net> wrote: >>> >>> Sedat Dilek <sedat.dilek@googlemail.com> writes: >>> >>>> On Fri, Feb 25, 2011 at 11:22 PM, John W. Linville >>>> <linville@tuxdriver.com> wrote: >>>>> 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---- > >>> 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 >
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-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |