git bisect in 2.6.25-rc1 looks weird

git bisect in 2.6.25-rc1 looks weird

[Zhang, Yanmin]

I am tracking a performance issue of volanoMark with kernel 2.6.25-rc1.

As reverting patch have conflictions, I decided to bisect between:
Good tag:       6b2d7700266b9402e12824e11e0099ae6a4a6a79
and
Bad tag:        550ade8432a2a6fbfb48ba7018750b0e8c81e8d0.

#git bisect start
#git bisect good 6b2d7700266b9402e12824e11e0099ae6a4a6a79
#git bisect bad 550ade8432a2a6fbfb48ba7018750b0e8c81e8d0
Bisecting: 910 revisions left to test after this
[50d9a126240f9961cfdd063336bbeb91f77a7dce] Merge git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6

By "git log", I could see 50d9a126240f9961cfdd063336bbeb91f77a7dce is committed
between 6b2d7700266b9402e12824e11e0099ae6a4a6a79 and 550ade8432a2a6fbfb48ba7018750b0e8c81e8d0. 
Then,
#git bisect bad
Bisecting: 429 revisions left to test after this
[95af8a26cba55222d6a1beda7970431b4fbbbdd6] V4L/DVB (6958): tda18271: clean up function tda18271_set_analog_params

By "git log", I couldn't find commit of 6b2d7700266b9402e12824e11e0099ae6a4a6a79 and
550ade8432a2a6fbfb48ba7018750b0e8c81e8d0. I find patch 6b2d7700266b9402e12824e11e0099ae6a4a6a79
isn't applied at this time. So bisect in this step looks jumping out of the original range.


If I just manually checkout to the commit point of 95af8a26cba55222d6a1beda7970431b4fbbbdd6, I
find 6b2d7700266b9402e12824e11e0099ae6a4a6a79 isn't applied. Command is: #git checkout -b test1 95afXXX.
If I just manually checkout to the commit point of 6b2d7700266b9402e12824e11e0099ae6a4a6a79 , I
find 95af8a26cba55222d6a1beda7970431b4fbbbdd6 isn't applied.

Are the patches committed in line? or there are many paths crossing?

It looks weird.

-yanmin

Re: git bisect in 2.6.25-rc1 looks weird

[Ingo Molnar]

* Zhang, Yanmin <yanmin_zhang@linux.intel.com> wrote:

> Are the patches committed in line? or there are many paths crossing?

it's fine. git-bisect works on a tree of commits (not a queue/line of 
commits) - so certain 'lines' of patches can jump in and out.

the scheduler patches are always in a straight line, so later on in the 
bisection the jumping should be simplified.

you might want to look at "gitk" output and pick out a specific line of 
scheduler patches. For example:

  commit 32a76006683f7b28ae3cc491da37716e002f198e

to:

  commit 6d082592b62689fb91578d0338d04a9f50991990

is a straight line of 95 scheduler related commits. That's one of the 
probable areas where the regression you are looking for came in. 

when you bisect that specific range, you should try to undo the 
following two commits:

      commit 58e2d4ca581167c2a079f4ee02be2f0bc52e8729
      Author: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
      Date:   Fri Jan 25 21:08:00 2008 +0100
      sched: group scheduling, change how cpu load is calculated

      commit 6b2d7700266b9402e12824e11e0099ae6a4a6a79
      Author: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
      Date:   Fri Jan 25 21:08:00 2008 +0100
      sched: group scheduler, fix fairness of cpu bandwidth allocation for task

	Ingo

Re: git bisect in 2.6.25-rc1 looks weird

[Zhang, Yanmin]

On Fri, 2008-03-07 at 08:34 +0100, Ingo Molnar wrote:
> * Zhang, Yanmin <yanmin_zhang@linux.intel.com> wrote:
> 
> > Are the patches committed in line? or there are many paths crossing?
> 
> it's fine. git-bisect works on a tree of commits (not a queue/line of 
> commits) - so certain 'lines' of patches can jump in and out.
> 
> the scheduler patches are always in a straight line, so later on in the 
> bisection the jumping should be simplified.
Thanks.

> 
> you might want to look at "gitk" output and pick out a specific line of 
> scheduler patches. For example:
> 
>   commit 32a76006683f7b28ae3cc491da37716e002f198e
> 
> to:
> 
>   commit 6d082592b62689fb91578d0338d04a9f50991990
> 
> is a straight line of 95 scheduler related commits. That's one of the 
> probable areas where the regression you are looking for came in. 
> 
> when you bisect that specific range, you should try to undo the 
> following two commits:
It looks like many patches commited ater the 2 patches changed same
code lines or nearby code lines. So there are many conflictions when I undo
the 2 patches.

Let me retry.

> 
>       commit 58e2d4ca581167c2a079f4ee02be2f0bc52e8729
>       Author: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
>       Date:   Fri Jan 25 21:08:00 2008 +0100
>       sched: group scheduling, change how cpu load is calculated
> 
>       commit 6b2d7700266b9402e12824e11e0099ae6a4a6a79
>       Author: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
>       Date:   Fri Jan 25 21:08:00 2008 +0100
>       sched: group scheduler, fix fairness of cpu bandwidth allocation for task
> 
> 	Ingo