netdev - Re: [PATCH 0/2] HTB scheduler HTB

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4846B55D.4060306@cdi.cz>
Date:	Wed, 04 Jun 2008 17:31:41 +0200
From:	Martin Devera <devik@....cz>
To:	jdb@...x.dk
CC:	"David S. Miller" <davem@...emloft.net>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH 0/2] HTB scheduler HTB_HYSTERESIS modifications

>> I'm thinking about removing HYSTERESIS code altogether, but
>> (and it holds for setting HYSTERESIS=off as default) 
> 
> I prefer a turn knob, where the default is off.

Ok. As seen from interrupt load below, it is reasonable.

> With current testing (on 2.6.25.4) I could not see any changes with CPU
> usage, but thats probably caused by the fast CPU on the test system
> (Dual Xeon). BUT an interesting observation was that the number of
> interrupts increased significantly, from approx 1300 to 2000 per sec.
> The other observation was that I got significantly less jitter.

Interesting. It is probably result of merging of subsequent yellow/red
states without going to green for while. The traffic is more bursty then
(it is no longer only timer-granular, but {c,}burst sized bursts are
FORCED in output) but NIC driver can emit more outgoing packets
per in single "buffer free" interrupt.

>> Also, I'm a bit busy for a few weeks, would you be able/interested
>> to do such testing ?
> 
> Okay, lets wait until I get this kernel into our real-life production
> system.  Then I can report on the real-life impact on CPU performance.

Thanks, I'll try to set some test up later. With large class-count as
state changes will cost more then (RB tree deletes/inserts).

Regarding your intr/sec count, what about to keep default value
of hysteresis switch as "on" (just to be on safe side) ?
I'm afraid what that 40% larger interrupt load might do with bigger
routers (I already got some performance related questions from ppl
with hundreds classes on 100's Mb links).

m.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html