Re: git bisect in 2.6.25-rc1 looks weird

[Ingo Molnar <mingo@elte.hu>]

* 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