linux-kernel - Re: [BUG] kernel freezes with latest tree

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 for Android: free password hash cracker in your pocket

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

Message-ID: <1326301102.2442.171.camel@twins>
Date:	Wed, 11 Jan 2012 17:58:22 +0100
From:	Peter Zijlstra <peterz@...radead.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Ingo Molnar <mingo@...e.hu>, David Ahern <dsahern@...il.com>,
	Eric Dumazet <eric.dumazet@...il.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Martin Schwidefsky <schwidefsky@...ibm.com>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Suresh Siddha <suresh.b.siddha@...el.com>
Subject: Re: [BUG] kernel freezes with latest tree

On Wed, 2012-01-11 at 08:31 -0800, Linus Torvalds wrote:
> On Wed, Jan 11, 2012 at 8:05 AM, Peter Zijlstra <peterz@...radead.org> wrote:
> >
> > Ah, right! Silly me. One possibility is to rotate that list, except that
> > won't work for the cgroup case where we have another iteration.
> 
> I just wonder whether you *really* need that loop at all?
> 
> If something went wrong with the attempted task move - you raced with
> another cpu, or whatever - is there any real reason to even bother to
> try again?
> 
> It's just a heuristic, after all, and we'll come back to balancing later.
> 
> The minimal patch looks good, but I did want to ask whether people
> have considered just removing the looping entirely?

Yeah, I did consider it, and given the current code it doesn't really
make a difference either way. But ideally we'll go fix the code to
provide better progress over repeated attempts.

Esp for people who put the migration count rather low (-rt crackpots)
multiple rounds (provided progress) make more sense.

Something like the below snippet improves the progress for !cgroup
kernels, but it also defeats the regular termination condition since any
list with two or more elements will endlessly rotate until we hit the
break limit.

We could fix this by adding an iteration count and limit that to
nr_running I guess, but since world and dog compiles kernels with cgroup
muck these days we need something slightly more clever to deal with the
for_each_leaf_cfs_rq() loop in load_balance_fair().

Will ponder more.. 

---
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -3244,8 +3246,10 @@ balance_tasks(struct rq *this_rq, int th
 
 		if ((p->se.load.weight >> 1) > rem_load_move ||
 		    !can_migrate_task(p, busiest, this_cpu, sd, idle,
-				      lb_flags))
+				      lb_flags)) {
+			list_move_tail(&p->se.group_node, &busiest_cfs_rq->tasks);
 			continue;
+		}
 
 		pull_task(busiest, p, this_rq, this_cpu);
 		pulled++;

--
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/