Trouble with the scheduler in RHEL 2.6; changing the process priority

I recently upgraded to 2.6 kernels on various machines, and the following happens:

I go to 'rm -rf foo,' realize that the directory foo is HUGE (50+GB), hit ctr-z, and try to background it in an effort to move on with my life.

Under 2.4, the process would suspend immediately, background immediately, and the interactive response was perfect (IMHO).

Under 2.6, I hit ctr-z, and nothing happens for up to 30 seconds.

Eventually the process suspends, and then I can background it, but it's totally unnerving. It makes me feel like I'm using Windows.

Is this a real change in 2.6, or am I doing something wrong? Did the scheduler change between 2.4 and 2.6?

    Requires Free Membership to View

    Login

I must say I am a little stumped on this one, but I think you are right to be looking at scheduling as the issue. My suggestion would be to run the rm process with the highest priority to see if that makes a difference. You can try this just to see if that is the issue:

First, after starting the "rm –rf foo" comman, grep for the rm process:

ps –aux | grep rm

This should give you a response that looks something like the second line (the first line is just the identification of columns):

USER PID %CPU %MEM  VSZ  RSS TTY STAT START TIME COMMAND
root 1335 0.0 0.1 1684 544 ?  S  Jun12 0:06 rm

You can then set the priority of the process to the top priority which is quantified by a number between -20 and 19 where -20 is the highest priority. You can do this using the renice command, which is issued by entering the following command:

 renice -20 1335

The renice command is followed by the priority and the last number is the Process ID (PID) that was returned from the example above.

This should set that process with the highest priority and perhaps speed up your removal of the large directory. I really can't speak to why the process is slower since you updated to kernel 2.6. The difference as I understand it is that the Linux 2.6 kernel no longer includes the same process scheduler that was used under kernel 2.4 -- which used algorithms to determine task importance and then ran the task. The scheduler in 2.6 sorts tasks in a "ready-to-run" queue and then chooses the most favorable task to run the process. This difference may account for the disparately in performance but I am not familiar enough to make a complete diagnosis.

For more information:
Kenneth Milberg provides another answer to this question about issues with the scheduler in 2.6.

This was first published in June 2005

Join the conversationComment

Share
Comments

    Results

    Contribute to the conversation

    All fields are required. Comments will appear at the bottom of the article.
    Back to top