That is written by my friend GREG!! I know Greg. I've had many beers with Greg. Ruben On Sun, Apr 12, 2015 at 04:36:53AM +0000, Mohammed Ghriga wrote: > In addition to the suggestions that were offered, I recommend you try reading Chapter 16: https://www.google.com/search?tbo=p&tbm=bks&q=isbn:0596554672 (pages: 267-272). > > > -----Original Message----- > From: nick [mailto:xerofoify@xxxxxxxxx] > Sent: Sunday, April 12, 2015 12:16 AM > To: Ruben Safir; kernelnewbies@xxxxxxxxxxxxxxxxx; Mohammed Ghriga > Subject: Re: Kernel thread scheduling > > > > 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@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 > > -- So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998 http://www.mrbrklyn.com DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002 http://www.nylxs.com - Leadership Development in Free Software http://www2.mrbrklyn.com/resources - Unpublished Archive http://www.coinhangout.com - coins! http://www.brooklyn-living.com Being so tracked is for FARM ANIMALS and and extermination camps, but incompatible with living as a free human being. -RI Safir 2013 _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
