Does the Linux Scheduler Prefer to Run Child Process After Fork()

Does the Linux scheduler prefer to run child process after fork()?

To quote The Linux Programming Interface (pg. 525) for a general answer:

After a fork(), it is indeterminate which process - the parent or the child - next has access to the CPU. (On a multiprocessor system, they may both simultaneously get access to a CPU.)

The book goes on about the differences in kernel versions and also mentions CFS / Linux 2.6.32:

[...] since Linux 2.6.32, it is once more the parent that is, by default, run first after a fork(). This default can be changed by assigning a nonzero value to the Linux-specific /proc/sys/kernel/sched_child_runs_first file.

This behaviour is still present with CFS although there are some concerns for the future of this feature. Looking at the CFS implementation, it seems to schedule the parent before the child.

The way to go for you would be to set /proc/sys/kernel/sched_child_runs_first to a non-zero value.

Edit: This answer analyzes the default behaviour and compares it to sched_child_runs_first.

Scheduling during child process creation

Ok I found the solution. There is this attribute called "sched_child_runs_first".
We can find this in the following path:

/proc/sys/kernel/sched_child_runs_first.

This value can be 0 or 1. This decides the scheduling sequence.

Scheduling Policy in an exec system call after a fork

Firstly, exec family of system calls does not executes it's own image rather it executes the binary it loads. As per man exec:

The exec() family of functions replaces the current process image with a new process image.

So, it'll behave how that particular executable image was prepared to be scheduled.

When a process it marked to be scheduled as SCHED_BATCH, they will be scheduled based on their nice values just like SCHED_OTHER. Since, batch tasks doesn't require user interaction therefore scheduler treats the task as CPU-intensive. As per man sched_setschedparam quote from SCHED_BATCH: Scheduling batch process -

This policy is similar to SCHED_OTHER in that it schedules the process according to its dynamic priority (based on the nice value).The difference is that this policy will cause the scheduler to always assume that the process is CPU-intensive. Consequently, the scheduler will apply a small scheduling penalty with respect to wakeup behaviour, so that this process is mildly disfavored in scheduling decisions.

Therefore, if you change a process's scheduling policy to SCHED_BATCH, it'll be scheduled just like almost any other normal processes (SCHED_OTHER, the default scheduling policy). If you want to fallback to the fully default behavior then you have to utilize SCHED_RESET_ON_FORK flag ORed with the scheduling policy. If you specify that flag, any newly created process will fallback to default scheduling policy rather copying parent's behavior.

Hope this helps!

Child process starts after parent process

The explanation is simple.
Scheduling of processes is up to the kernel. If this is a single core processor then in this run it decided to suspend the child execution and allow the parent process to run first. The parent ran for a few loops before being suspended in favor of the child, and so forth.

In a multiprocessor system both process can run in tandem but the console device will alternate the output depending on timing of interrupts.

There is no assurance a different run will result in the same output. There is also no assurance that different kernel version won't do something else.

If you want the processes to alternate between loops now is the time to learn interprocess communication.

---

Related Topics