On 05/05/2012 03:48 PM, dave taht wrote:

On 05/05/2012 03:39 PM, Eric Dumazet wrote:

On Sat, 2012-05-05 at 15:34 -0700, dave taht wrote:

On 05/05/2012 03:09 PM, Eric Dumazet wrote:

On Sat, 2012-05-05 at 15:03 -0700, dave taht wrote:

Maybe on your arch, but highly doubtful on a 680Mhz mips that isn't even
superscalar.

CPU are fast, memory is slow.

I'd prefer to leave it in and be able to compile it out, and actually
measure the difference.

You optimize the case where there is no need to optimize (small queue)

I can see count bigger than 100000 with 20 concurrent netperf

This makes no sense to have a cache so big.

Or there is a bug in codel

The original reciprocol approximation test code rapidly goes AWOL after
exceeding 2^8.

I went looking for butterflies and didn't see any in the scaled code in
the range 0-100000,
and they would only take flight briefly, so...

However I have not corrected it for BITS_PER_LONG as per our 4AM
discussion.

You should use the exact code in kernel. (using BITS_PER_LONG)

...

interval/sqrt(99999)=316229 approx :6250190 19.76475908 interval/scaled:
316236 1.00002214

If you read the code , there is no possible overflow, even with very
large 'u32 count'

anyway the problem is q->count keeps increasing under load.

Only when load is stopped for a while, count is reset to 1

Stalking butterflies. ( http://en.wikipedia.org/wiki/File:Lorenz_attractor_yb.svg )

I suspected also we would have issues as we hit some natural quantums (clock rate/interrupt rate/bql estimator etc) but for all I know it's just a plain bug. I need a reboot. Goin to dinner.

If we just compare us to us rather than ns to ns you get chunkier drops, by a lot...

interval/sqrt(370)=5198752 approx :6250190 1.20224815 interval/scaled: 5198761 1.00000173
interval/sqrt(371)=5191741 approx :6250190 1.20387169 interval/scaled: 5191776 1.00000674


secondly adding a fudge factor to the calculation would bring it closer to inline with an actual sqrt.