Kernel thread scheduling

[xerofoify@gmail.com (nick)]

On 2015-04-11 11:02 PM, Ruben Safir wrote:
> On 04/11/2015 10:21 PM, Ruben Safir wrote:
>> On 04/10/2015 09:09 AM, nick wrote:
>>>
>>>
>>> On 2015-04-09 11:37 PM, Ruben Safir wrote:
>>>> On 04/09/2015 10:52 PM, nick wrote:
>>>>> Before asking questions again like this please look into either using lxr or ctags
>>>>> to navigate the kernel tree for answers as can be faster then waiting for me or 
>>>>> someone else to respond.
>>>>
>>>>
>>>> well, I reading the text is ctags aren't much value there.
>>>>
>>> Ctags is useful for searching the code, which is why I am recommending it.
>>> Nick
>>
>> I have it built into gvim, but you can't use it from a textbook.  I'm
>> finding it is not as useful as it could be for the kernel code.  There
>> are stacks of tags to get around.  Another 2 days to learn to get around
>> tags in vi is not in the agenda right now.  It is the tool I have so
>> I'll have to live with it right now.
>>
>> I also have a question that is not obvious from the code I'm looking at.
>>  I'm not sure how these structs are attached together.  Or more
>> specifically, I'm not sure how pulling the correct sched_entity gets one
>> the coresponding task_entity
>>
>> You have
>> struct task_struct with a
>> 	struct sched_entity
>>
>> struct sched_enitities are nodes in the RB tree
>> 	which are a "container" for "struct rb_node run_node".
>>
>> So a look at sched_entity ... is in ../linux/sched.h
>>
>> 1161 struct sched_entity {
>> 1162    struct load_weight   load;    /* for load-balancing */
>> 1163    struct rb_node    run_node;
>> 1164    struct list_head  group_node;
>> 1165    unsigned int      on_rq;
>> 1166
>> 1167    u64         exec_start;
>> 1168    u64         sum_exec_runtime;
>> 1169    u64         vruntime;
>> 1170    u64         prev_sum_exec_runtime;
>> 1171
>> 1172    u64         nr_migrations;
>> 1173
>> 1174 #ifdef CONFIG_SCHEDSTATS
>> 1175    struct sched_statistics statistics;
>> 1176 #endif
>> 1177
>> 1178 #ifdef CONFIG_FAIR_GROUP_SCHED
>> 1179    int         depth;
>> 1180    struct sched_entity  *parent;
>> 1181    /* rq on which this entity is (to be) queued: */
>> 1182    struct cfs_rq     *cfs_rq;
>> 1183    /* rq "owned" by this entity/group: */
>> 1184    struct cfs_rq     *my_q;
>> 1185 #endif
>> 1186
>> 1187 #ifdef CONFIG_SMP
>> 1188    /* Per-entity load-tracking */
>> 1189    struct sched_avg  avg;
>> 1190 #endif
>> 1191 };
>>
>> I see no means of referencing a specific task from this struct that
>> forms the node.  So when you pull the node with the smallest vruntime
>> from the left most postion of the RB tree, by calling pick_next_task(),
>>
>>
>> static struct sched_entity *__pick_next_entity(struct sched_entity *se)
>> {
>> 	struct rb_node *next = rb_next(&se->run_node);
This finds the next node in the red black tree for  sched_enities.
Basically rb_next finds the next node in the tree. The argument is 
the rb_node structure embedded in the structure using a red black
tree.
>>
>> 	if (!next)
>> 		return NULL;
>>
If there is no runnable task return NULL and pick_next_task will run the 
idle_task for this cpu.
>> 	return rb_entry(next, struct sched_entity, run_node);
>> }
>>
>>
>> how do we know what task we are attached to?
>>
Also try to read Chapter 6 of Linux Kernel Development as if have read that
chapter understanding how red black trees and other data structures work in
kernel code would make more sense.
Nick
>> Ruben
>>
>>
> 
> I'm still loss on how we know which taks_struct is being used but as a
> side note, I found this also very puzzling
> 
> return rb_entry(next, struct sched_entity, run_node);
> With help I ran it down to this:
> 
> http://lxr.free-electrons.com/source/include/linux/rbtree.h#L50
> 
> #define rb_entry(ptr, type, member) container_of(ptr, type, member)
> 
> which leads me to yet another macro
> 
> 798 #define container_of(ptr, type, member) ({                      \
> 799         const typeof( ((type *)0)->member ) *__mptr = (ptr);    \
> 800         (type *)( (char *)__mptr - offsetof(type,member) );})
> 
> 
> This is a use of macros I'd never seen before up close.  If anyone could
> help me understand it, I'd appreciate it.
> 
> Ruben
>>
>>
>>>> _______________________________________________
>>>> Kernelnewbies mailing list
>>>> Kernelnewbies at kernelnewbies.org
>>>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>>>>
>>>
>>>
>>
>>
>> _______________________________________________
>> Kernelnewbies mailing list
>> Kernelnewbies at kernelnewbies.org
>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>>
>>
> 
> 
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>