[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1225134690.4942.11.camel@marge.simson.net>
Date: Mon, 27 Oct 2008 20:11:30 +0100
From: Mike Galbraith <efault@....de>
To: Rick Jones <rick.jones2@...com>
Cc: David Miller <davem@...emloft.net>, rjw@...k.pl, mingo@...e.hu,
s0mbre@...rvice.net.ru, a.p.zijlstra@...llo.nl,
linux-kernel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [tbench regression fixes]: digging out smelly deadmen.
On Mon, 2008-10-27 at 10:26 -0700, Rick Jones wrote:
> Mike Galbraith wrote:
> > That's exactly what I've been trying to look into, but combined with
> > netperf. The thing is an incredibly twisted maze of _this_ affects
> > _that_... sometimes involving magic and/or mythical creatures.
>
> I cannot guarantee it will help, but the global -T option to pin netperf
> or netserver to a specific CPU might help cut-down the variables.
Yup, and how. Early on, the other variables drove me bat-shit frigging
_nuts_. I eventually selected a UP config to test _because_ those other
variables combined with SMP overhead and config options drove crazy ;-)
> FWIW netperf top of trunk omni tests can now also determine and report
> the state of SELinux. They also have code to accept or generate their
> own RFC4122-esque UUID. Define some connical tests and then ever closer
> to just needing some database-fu and automagic testing I suppose...
> things I do not presently posess but am curious enough to follow some
> pointers.
Hrm. I'm going to have to save that, and parse a few times. (usual)
> happy benchmarking,
Not really, but I can't seem to give up ;-)
-Mike
--
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
Powered by blists - more mailing lists