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?
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:
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
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.
Dig Deeper on Linux monitoring and troubleshooting
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.