From: tip-bot for Peter Zijlstra <a.p.zijlstra@chello.nl>
To: linux-tip-commits@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, hpa@zytor.com, mingo@redhat.com,
eric.dumazet@gmail.com, torvalds@linux-foundation.org,
a.p.zijlstra@chello.nl, schwidefsky@de.ibm.com,
fweisbec@gmail.com, suresh.b.siddha@intel.com, dsahern@gmail.com,
tglx@linutronix.de, mingo@elte.hu
Subject: [tip:sched/urgent] sched: Fix lockup by limiting load-balance retries on lock-break
Date: Wed, 11 Jan 2012 22:17:09 -0800 [thread overview]
Message-ID: <tip-bced76aeaca03b45e3b4bdb868cada328e497847@git.kernel.org> (raw)
In-Reply-To: <1326297936.2442.157.camel@twins>
Commit-ID: bced76aeaca03b45e3b4bdb868cada328e497847
Gitweb: http://git.kernel.org/tip/bced76aeaca03b45e3b4bdb868cada328e497847
Author: Peter Zijlstra <a.p.zijlstra@chello.nl>
AuthorDate: Wed, 11 Jan 2012 13:11:12 +0100
Committer: Ingo Molnar <mingo@elte.hu>
CommitDate: Wed, 11 Jan 2012 17:15:12 +0100
sched: Fix lockup by limiting load-balance retries on lock-break
Eric and David reported dead machines and traced it to commit
a195f004 ("sched: Fix load-balance lock-breaking"), it turns out
there's still a scenario where we can end up re-trying forever.
Since there is no strict forward progress guarantee in the
load-balance iteration we can get stuck re-retrying the same
task-set over and over.
Creating a forward progress guarantee with the existing
structure is somewhat non-trivial, for now simply terminate the
retry loop after a few tries.
Reported-by: Eric Dumazet <eric.dumazet@gmail.com>
Tested-by: Eric Dumazet <eric.dumazet@gmail.com>
Reported-by: David Ahern <dsahern@gmail.com>
[ logic cleanup as suggested by Eric ]
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Suresh Siddha <suresh.b.siddha@intel.com>
Link: http://lkml.kernel.org/r/1326297936.2442.157.camel@twins
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
kernel/sched/fair.c | 10 +++++++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 8e42de9..84adb2d 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -3130,8 +3130,10 @@ task_hot(struct task_struct *p, u64 now, struct sched_domain *sd)
}
#define LBF_ALL_PINNED 0x01
-#define LBF_NEED_BREAK 0x02
-#define LBF_ABORT 0x04
+#define LBF_NEED_BREAK 0x02 /* clears into HAD_BREAK */
+#define LBF_HAD_BREAK 0x04
+#define LBF_HAD_BREAKS 0x0C /* count HAD_BREAKs overflows into ABORT */
+#define LBF_ABORT 0x10
/*
* can_migrate_task - may task p from runqueue rq be migrated to this_cpu?
@@ -4508,7 +4510,9 @@ redo:
goto out_balanced;
if (lb_flags & LBF_NEED_BREAK) {
- lb_flags &= ~LBF_NEED_BREAK;
+ lb_flags += LBF_HAD_BREAK - LBF_NEED_BREAK;
+ if (lb_flags & LBF_ABORT)
+ goto out_balanced;
goto redo;
}
next prev parent reply other threads:[~2012-01-12 6:17 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-10 4:57 [BUG] kernel freezes with latest tree Eric Dumazet
2012-01-10 5:03 ` Eric Dumazet
2012-01-10 8:16 ` Eric Dumazet
2012-01-10 16:13 ` Eric Dumazet
2012-01-10 16:28 ` Linus Torvalds
2012-01-10 16:37 ` Eric Dumazet
2012-01-10 16:49 ` Linus Torvalds
2012-01-10 16:53 ` Eric Dumazet
2012-01-10 17:00 ` Linus Torvalds
2012-01-10 19:32 ` Ingo Molnar
2012-01-10 22:23 ` Eric Dumazet
2012-01-10 23:44 ` Linus Torvalds
2012-01-11 6:35 ` David Ahern
2012-01-11 9:04 ` Peter Zijlstra
2012-01-11 10:28 ` Eric Dumazet
2012-01-11 11:29 ` Eric Dumazet
2012-01-11 12:25 ` Peter Zijlstra
2012-01-11 13:24 ` Eric Dumazet
2012-01-11 15:56 ` Ingo Molnar
2012-01-11 16:05 ` Peter Zijlstra
2012-01-11 16:14 ` Ingo Molnar
2012-01-11 16:31 ` Linus Torvalds
2012-01-11 16:58 ` Peter Zijlstra
2012-01-12 6:17 ` tip-bot for Peter Zijlstra [this message]
2012-01-11 8:22 ` Eric Dumazet
2012-01-11 14:20 ` Frederic Weisbecker
2012-01-10 16:16 ` Linus Torvalds
2012-01-10 16:33 ` Eric Dumazet
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=tip-bced76aeaca03b45e3b4bdb868cada328e497847@git.kernel.org \
--to=a.p.zijlstra@chello.nl \
--cc=dsahern@gmail.com \
--cc=eric.dumazet@gmail.com \
--cc=fweisbec@gmail.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tip-commits@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=mingo@redhat.com \
--cc=schwidefsky@de.ibm.com \
--cc=suresh.b.siddha@intel.com \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.