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);
>
> if (!next)
> return NULL;
>
> return rb_entry(next, struct sched_entity, run_node);
> }
>
>
> how do we know what task we are attached to?
>
> 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@xxxxxxxxxxxxxxxxx
>>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>>>
>>
>>
>
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies@xxxxxxxxxxxxxxxxx
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
>
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@xxxxxxxxxxxxxxxxx
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
