lkml.org 
[lkml]   [2008]   [Mar]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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


\
 
 \ /
  Last update: 2008-03-07 08:37    [W:0.157 / U:0.300 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site