Kernel Tuning: kernel.sched_child_runs_first

So, to kick start the Linux Kernel Tuning series I appear to have embarked on, first on the list is the kernel tunable parameter – kernel.sched_child_runs_first.

Disclaimer – see bottom of page.

The not so important disclaimer.  Basically, I have limited knowledge of C/C++ and therefore I am relying purely on third party information to provide the below.  So if you spot an inaccuracy let me know.

What is it for?

The idea behind the kernel.sched_child_runs_first parameter is that there may be times where a process (the parent)  will spawn a (number of) child process(es).  In this scenario it is likely that the child process(es) are the ones doing the actual grunt work and that the parent process is potentially just over seeing the running of the child processes.

The purpose of this variable is to set a preference that if at all possible, the child process should be run before the parent.  The thinking is that this could shave some processing time off of the overall total.

  • If you are running particularly low latency applications you could see a benefit by running the child before the parent.
  • If you are developing with or your application uses vfork then this is the default behaviour and therefore this configurable is not applicable

Why you should not change!

  •  According to the following thread there has historically been evidence of issues/bugs in bash when this sched_child_runs_first has been enabled.

Applies to: RHEL 6

Default Value: 0

Possible Values: 0 | 1

Related to: CFS (Completely Fair Scheduler).

Disclaimer:  Any changes to kernel parameters should be fully tested in a test environment or a “production like” lab environment, and you should always be certain that the changes you have made are recorded so that you can attempt to backout of the change.

Reference material;


2 thoughts on “Kernel Tuning: kernel.sched_child_runs_first

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.