Re: git-rev-list: "--bisect" flag

From: Linus Torvalds <torvalds@osdl.org>
Date: Jun 19, 2005, 19:01 UTC
Message-ID: <Pine.LNX.4.58.0506191153350.2268@ppc970.osdl.org>
In-Reply-To: <20050619173634.GA25768@elte.hu>

On Sun, 19 Jun 2005, Ingo Molnar wrote:

Show 6 quoted lines

> 
> another assumption is that the number of testsystems is a power of two 
> minus 1. With 2 or more testsystems (and automated testing) you could 
> dissect the search space into 3, 5 or more roughly equal pieces in the 
> first step (2, 4, 8 ... sections are already supported via the bisect 
> flag).

Yeah. I don't think it matters much, though, since the "more testsystems" thing will only really end up helping by a fairly small amount, at the cost of much more complexity. The difference between "log2(N)" and "log5(N)" isn't _that_ big, and it's even smaller when you just do the power-of-two thing and use 4 systems instead of 5 (ie now it's "log4(N)" vs "log5(N)").

Also, to use multiple test-systems efficiently, they all end up having to be synchronized (ie the next iteration needs to get the result from all the test-systems from the previous one), so it's quite a lot of bother for not a lot of improvement. It also assumes you can partition the problem space well into <n> roughly equal pieces - which may or may not be true.

More importantly, quite often the nasty problems are the ones that only happen for one machine. Trying to make it easy for non-developers to test different kernels is what this is about: I started thinking about this when we had the "x86-64 SIGSEGV's for me" issue, where bisection was fairly easy in the -mm series due to a nice linear series, but even then you had to have tools to apply/unapply different patches etc.

		Linus