From: "Yin-goo Yim" <ygyim@konkuk.ac.kr>
To: "Andreas Mohr" <andi@lisas.de>
Cc: "Dongsheng Yang" <yangds.fnst@cn.fujitsu.com>,
"Thomas Gleixner" <tglx@linutronix.de>,
<linux-kernel@vger.kernel.org>, <mingo@redhat.com>,
<peterz@infradead.org>, <torvalds@linux-foundation.org>,
<jinh@konkuk.ac.kr>
Subject: Re: [PATCH] sched: Fix rt_task to work properly
Date: Tue, 30 Aug 2016 04:08:55 +0900 [thread overview]
Message-ID: <1472497740717843.0.mail@mail> (raw)
In-Reply-To: <1472186868308057.0.mail@mail>
Thank you for your immediate response.
> AFAICS this change is a larger layer violation (dependency issue)
> since AFAIK prio.h is a generic, common base header
> which is to provide priority definitions
> common to *all* of the
> more specific scheduler sub handling
> (deadline, rt, ...),
> which thus should not have to aggregate
> any specific knowledge whatsoever about
> various scheduler sub type specific handling.
We agree that the prio.h file has to be generic, but we thought that adding
the priority information of deadline scheduler (i.e., #define MAX_DL_PRIO 0)
to this file should be fine, because prio.h already has the priority
information for cfs and rt schedulers (i.e., MAX_PRIO and MAX_RT_PRIO).
> rt_prio() quite likely is to be seen as an *rt-specific* API
> since it is defined in the *rt-specific* rt.h header.
> IOW, rt_prio() is *not to be used* for any areas where we
> do not have an RT case
> (quite certainly header docs should be added to rt_prio()
> to definitely emphasize this fact,
> maybe something like
> "Note that since this is an RT API it is meaningful for RT tasks only").
The rt_prio() function returns 1 or 0 according to whether or not the
corresponding process is an rt task. Thus, we believe that rt_prio() is a
suitable function to determine if a task is rt one, and can be called even
for non-rt tasks. Indeed we can easily find examples where
rt_prio()/rt_task() is called for an arbitrary process without limiting to
rt tasks (e.g., sched_fork()).
Though our initial intention was to fix the origin of the problem, if you/we
are not convinced of our patch due to dependency issues, we can reinforce
the conditional statement in tg_has_rt_tasks() by adding !dl_task(p) as
follows:
if (!dl_task(p) && rt_task(p) && task_group(p) == tg)
In this manner, we can avoid modifying the header files in
include/linux/sched/, while having the same effect with respect to cgroup.
Thanks,
Yin-goo Yim
next parent reply other threads:[~2016-08-29 19:09 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1472186868308057.0.mail@mail>
2016-08-29 19:08 ` Yin-goo Yim [this message]
2016-08-26 4:47 [PATCH] sched: Fix rt_task to work properly Andreas Mohr
-- strict thread matches above, loose matches on Subject: below --
2016-08-25 11:29 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=1472497740717843.0.mail@mail \
--to=ygyim@konkuk.ac.kr \
--cc=andi@lisas.de \
--cc=jinh@konkuk.ac.kr \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=yangds.fnst@cn.fujitsu.com \
/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.