Re: [tbench regression fixes]: digging out smelly deadmen.

Ilpo Järvinen
2008-10-30T19:05:30Z

On Thu, 30 Oct 2008, Stephen Hemminger wrote:

> Has anyone looked into the impact of port randomization on this benchmark.
> If it is generating lots of sockets quickly there could be an impact:
> * port randomization causes available port space to get filled non-uniformly
> and what was once a linear scan may have to walk over existing ports.
> (This could be improved by a hint bitmap)
>
> * port randomization adds at least one modulus operation per socket
> creation. This could be optimized by using a loop instead.

I did something with AIM9's tcp_test recently (1-2 days ago depending on
how one calculates that so didn't yet have time summarize the details in
the AIM9 thread) by deterministicly binding in userspace and got much more
sensible numbers than with randomized ports (2-4%/5-7% vs 25% variation
some difference in variation in different kernel versions even with
deterministic binding). Also, I'm still to actually oprofile and bisect
the remaining ~4% regression (around 20% was reported by Christoph). For
oprofiling I might have to change aim9 to do predefined number of loops
instead of a deadline to get more consistent view on changes in per func
runtime.

AIM9 is one process only so scheduler has a bit less to do in that
benchmark anyway.

It would probably be nice to test just the port randomizer separately to
see if there's some regression in that but I don't expect it to happen
any time soon unless I quickly come up with something in the bisection.

--
i.