Question

At first glance, my question might look bit trivial. Please bear with me and read completely.

I have identified a busy loop in my Linux kernel module. Due to this, other processes (e.g. sshd) are not getting CPU time for long spans of time (like 20 seconds). This is understandable as my machine has only single CPU and busy loop is not giving chance to schedule other processes.

Just to experiment, I had added schedule() after each iteration in the busy loop. Even though, this would be keeping the CPU busy, it should still let other processes run as I am calling schedule(). But, this doesn’t seem to be happening. My user level processes are still hanging for long spans of time (20 seconds).

In this case, the kernel thread got nice value -5 and user level threads got nice value 0. Even with low priority of user level thread, I think 20 seconds is too long to not get CPU.

Can someone please explain why this could be happening?

Note: I know how to remove busy loop completely. But, I want to understand the behaviour of kernel here. Kernel version is 2.6.18 and kernel pre-emption is disabled.

Answer 1

The schedule() function simply invokes the scheduler – it doesn’t take any special measures to arrange that the calling thread will be replaced by a different one. If the current thread is still the highest priority one on the run queue then it will be selected by the scheduler once again.

It sounds as if your kernel thread is doing very little work in its busy loop and it’s calling schedule() every time round. Therefore, it’s probably not using much CPU time itself and hence doesn’t have its priority reduced much. Negative nice values carry heavier weight than positives, so the difference between a -5 and a 0 is quite pronounced. The combination of these two effects means I’m not too surprised that user space processes miss out.

As an experiment you could try calling the scheduler every Nth iteration of the loop (you’ll have to experiment to find a good value of N for your platform) and see if the situation is better – calling schedule() too often will just waste lots of CPU time in the scheduler. Of course, this is just an experiment – as you have already pointed out, avoiding busy loops is the correct option in production code, and if you want to be sure your thread is replaced by another then set it to be TASK_INTERRUPTIBLE before calling schedule() to remote itself from the run queue (as has already been mentioned in comments).

Note that your kernel (2.6.18) is using the O(1) scheduler which existed until the Completely Fair Scheduler was added in 2.6.23 (the O(1) scheduler having been added in 2.6 to replace the even older O(n) scheduler). The CFS doesn’t use run queues and works in a different way, so you might well see different behaviour – I’m less familiar with it, however, so I wouldn’t like to predict exactly what differences you’d see. I’ve seen enough of it to know that “completely fair” isn’t the term I’d use on heavily loaded SMP systems with a large number of both cores and processes, but I also accept that writing a scheduler is a very tricky task and it’s far from the worst I’ve seen, and I’ve never had a significant problem with it on a 4-8 core desktop machine.