All of lore.kernel.org
 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]
  -- strict thread matches above, loose matches on Subject: below --
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 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.