[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20080307073434.GA27975@elte.hu>
Date: Fri, 7 Mar 2008 08:34:34 +0100
From: Ingo Molnar <mingo@...e.hu>
To: "Zhang, Yanmin" <yanmin_zhang@...ux.intel.com>
Cc: LKML <linux-kernel@...r.kernel.org>
Subject: Re: git bisect in 2.6.25-rc1 looks weird
* Zhang, Yanmin <yanmin_zhang@...ux.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@...ux.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@...ux.vnet.ibm.com>
Date: Fri Jan 25 21:08:00 2008 +0100
sched: group scheduler, fix fairness of cpu bandwidth allocation for task
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists