linux-kernel - sched tree bisectability

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <20080421.203212.262634448.davem@davemloft.net>
Date:	Mon, 21 Apr 2008 20:32:12 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	linux-kernel@...r.kernel.org
CC:	mingo@...e.hu, a.p.zijlstra@...llo.nl
Subject: sched tree bisectability


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@...llo.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@...llo.nl>
    Signed-off-by: Ingo Molnar <mingo@...e.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@...llo.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@...llo.nl>
    Signed-off-by: Ingo Molnar <mingo@...e.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;
 };
 
--
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/