sched tree bisectability

sched tree bisectability

[David Miller]

While trying to bisect a regression added by the sched tree merges
today, I found the following gem that broke compilation mid-bisect:

commit d0b27fa77854b149ad4af08b0fe47fe712a47ade
Author: Peter Zijlstra <a.p.zijlstra@chello.nl>
Date:   Sat Apr 19 19:44:57 2008 +0200

    sched: rt-group: synchonised bandwidth period
    
    Various SMP balancing algorithms require that the bandwidth period
    run in sync.
    
    Possible improvements are moving the rt_bandwidth thing into root_domain
    and keeping a span per rt_bandwidth which marks throttled cpus.
    
    Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Signed-off-by: Ingo Molnar <mingo@elte.hu>


That change adds:

@@ -156,6 +161,80 @@ struct rt_prio_array {
 	struct list_head queue[MAX_RT_PRIO];
 };
 
+struct rt_bandwidth {
+	ktime_t rt_period;
+	u64 rt_runtime;
+	struct hrtimer rt_period_timer;
+};
+

and then things like:

+static void start_rt_bandwidth(struct rt_bandwidth *rt_b)
+{
+	ktime_t now;
+
+	if (rt_b->rt_runtime == RUNTIME_INF)
+		return;
+
+	if (hrtimer_active(&rt_b->rt_period_timer))
+		return;
+
+	spin_lock(&rt_b->rt_runtime_lock);

rt_bandwidth does not have a rt_runtime_lock member, so the compile
fails.  The very next changeset adds it:

commit ac086bc22997a2be24fc40fc8d46522fe7e03d11
Author: Peter Zijlstra <a.p.zijlstra@chello.nl>
Date:   Sat Apr 19 19:44:58 2008 +0200

    sched: rt-group: smp balancing
    
    Currently the rt group scheduling does a per cpu runtime limit, however
    the rt load balancer makes no guarantees about an equal spread of real-
    time tasks, just that at any one time, the highest priority tasks run.
    
    Solve this by making the runtime limit a global property by borrowing
    excessive runtime from the other cpus once the local limit runs out.
    
    Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Signed-off-by: Ingo Molnar <mingo@elte.hu>

diff --git a/kernel/sched.c b/kernel/sched.c
index bb20323..313cd4f 100644
--- a/kernel/sched.c
+++ b/kernel/sched.c
@@ -164,6 +164,7 @@ struct rt_prio_array {
 struct rt_bandwidth {
 	ktime_t rt_period;
 	u64 rt_runtime;
+	spinlock_t rt_runtime_lock;
 	struct hrtimer rt_period_timer;
 };
 

Re: sched tree bisectability

[Ingo Molnar]

* David Miller <davem@davemloft.net> wrote:

> While trying to bisect a regression added by the sched tree merges 
> today, I found the following gem that broke compilation mid-bisect:
[...]

> rt_bandwidth does not have a rt_runtime_lock member, so the compile 
> fails.  The very next changeset adds it:

sorry, i broke that bisection point and i should have noticed this and 
should have backmerged that chunk.

i've just added some scripting to avoid this in the future - the 
scheduler tree gets built on every commit point before it's pushed out. 
I just ran it through the outstanding scheduler patches (there's a 
hundred more pending) and they all pass this test.

I'm wondering whether there are any other maintenance practices others 
use to keep things like this slip through.

It could be caught on the testing side via a new git-checkout feature:

   git-checkout --random base..head

which would pick a random commit from a git tree (from the range of 
commits given), which could be combined with make randconfig? This could 
be used in pre-push testing.

Another thing we might think about is when neither care from the 
maintainer nor any testing caught an unusable commit - then we could 
perhaps, as a last-ditch effort teach git-bisect to avoid known "100% 
unusable" commit points.

Something like a (append-only, constantly growing, but not too huge) 
repository of known-unusable commits via a special exceptions file like 
.gitignore - say .git/git-bisect-unusable. [Plus perhaps a git-bisect 
--ignore-bad option so that if someone wants to run a pristine bisection 
it can be done too.]

The semantics would be to pass along this information across a pull as 
well, so that the known-unusable commit points would.

The downside of such an approach would be that the file would grow 
indefinitely, and would never shrink. That does not feel too good.

	Ingo

Re: sched tree bisectability

[Peter Zijlstra]

On Mon, 2008-04-21 at 20:32 -0700, David Miller wrote:
> While trying to bisect a regression added by the sched tree merges
> today, I found the following gem that broke compilation mid-bisect:

Hmm, sorry about that - I try avoid these things :-/