From mboxrd@z Thu Jan 1 00:00:00 1970 From: xerofoify@gmail.com (nick) Date: Sun, 12 Apr 2015 00:16:01 -0400 Subject: Kernel thread scheduling In-Reply-To: <5529E051.5080506@mrbrklyn.com> References: <20150320231955.GA5713@vinc94-desktop> <4E5779AD88B2F040B8A7E83ECF544D1A5C7240@SJCPEX01CL03.citrite.net> <508921156.2279151.1426919611846.JavaMail.yahoo@mail.yahoo.com> <20150322231449.GA3235@vinc94-desktop> <550F509A.9030207@gmail.com> <550F58E3.1080500@mrbrklyn.com> <550F5FDD.7090602@gmail.com> <55272CA2.2090603@mrbrklyn.com> <55272EA8.7010908@gmail.com> <55273179.2030706@mrbrklyn.com> <55273AD3.1010000@gmail.com> <55274580.5070005@mrbrklyn.com> <5527CB72.1000401@gmail.com> <5529D69A.1020104@mrbrklyn.com> <5529E051.5080506@mrbrklyn.com> Message-ID: <5529F181.2090300@gmail.com> To: kernelnewbies@lists.kernelnewbies.org List-Id: kernelnewbies.lists.kernelnewbies.org 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 >