From: Greg KH <gregkh@suse.de>
To: linux-kernel@vger.kernel.org, stable@kernel.org, jejb@kernel.org
Cc: Justin Forbes <jmforbes@linuxtx.org>,
Zwane Mwaikambo <zwane@arm.linux.org.uk>,
"Theodore Ts'o" <tytso@mit.edu>,
Randy Dunlap <rdunlap@xenotime.net>,
Dave Jones <davej@redhat.com>,
Chuck Wolber <chuckw@quantumlinux.com>,
Chris Wedgwood <reviews@ml.cw.f00f.org>,
Michael Krufky <mkrufky@linuxtv.org>,
Chuck Ebbert <cebbert@redhat.com>,
Domenico Andreoli <cavokz@gmail.com>, Willy Tarreau <w@1wt.eu>,
Rodrigo Rubira Branco <rbranco@la.checkpoint.com>,
Jake Edge <jake@lwn.net>, Eugene Teo <eteo@redhat.com>,
torvalds@linux-foundation.org, akpm@linux-foundation.org,
alan@lxorguk.ukuu.org.uk, Dario Faggioli <raistlin@linux.it>,
Michael Trimarchi <trimarchimichael@yahoo.it>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Ingo Molnar <mingo@elte.hu>
Subject: [patch 05/14] sched_rt.c: resch needed in rt_rq_enqueue() for the root rt_rq
Date: Sat, 18 Oct 2008 11:57:24 -0700 [thread overview]
Message-ID: <20081018185724.GF17196@suse.de> (raw)
In-Reply-To: <20081018185658.GA17196@suse.de>
[-- Attachment #1: sched_rt.c-resch-needed-in-rt_rq_enqueue-for-the-root-rt_rq.patch --]
[-- Type: text/plain, Size: 2358 bytes --]
2.6.25-stable review patch. If anyone has any objections, please let us
know.
------------------
From: Dario Faggioli <raistlin@linux.it>
commit f6121f4f8708195e88cbdf8dd8d171b226b3f858 upstream
While working on the new version of the code for SCHED_SPORADIC I
noticed something strange in the present throttling mechanism. More
specifically in the throttling timer handler in sched_rt.c
(do_sched_rt_period_timer()) and in rt_rq_enqueue().
The problem is that, when unthrottling a runqueue, rt_rq_enqueue() only
asks for rescheduling if the runqueue has a sched_entity associated to
it (i.e., rt_rq->rt_se != NULL).
Now, if the runqueue is the root rq (which has a rt_se = NULL)
rescheduling does not take place, and it is delayed to some undefined
instant in the future.
This imply some random bandwidth usage by the RT tasks under throttling.
For instance, setting rt_runtime_us/rt_period_us = 950ms/1000ms an RT
task will get less than 95%. In our tests we got something varying
between 70% to 95%.
Using smaller time values, e.g., 95ms/100ms, things are even worse, and
I can see values also going down to 20-25%!!
The tests we performed are simply running 'yes' as a SCHED_FIFO task,
and checking the CPU usage with top, but we can investigate thoroughly
if you think it is needed.
Things go much better, for us, with the attached patch... Don't know if
it is the best approach, but it solved the issue for us.
Signed-off-by: Dario Faggioli <raistlin@linux.it>
Signed-off-by: Michael Trimarchi <trimarchimichael@yahoo.it>
Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
kernel/sched_rt.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
--- a/kernel/sched_rt.c
+++ b/kernel/sched_rt.c
@@ -91,12 +91,12 @@ static void dequeue_rt_entity(struct sch
static void sched_rt_rq_enqueue(struct rt_rq *rt_rq)
{
+ struct task_struct *curr = rq_of_rt_rq(rt_rq)->curr;
struct sched_rt_entity *rt_se = rt_rq->rt_se;
- if (rt_se && !on_rt_rq(rt_se) && rt_rq->rt_nr_running) {
- struct task_struct *curr = rq_of_rt_rq(rt_rq)->curr;
-
- enqueue_rt_entity(rt_se);
+ if (rt_rq->rt_nr_running) {
+ if (rt_se && !on_rt_rq(rt_se))
+ enqueue_rt_entity(rt_se);
if (rt_rq->highest_prio < curr->prio)
resched_task(curr);
}
--
next prev parent reply other threads:[~2008-10-18 19:21 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20081018185031.236868964@mini.kroah.org>
2008-10-18 18:56 ` [patch 00/14] 2.6.25-stable review Greg KH
2008-10-18 18:57 ` [patch 01/14] x86: Reserve FIRST_DEVICE_VECTOR in used_vectors bitmap Greg KH
2008-10-18 18:57 ` [patch 02/14] x86: improve UP kernel when CPU-hotplug and SMP is enabled Greg KH
2008-10-18 18:57 ` [patch 03/14] x86, early_ioremap: fix fencepost error Greg KH
2008-10-18 18:57 ` [patch 04/14] tty: Termios locking - sort out real_tty confusions and lock reads Greg KH
2008-10-18 18:57 ` Greg KH [this message]
2008-10-18 18:57 ` [patch 06/14] CIFS: make sure we have the right resume info before calling CIFSFindNext Greg KH
2008-10-18 18:57 ` [patch 07/14] b43legacy: Fix failure in rate-adjustment mechanism Greg KH
2008-10-18 18:57 ` [patch 08/14] fbcon_set_all_vcs: fix kernel crash when switching the rotated consoles Greg KH
2008-10-18 18:57 ` [patch 09/14] hwmon: (it87) Prevent power-off on Shuttle SN68PT Greg KH
2008-10-18 18:57 ` [patch 10/14] Dont allow splice() to files opened with O_APPEND Greg KH
2008-10-18 18:57 ` [patch 11/14] V4L: bttv: Prevent NULL pointer dereference in radio_open Greg KH
2008-10-18 18:57 ` [patch 12/14] V4L: zr36067: Fix RGBR pixel format Greg KH
2008-10-18 18:57 ` [patch 13/14] drm/i915: fix ioremap of a user address for non-root (CVE-2008-3831) Greg KH
2008-10-18 18:57 ` [patch 14/14] x86: work around MTRR mask setting, v2 Greg KH
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=20081018185724.GF17196@suse.de \
--to=gregkh@suse.de \
--cc=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=cavokz@gmail.com \
--cc=cebbert@redhat.com \
--cc=chuckw@quantumlinux.com \
--cc=davej@redhat.com \
--cc=eteo@redhat.com \
--cc=jake@lwn.net \
--cc=jejb@kernel.org \
--cc=jmforbes@linuxtx.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=mkrufky@linuxtv.org \
--cc=raistlin@linux.it \
--cc=rbranco@la.checkpoint.com \
--cc=rdunlap@xenotime.net \
--cc=reviews@ml.cw.f00f.org \
--cc=stable@kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=trimarchimichael@yahoo.it \
--cc=tytso@mit.edu \
--cc=w@1wt.eu \
--cc=zwane@arm.linux.org.uk \
/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