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 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).