Historic archive of defunct list bloat-devel@lists.bufferbloat.net
 help / color / mirror / Atom feed
From: d@taht.net (Dave Täht)
To: sedat.dilek@gmail.com
Cc: linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
	bloat-devel@lists.bufferbloat.net, linux-kernel@vger.kernel.org
Subject: Re: ANNOUNCE: debloat-testing kernel git tree
Date: Sun, 27 Feb 2011 08:56:48 -0700	[thread overview]
Message-ID: <8739n9ii7z.fsf@cruithne.co.teklibre.org> (raw)
In-Reply-To: <AANLkTinpG-xAC-VV-j7EBJB522+BqCyyFd_6N3KEr2Cf@mail.gmail.com> (Sedat Dilek's message of "Sun, 27 Feb 2011 16:38:17 +0100")

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

  reply	other threads:[~2011-02-27 15:57 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-25 22:22 John W. Linville
2011-02-27 15:23 ` Sedat Dilek
2011-02-27 15:31   ` Dave Täht
2011-02-27 15:38     ` Sedat Dilek
2011-02-27 15:56       ` Dave Täht [this message]
2011-02-27 16:01         ` Sedat Dilek
2011-02-27 16:25           ` Dave Täht
2011-03-03 18:16             ` Rick Jones
2011-03-03 18:19               ` John W. Linville
2011-03-03 19:45               ` Tianji Li
2011-03-03 22:33                 ` Rick Jones
2011-03-08  6:58                 ` Pavel Machek
2011-03-08 18:48                   ` Rick Jones
2011-03-13 10:27                     ` Pavel Machek

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=8739n9ii7z.fsf@cruithne.co.teklibre.org \
    --to=d@taht.net \
    --cc=bloat-devel@lists.bufferbloat.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=sedat.dilek@gmail.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