On Tue, 11 Mar 2008, Andi Kleen wrote:
quoted text
> > It's a question of how you write such test code to achieve
> > reproducability. It's not rocket science to track the variables of a
> > test run and print them along with the printk, when a wrong state is
> > detected. 
> 
> If you wanted to do that you would need some variant of my patch too --
> to do it with random32() you would first need to print all NR_CPUS
> state (and implement "kernel less" first for NR_CPUS > 128 kernels :),
> then keep track of all CPUs the test thread ran on and print that
> out too and also disable the regular timer reseeder to avoid races.
> Clearly doesn't make sense.
> 
> random32() in lib/ is simply unusable as a deterministic RND,
> it's more like super weak strange /dev/random variant which
> probably should be never put into lib/ anyways because it's unlikely
> to be generally useful.
> 
> So for a random but repeatable sequence like you describe you could keep the 
> patch, replace the static int next = 1; with static int next and add a 
> get_random_bytes(&next, sizeof(next)); and then print out the next value

Oh well. Randomized test code is there to catch bugs by statistical
spreading. Having a pseudo randomized scenario which is repeatable per
machine is defeating the randomized approach. Repeating a test with a
stale pattern is pretty useless unless you catch a bug right in the
first run.

The only bug that code ever caught aside of tons of false positives
was when we increased the runtime length and added the thread which
repeated the test.

Finding a bug, when it was exposed by a static pattern, is trivial,
but the challenge is to make such tests useful enough with random
patterns. And there are ways to do that, e.g. by making the debug
output informative enough to provide information about the problem in
detail instead of printing some useless info "a != b".

Thanks,

	tglx
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/