linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Yin-goo Yim" <ygyim@konkuk.ac.kr>
To: <mingo@redhat.com>, <peterz@infradead.org>
Cc: <linux-kernel@vger.kernel.org>, <tj@kernel.org>,
	<torvalds@linux-foundation.org>, <jinh@konkuk.ac.kr>
Subject: [PATCH] sched: Fix rt_task to work properly
Date: Thu, 25 Aug 2016 20:29:59 +0900	[thread overview]
Message-ID: <1472124612156711.0.mail@mail> (raw)

Hi,
I am a graduate student of System Software Lab. at Konkuk University

We found that the rt_task() function returns true even if the task is a
deadline task scheduled by SCHED_DEADLINE, because the function simply
checks whether the priority of the task is smaller than 100. As the
priority of deadline tasks is smaller than 0, the rt_task() function
returns true for deadline tasks. However, there exists a separate function
(i.e., dl_task()) to check if a task is a deadline task. That is, we
believe that rt_task() has to return true only if the task is an rt task
scheduled by SCHED_FIFO or SCHED_RR, while giving false for deadline tasks.

This ambiguity of rt_task() is causing a strange problem in cgroup. More
precisely, we found that -EBUSY was always returned when we tried to run a
task group that consisted of rt tasks together with a deadline task. This
happened regardless of how much CPU resources were reserved by cgroups and

deadline tasks. It turns out that tg_rt_schedulable() returns ?EBUSY by the
following conditional statement for deadline tasks:
if (rt_bandwidth_enabled() && !runtime && tg_has_rt_tasks(tg))
return -EBUSY;
For deadline tasks, tg_has_rt_tasks() in the above statement has to return
false. However, the current implementation of rt_task() called by
tg_has_rt_tasks() only checks whether the priority of tasks are smaller
than 100; thus, it returns true even for deadline tasks that have a minus
number.

Our patch is to fix this problem by checking the priority of tasks more
precisely (i.e., 0 < priority < 100) in rt_task().

Signed-off-by: Yin-goo Yim <ygyim@konkuk.ac.kr>
---
include/linux/sched/deadline.h | 8 +-------
include/linux/sched/prio.h     | 8 ++++++++
include/linux/sched/rt.h       | 2 +-
3 files changed, 10 insertions(+), 8 deletions(-)

diff --git a/include/linux/sched/deadline.h b/include/linux/sched/deadline.h
index 9089a2a..3e38564 100644
--- a/include/linux/sched/deadline.h
+++ b/include/linux/sched/deadline.h
@@ -1,13 +1,7 @@
#ifndef _SCHED_DEADLINE_H
#define _SCHED_DEADLINE_H

-/*
- * SCHED_DEADLINE tasks has negative priorities, reflecting
- * the fact that any of them has higher prio than RT and
- * NORMAL/BATCH tasks.
- */
-
-#define MAX_DL_PRIO 0
+#include <linux/sched/prio.h>

static inline int dl_prio(int prio)
{
diff --git a/include/linux/sched/prio.h b/include/linux/sched/prio.h
index d9cf5a5..3faddc6 100644
--- a/include/linux/sched/prio.h
+++ b/include/linux/sched/prio.h
@@ -25,6 +25,14 @@
#define DEFAULT_PRIO (MAX_RT_PRIO + NICE_WIDTH / 2)

/*
+ * SCHED_DEADLINE tasks has negative priorities, reflecting
+ * the fact that any of them has higher prio than RT and
+ * NORMAL/BATCH tasks.
+ */
+
+#define MAX_DL_PRIO 0
+
+/*
  * Convert user-nice values [ -20 ... 0 ... 19 ]
  * to static priority [ MAX_RT_PRIO..MAX_PRIO-1 ],
  * and back.
diff --git a/include/linux/sched/rt.h b/include/linux/sched/rt.h
index a30b172..062cddb 100644
--- a/include/linux/sched/rt.h
+++ b/include/linux/sched/rt.h
@@ -5,7 +5,7 @@

static inline int rt_prio(int prio)
{
- if (unlikely(prio < MAX_RT_PRIO))
+ if (unlikely(prio < MAX_RT_PRIO && prio > MAX_DL_PRIO))
  return 1;
  return 0;
} 

             reply	other threads:[~2016-08-25 11:35 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-25 11:29 Yin-goo Yim [this message]
2016-08-26  4:47 [PATCH] sched: Fix rt_task to work properly Andreas Mohr
     [not found] <1472186868308057.0.mail@mail>
2016-08-29 19:08 ` Yin-goo Yim

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=1472124612156711.0.mail@mail \
    --to=ygyim@konkuk.ac.kr \
    --cc=jinh@konkuk.ac.kr \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=tj@kernel.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).