Changing the policy of the init process at include/linux/init_task.h
worked! Although a lot of tasks asked to change the scheduler policy to
SCHED_NORMAL (and thus the scheduler class to CFS) through
sched_setscheduler(), so I had to add some code there to force the SCHED_RR
policy.

I made the priority of the tasks to be the same of the init process, so the
RT scheduler turned (I think) into a simple Round-Robin scheduler, as the
priority of almost all processes is the same. The only processes that had
higher priority were the ones that already runned using the RT scheduler
even when the CFS was being used.

The linux booted up okay, although I am not using a desktop environment, so
I don't know if it would boot up if it had XOrg.

What would I have to do if I instead wanted to change the scheduler class
that is used when a process specifies the SCHED_NORMAL policy? Is there a
way to do that without replacing the CFS source at fair.c?

Thanks.

Em ter, 24 de mai de 2016 ?s 12:22, Frederic Weisbecker [off-list ref]
escreveu:

(Sorry I forgot to Cc kernelnewbies, I fixed the Cc line).

On Tue, May 24, 2016 at 11:47:37AM +0000, Renato Utsch wrote:

quoted

Hi Frederic,

Thanks, this was exactly what I was looking for! I was suspecting that

all

quoted

the processes would inherit the policy of the init process, but I didn't
know where to look at. I'll take a look at this and see what happens.

By the way, how are the scheduler policies and the schedulers related?
Because the RT scheduler can be used with either SCHED_FIFO or SCHED_RR.
Are some policies linked to particular schedulers? If so, can I introduce
new SCHED_* constants? How should I do that if I want to call
sched_setscheduler() to change the policy to, say, SCHED_MY in an

userspace

quoted

program?

What you refer as "scheduler" is in fact a scheduler class.
So we have two different notions here: scheduler policy and scheduler
class.

_ The scheduler policy is set by the user or the system to tell how to
schedule a task.
  That's in the user interface level.

_ The scheduler classes handle the tasks scheduling differently on top of
their scheduler policy (driven
  by the user) or on top of kernel internal needs (idle_sched_class and
stop_sched_class).

  We have 4 of them, from lowest prio to highest:

     _ idle_sched_class = implement idle tasks. The idle tasks (one per
CPU)
                          are set with SCHED_NORMAL but the policy of idle
tasks are
                          not even checked.

     _ fair_sched_class = implement SCHED_NORMAL/SCHED_FAIR and SCHED_IDLE
(not to be confused
                          with idle tasks. In fact SCHED_IDLE tasks are
normal tasks that execute
                          when there is no SCHED_NORMAL tasks to run)

     _ rt_sched_class   = implement SCHED_RR and SCHED_FIFO

     _ dl_sched_class   = deadline realtime tasks (SCHED_DEADLINE)

     _ stop_sched_class = stop machine tasks. They don't refer to any
policy, the stop machine
                          tasks call sched_set_stop_task() to switch to
this class. Their policy
                          are SCHED_NORMAL but it's ignored.

   That's in the implementation level.

When the scheduler needs to choose the next task to run on the CPU, it
iterates each class
from highest prio to lower: (stop, dl, rt, fair, idle) and calls the
->pick_next_task()
callback for each of these classes. The first one that has a task to run
will have it on
the CPU. This is how class priorities are implemented.

So if you want to implement a new policy, the easiest is to create a new
scheduler class
but you'll need to decide where it fits between the classes prio.

Now when people talk about re-implementing the scheduler, they usually
mean the way to schedule
the SCHED_NORMAL tasks. If that's what you're interested in, I think you
rather want to rewrite
kernel/sched/fair.c and do your own fair_sched_class implementation.

Now kernel/sched/fair.c does a lot more than just implement
fair_sched_class so rewriting it the
way you like to experiment will be painful due to the links it has all
around in the core kernel.
Perhaps it's easier to create your own policy, define its prio between
idle_sched_class and
fair_sched_class then run your task under that policy on a CPU that
doesn't have any SCHED_NORMAL
tasks.

You can also set the init/0 task to your policy but there is no guarantee
it will propagate all
along recursively to the whole process tree as anything can override a
parent back to SCHED_NORMAL
at some point.

Thanks.

quoted

Em ter, 24 de mai de 2016 ?s 08:39, Frederic Weisbecker <

fweisbec at gmail.com>

quoted

escreveu:

quoted

Hi Renato,

What you're talking about is not exactly the scheduler but the

scheduler

quoted

quoted

policy. Basically the scheduler policy is inherited on fork(). The very
first task (init/0) is initialized with SCHED_NORMAL and this policy is
inherited recursively through all subsequent fork() calls as it is the

root

quoted

quoted

parent task. If you want all tasks in the system to inherit a

SCHED_FIFO

quoted

quoted

policy, you need to change the policy of init/0. This is probably

feasible

quoted

quoted

in include/linux/init_task.h (I can't check that right now). Now since
every task will have a real time policy, some of them may starve

others.

quoted

quoted

You may observe surprising behaviour,  your system could even fail to

boot.

quoted

quoted

Have fun.
Le 20 mai 2016 01:51, "Renato Utsch" [off-list ref] a ?crit :

quoted

Hello,

I am a new developer trying to learn how to tinker with the kernel. I
searched on the internet but couldn't find much info about this (and
couldn't find any info up to date).

My question is, how does the kernel decide which is the default

scheduler

quoted

quoted

quoted

that all processes start with? I can change the scheduler of a

process by

quoted

quoted

quoted

sched_setscheduler(), but how do I change *all* processes from using

the

quoted

quoted

quoted

CFS scheduler to, for example, the RR scheduler?

Sorry if this is too basic, but I don't know where to search for

this. If

quoted

quoted

quoted

you guys could point me places where I can learn more about this, I

would

quoted

quoted

quoted

be grateful.

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies at kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20160525/03c612c6/attachment-0001.html