kernel: BUG: soft lockup – CPU#0 stuck for 67s!

Over the weekend I was confronted by the above error being repeated on the console of a VM running Oracle RDBMS.

This error occurs when there is a shortage of CPU resources.  For me the solution was a quick shut down of the VM and increasing the available CPU resources.  However there are more ways to skin this cat…

There is also a kernel parameter which can be tweaked;


Were “x” is the threshold (in seconds) you want to allow the kernel to wait before decided there has been a soft lockup.

The Red Hat documentation showed a threshold of 30 seconds.  So I would recommend a bit of experimentation if you feel that 30 seconds is not high enough.  Or throw more resources at it.

Reference Material

Featured image: The Old Lockup was made available by John Powell on Flickr.

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.