了解rt_rq(实时运行队列)内核中数据成员的使用

问题描述

以下是v3.5.4中的实时运行队列结构

struct rt_rq {
        struct rt_prio_array active;
        unsigned int rt_nr_running;
#if defined CONFIG_SMP || defined CONFIG_RT_GROUP_SCHED
        struct {
                int curr; /* highest queued rt task prio */
#ifdef CONFIG_SMP
                int next; /* next highest */
#endif
        } highest_prio;
#endif
#ifdef CONFIG_SMP
        unsigned long rt_nr_migratory;
        unsigned long rt_nr_total;
        int overloaded;
        struct plist_head pushable_tasks;
#endif
        int rt_throttled;
        u64 rt_time;
        u64 rt_runtime;
        /* Nests inside the rq lock: */
        raw_spinlock_t rt_runtime_lock;

#ifdef CONFIG_RT_GROUP_SCHED
        unsigned long rt_nr_boosted;

        struct rq *rq;
        struct list_head leaf_rt_rq_list;
        struct task_group *tg;
 #endif
};

我已经理解了某些数据成员的含义，但是我不确定以下数据成员的含义:

a)rt_nr_migratory :(我认为)这是一个计数器，用于统计可以将多少个任务推送到其他cpu的计数

b)pushable_tasks是任务列表，如果没有任何要运行的任务，可以将这些任务推入其他运行队列.

如果我对以上输入内容有误，请纠正我.

c)rt_throttled，rt_time，rt_runtime，rt_nr_total，rt_nr_boosted:我不知道这有什么用.

为什么只有在有组调度的情况下才需要struct rq *rq;.我的意思是它的意义是什么.

解决方案

这是一个很难回答的问题，部分原因是它一次确实是六个复杂的问题.因此，为了帮助您理解所有这些内容，我查找了添加这些字段中的每个字段时的情况.阅读提交消息以及可能引入每个字段的补丁程序应该使您更加了解它们为什么存在.

rt_nr_migratory已添加到提交计划:添加RT平衡CPU权重.

pushable_tasks已添加到提交预定:创建"pushable_tasks"列表以将推送限制为一次尝试.

在提交预定:rt时间限制.

rt_runtime已添加到提交预定:rt-group:smp平衡.

rt_nr_total已添加到提交 sched_rt:修复了rt组计划中的重载错误.

rt_nr_boosted已添加到提交预定:rt-group:处理PI . (我相信"PI"在这里表示优先级倒置".)

rq已添加到提交预定:rt组预定.

---

我使用git blame来确定何时引入每行，但是在这种情况下，这非常复杂，因为自从完成所有这些工作以来，调度程序源代码已经经历了两次主要重组.因此，当我使用git blame sched.h时，它告诉我整个结构是一次全部添加的，但是它命名的提交实际上是将结构移出sched.c的时间.然后，我使用git blame <commit>~ -- sched.c来查看更改之前sched.c的外观.最后，对于我认为可能重要的每次提交，我都使用git show <commit>进行了仔细检查.

The following is the real time run queue structure in v3.5.4

struct rt_rq {
        struct rt_prio_array active;
        unsigned int rt_nr_running;
#if defined CONFIG_SMP || defined CONFIG_RT_GROUP_SCHED
        struct {
                int curr; /* highest queued rt task prio */
#ifdef CONFIG_SMP
                int next; /* next highest */
#endif
        } highest_prio;
#endif
#ifdef CONFIG_SMP
        unsigned long rt_nr_migratory;
        unsigned long rt_nr_total;
        int overloaded;
        struct plist_head pushable_tasks;
#endif
        int rt_throttled;
        u64 rt_time;
        u64 rt_runtime;
        /* Nests inside the rq lock: */
        raw_spinlock_t rt_runtime_lock;

#ifdef CONFIG_RT_GROUP_SCHED
        unsigned long rt_nr_boosted;

        struct rq *rq;
        struct list_head leaf_rt_rq_list;
        struct task_group *tg;
 #endif
};

I have understood what does some data members stand for but I am not completely sure for the following data members:

a) rt_nr_migratory : (I think that) it is a counter to keep count of how many tasks can be pushed to other cpu's

b) pushable_tasks is the list of tasks which can be pushed to other run queues if they do not have anything to run.

Please correct me if I am wrong for the above entries.

c) rt_throttled, rt_time, rt_runtime, rt_nr_total, rt_nr_boosted : I do not understand what is the use of this.

Also why is struct rq *rq; only required when group scheduling is there. I mean what is its significance.

解决方案

This is a difficult question to answer, partly because it's really a half-dozen complicated questions at once. So to help you understand each of these pieces, I've looked up when each of those fields was added. Reading the commit message and possibly the patch that introduced each field should get you much closer to understanding why they're there.

rt_nr_migratory was added in commit sched: add RT-balance cpu-weight.

pushable_tasks was added in commit sched: create "pushable_tasks" list to limit pushing to one attempt.

rt_throttled and rt_time were added in commit sched: rt time limit.

rt_runtime was added in commit sched: rt-group: smp balancing.

rt_nr_total was added in commit sched_rt: Fix overload bug on rt group scheduling.

rt_nr_boosted was added in commit sched: rt-group: deal with PI. (I believe "PI" here means "priority inversion".)

rq was added in commit sched: rt group scheduling.

---

I used git blame to find out when each line was introduced, but it was pretty complicated in this case because the scheduler source code has gone through two major reorganizations since all this work was done. So when I used git blame sched.h, it told me that that the whole structure was added all at once, but the commit it named was actually when the structure was moved out of sched.c. Then I used git blame <commit>~ -- sched.c to see what sched.c looked like before that change. Finally, for each commit that I thought might matter, I double-checked using git show <commit>.

这篇关于了解rt_rq(实时运行队列)内核中数据成员的使用的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！