6

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.

Aman Deep Gautam
  • 8,091
  • 21
  • 74
  • 130

1 Answers1

10

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

Jamey Sharp
  • 8,363
  • 2
  • 29
  • 42
  • 2
    though this is unrelated but can you tell me how to find such commit messages or a tutorial for such a thing, it will be very helpful. I mean how did you find out these links. – Aman Deep Gautam Nov 06 '12 at 10:12
  • 2
    That's not unrelated; I should probably have included notes on how I answered the question to begin with. Done! – Jamey Sharp Nov 06 '12 at 16:00
  • 1
    Excellent mini-tutorial on how to use `git blame` to take a quick peek at how a file looked prior to a change. What does the `--` do specifically? I see that it works without the `--` as well... – TheCodeArtist Jun 02 '15 at 11:29
  • 2
    `--` here ensures that the argument before is treated as a commit hash, and the argument after is treated as a filename. Otherwise, git will often try to guess whether the argument is a commit or filename, and if you have both a file and a branch with the same name it may guess wrong. Often this doesn't make any difference, but it's a good habit to get into. – Jamey Sharp Jun 07 '15 at 04:54