Messages in this thread | | | From | "Yin-goo Yim" <> | Subject | Re: [PATCH] sched: Fix rt_task to work properly | Date | Tue, 30 Aug 2016 04:08:55 +0900 |
| |
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
| |