From: ruben@mrbrklyn.com (Ruben Safir)
To: kernelnewbies@lists.kernelnewbies.org
Subject: Kernel thread scheduling
Date: Sat, 11 Apr 2015 22:21:14 -0400 [thread overview]
Message-ID: <5529D69A.1020104@mrbrklyn.com> (raw)
In-Reply-To: <5527CB72.1000401@gmail.com>
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
>> _______________________________________________
>> Kernelnewbies mailing list
>> Kernelnewbies at kernelnewbies.org
>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>>
>
>
next prev parent reply other threads:[~2015-04-12 2:21 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-20 23:19 Kernel thread scheduling Vincenzo Scotti
2015-03-20 23:27 ` Jeff Haran
2015-03-21 6:33 ` Anand Moon
2015-03-22 23:14 ` Vincenzo Scotti
2015-03-22 23:30 ` nick
2015-03-23 0:05 ` Ruben Safir
2015-03-23 0:35 ` nick
2015-04-10 1:51 ` Ruben Safir
[not found] ` <55272EA8.7010908@gmail.com>
2015-04-10 2:12 ` Ruben Safir
2015-04-10 2:52 ` nick
2015-04-10 3:37 ` Ruben Safir
[not found] ` <5527CB72.1000401@gmail.com>
2015-04-12 2:21 ` Ruben Safir [this message]
2015-04-12 3:02 ` Ruben Safir
2015-04-12 4:16 ` nick
2015-04-12 4:53 ` Ruben Safir
[not found] ` <A2417C6E7F04A0438F09C31B33A6BE8B01D9CE3BE7@B-EXH-MBX2.liunet.edu>
2015-04-12 5:06 ` Ruben Safir
2015-04-13 3:21 ` nick
2015-04-17 13:10 ` Ruben Safir
2015-04-17 13:14 ` Ruben Safir
2015-04-16 14:56 ` Ruben Safir
2015-04-16 15:07 ` Ricardo Ribalda Delgado
2015-04-16 15:11 ` Ruben Safir
2015-04-16 15:12 ` Ruben Safir
2015-04-16 15:51 ` Ricardo Ribalda Delgado
2015-04-16 15:10 ` Aruna Hewapathirane
2015-04-16 15:37 ` Ruben Safir
2015-04-16 15:11 ` Mark P
2015-04-16 16:31 ` Jeff Haran
2015-04-16 17:08 ` Ruben Safir
2015-04-16 17:34 ` Jeff Haran
2015-04-16 18:28 ` Ruben Safir
2015-04-16 18:47 ` Valdis.Kletnieks at vt.edu
2015-04-16 21:41 ` Jeff Haran
2015-04-17 7:45 ` Silvan Jegen
2015-04-17 8:50 ` Ruben Safir
2015-04-16 23:05 ` Ruben Safir
2015-04-16 18:32 ` John de la Garza
2015-04-16 18:38 ` Ruben Safir
2015-04-16 18:42 ` Ruben Safir
2015-04-16 19:43 ` Silvan Jegen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5529D69A.1020104@mrbrklyn.com \
--to=ruben@mrbrklyn.com \
--cc=kernelnewbies@lists.kernelnewbies.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).