Re: Kernel thread scheduling

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux