Messages in this thread | | | Date | Thu, 30 Oct 2008 21:01:19 +0200 (EET) | From | "Ilpo Järvinen" <> | Subject | Re: [tbench regression fixes]: digging out smelly deadmen. |
| |
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.
| |