From: Wanpeng Li <wanpeng.li@linux.intel.com>
To: Ingo Molnar <mingo@redhat.com>, Peter Zijlstra <peterz@infradead.org>
Cc: Juri Lelli <juri.lelli@arm.com>,
Kirill Tkhai <ktkhai@parallels.com>,
linux-kernel@vger.kernel.org,
Wanpeng Li <wanpeng.li@linux.intel.com>
Subject: [PATCH] sched: fix start hrtick for short schedule slices on UP
Date: Fri, 21 Nov 2014 16:24:43 +0800 [thread overview]
Message-ID: <1416558283-204916-1-git-send-email-wanpeng.li@linux.intel.com> (raw)
Start hrtick for schedule slices shorter than 10000ns doesn't make any
sense and can cause timer DoS.
The commit 177ef2a6315e ("sched/deadline: Fix a precision problem in
the microseconds range") fixes the shorter slices issue for dl class.
Both the UP and SMP sides of hrtick_start() will handle the shorter
slices issue before the commit, however, the UP side of hrtick_start()
doesn't handle shorter slides issue any more after the commit applied.
This patch fix it by making sure the scheduling slice won't be smaller
than 10us in the UP side of hrtick_start() for fair and dl schedule
class.
Signed-off-by: Wanpeng Li <wanpeng.li@linux.intel.com>
---
kernel/sched/core.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index d44d0c5..dbfcca6 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -490,6 +490,11 @@ static __init void init_hrtick(void)
*/
void hrtick_start(struct rq *rq, u64 delay)
{
+ /*
+ * Don't schedule slices shorter than 10000ns, that just
+ * doesn't make sense. Rely on vruntime for fairness.
+ */
+ delay = max_t(u64, delay, 10000LL);
__hrtimer_start_range_ns(&rq->hrtick_timer, ns_to_ktime(delay), 0,
HRTIMER_MODE_REL_PINNED, 0);
}
--
1.9.1
reply other threads:[~2014-11-21 8:24 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=1416558283-204916-1-git-send-email-wanpeng.li@linux.intel.com \
--to=wanpeng.li@linux.intel.com \
--cc=juri.lelli@arm.com \
--cc=ktkhai@parallels.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®