Messages in this thread | | | Date | Fri, 7 Mar 2008 08:34:34 +0100 | From | Ingo Molnar <> | Subject | Re: git bisect in 2.6.25-rc1 looks weird |
| |
* 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
| |