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
* Zhang, Yanmin <[email protected]> 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 <[email protected]>
Date: Fri Jan 25 21:08:00 2008 +0100
sched: group scheduling, change how cpu load is calculated
commit 6b2d7700266b9402e12824e11e0099ae6a4a6a79
Author: Srivatsa Vaddagiri <[email protected]>
Date: Fri Jan 25 21:08:00 2008 +0100
sched: group scheduler, fix fairness of cpu bandwidth allocation for task
Ingo
On Fri, 2008-03-07 at 08:34 +0100, Ingo Molnar wrote:
> * Zhang, Yanmin <[email protected]> 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 <[email protected]>
> Date: Fri Jan 25 21:08:00 2008 +0100
> sched: group scheduling, change how cpu load is calculated
>
> commit 6b2d7700266b9402e12824e11e0099ae6a4a6a79
> Author: Srivatsa Vaddagiri <[email protected]>
> Date: Fri Jan 25 21:08:00 2008 +0100
> sched: group scheduler, fix fairness of cpu bandwidth allocation for task
>
> Ingo