Re: About git-bisect (was: Linux 2.6.28-rc7)

Re: About git-bisect (was: Linux 2.6.28-rc7)

[Toralf Förster]

[-- Attachment #1: Type: text/plain, Size: 248 bytes --]


>I need more than 20min to compile each kernel, so is necessary ~260min.
Try to us ccache. It should speed up such compile orgy a lot.
-- 
MfG/Sincerely

Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: About git-bisect (was: Linux 2.6.28-rc7)

[Francis Moreau]

Linus Torvalds <torvalds@linux-foundation.org> writes:

> That said, the _best_ way to speed up your compile (whether bisecting or 
> not) is to simply only compile the drivers and modules you actually need. 

That's interesting because I recently tried to strip down my kernel
configuration but I met a problem: I usually don't know if I really
need a feature or not, and that's specially true when configuring the
network stuffs, since I'm not a network expert...

So I still have 254 modules and after recompiling my kernel, I did:

	$ touch kernel/sched.c
	$ time make -j4
	[...]
	MODPOST 254 modules
	[...]
	Kernel: arch/x86/boot/bzImage is ready  (#109)
	
	real    3m23.866s
	user    0m35.006s
	sys     0m15.698s

and here is the time I get if I recompile the kernel without touching
any files:

	$ time make -j4
	  CHK     include/linux/version.h
	  CHK     include/linux/utsrelease.h
	  SYMLINK include/asm -> include/asm-x86
	  CALL    scripts/checksyscalls.sh
	  CHK     include/linux/compile.h
	dnsdomainname: Unknown host
	  CHK     include/linux/version.h
	make[2]: `scripts/unifdef' is up to date.
	  Building modules, stage 2.
	Kernel: arch/x86/boot/bzImage is ready  (#109)
	  MODPOST 254 modules
	
	real      0m53.612s
	user      0m17.996s
	sys       0m9.752s

With these figures, I can confirm that doing bisection, even with 5
reboots, is painful.

> It takes me 16 seconds to compile my kernel (if it's all cached), and 
> that's largely because I do _not_ compile one of the crazy distro kernels 
> with thousands of totally irrelevant modules for my setup.

an other reason is perhaps you're using a computer that most common
mortal don't have ;)

Care to share your network configuration ;) ?

thanks

Francis

Re: About git-bisect (was: Linux 2.6.28-rc7)

[Linus Torvalds]

On Tue, 2 Dec 2008, Sam Ravnborg wrote:
> 
> You do not need to do a "make clean" between each build, so if none
> of the core files are touched you should be much faster.

Not for big ranges, sadly.

Because "git bisect" tends to jump around wildly, it's very rare to not 
have to rebuild the whole tree. Only at the very last few bisection events 
(when it's been narrowed down to just a few tens of commits) will you 
generally see your compiles speed up.

That said, the _best_ way to speed up your compile (whether bisecting or 
not) is to simply only compile the drivers and modules you actually need. 
It takes me 16 seconds to compile my kernel (if it's all cached), and 
that's largely because I do _not_ compile one of the crazy distro kernels 
with thousands of totally irrelevant modules for my setup.

A good config file will not just result in a smaller kernel, it will often 
cut down your kernel compile times by a factor of ten or even more.

				Linus

Re: About git-bisect (was: Linux 2.6.28-rc7)

[Linus Torvalds]

On Tue, 2 Dec 2008, Renato S. Yamane wrote:
>
> Linus Torvalds wrote:
> > Just do
> > 
> > 	git bisect start
> > 	git bisect bad v2.6.27
> > 	git bisect good v2.6.28-rc6-00007-ged31348
> > 
> > and off you go. That would help enormously.
> 
> Hi Linus, is possible plan something to make faster and easier the way
> to loking for a specific bug?

Well, normally 'git bisect' is pretty optimal, if you don't have "extra" 
information. 

> E.g: <https://bugs.launchpad.net/ubuntu/+source/linux/+bug/110784>
> 
> In this bug, I think that it appear after ~2.6.22, so is necessary do a 
> git-bisect more than 13 times!

Well, thirteen kernel compiles and bootups may feel really painful, and I 
agree that it's not exactly pleasant, but considering that there's almost 
ten _thousand_ commits there, isnt' it nice to only have to test 13 
kernels?

> I need more than 20min to compile each kernel, so is necessary ~260min.
> 
> My wife will kill me if I says: Hey baby, wait 260min to me compile a
> lot of kernel here.

heh. It will probably take a lot longer than 260 min, if only because you 
need to reboot and test. And yes, it's painful.

You _can_ speed it up if you already have a good clue about where the bug 
is, and if you know which files/directories are involved, you can give 
that pathname list to "git bisect start". IOW, you can do things like

	git bisect start drivers/acpi arch/x86/kernel/acpi

if you are _sure_ that it's really an ACPI issue, for example. But let me 
be honest: about 50% of the time people have ever tried this, their guess 
has actually turned out to be wrong, and they actually caused _more_ time 
to be wasted rather than less. Which is why I do not generally ever 
suggest using this mode, even if it's better "in theory".

There's another way you can speed up bisection if you have a guess about 
_when_ it happened (as opposed to where). What you can do, is that when 
"git bisect" runs and gives you a suggested commit to compile, you can 
decide that you actually have a better idea, and use "git reset <mycommit>" 
instead to say "I want to test at _this_ point instead, to narrow it down 
faster".

However, as with the path-based one, in order for this to actually speed 
up bisection, you really need to guess right - and you need to understand 
how bisection works. You don't want to guess at the bad commit - instead, 
you want to guess at a commit that _limits_ the set of commits to be 
tested to the bad one in an optimal way.

IOW rather than doing 13 tries, what you can do if you suspect a 
particular range of commits is to first try a commit just before that 
range (on the assumption that it will be good), and then if that worked 
out, try a commit just after the range (on the guess that it will be bad), 
and now you may have cut down the guesses from ten thousand to just a 
couple of hundred with just two tries.

Of course, again - if your guesses were bad, you effectively screwed up 
the 'log2(n)' behavior of "git bisect", and instead of 13 tries you 
probably now have 14 or 15 instead, because your two first tries were just 
not very helpful, and lessened the number of commits to try by much less 
than half each.

The good news, of course, is that if multiple people see the same bug, you 
can actually distribute the bisection load across machines. That works 
only if it is really guaranteed to be the same bug, of course. And it 
won't make it possible to do things in parallel (since each bisection is 
still dependent on the result from the previous one), but it means that 
even if you decide that "13 bisections is too much", if you just do four 
or five, and tell others about your results, now somebody else who thinks 
that they have the same issue can at least start from your range.

Again, that actually requires that people udnerstand how bisection works, 
although it can be done blindly by people just doing "git bisect replay" 
and just assuming that they really see exactly the same issue.

			Linus

Re: About git-bisect (was: Linux 2.6.28-rc7)

[Sam Ravnborg]

> 
> I need more than 20min to compile each kernel, so is necessary ~260min.

You do not need to do a "make clean" between each build, so if none
of the core files are touched you should be much faster.
Do you bisect and then type make should be enough.

	Sam

About git-bisect (was: Linux 2.6.28-rc7)

[Renato S. Yamane]

Linus Torvalds wrote:
> Just do
> 
> 	git bisect start
> 	git bisect bad v2.6.27
> 	git bisect good v2.6.28-rc6-00007-ged31348
> 
> and off you go. That would help enormously.

Hi Linus, is possible plan something to make faster and easier the way
to loking for a specific bug?

E.g:
<https://bugs.launchpad.net/ubuntu/+source/linux/+bug/110784>

In this bug, I think that it appear after ~2.6.22, so is necessary do a
git-bisect more than 13 times!

I need more than 20min to compile each kernel, so is necessary ~260min.

My wife will kill me if I says: Hey baby, wait 260min to me compile a
lot of kernel here.

Best regards,
Renato