Serious scheduler starvation
I'm reposting this, since I got no response last time.
First the machine details. It's a Pentium4 running at 2 GHz. Linux version 2.6.0-test3 + O16int + softrr.
I just experienced something that might be a scheduler problem. I was working in XEmacs, when suddenly the machine became very unresponsive. The mouse pointer in X moved sporadically. I could switch to a text console and log in, though typing lagged tens of seconds. Switching between text consoles was fast, though. I killed xemacs, and the system was back to normal. Further investigation showed that xemacs was stuck in a nasty regexp match. If I was quick enough, I could interrupt it with C-g.
With X and the window manager reniced to -10, they seem to be able to get their job done. This leads me to believe that maybe xemacs is considered interactive, and given too high priority when it suddenly starts burning the cpu.
I'll try it later with other kernel versions, but right now I don't want to reboot.
What can I do to collect more information about the problem?
Signature · 2 lines
Måns Rullgård [email protected]
Quoted 4 lines · Måns Rullgård
I'm reposting this, since I got no response last time.
First the machine details. It's a Pentium4 running at 2 GHz. Linux version 2.6.0-test3 + O16int + softrr.
Softrr ? Which patch? Davide's? Noone has tried to make them compatible (yet?). Even so, this may be unrelated to softrr.
Quoted 1 line
I just experienced something that might be a scheduler problem. I was
Almost certainly is.
Quoted 13 lines
working in XEmacs, when suddenly the machine became very unresponsive. The mouse pointer in X moved sporadically. I could switch to a text console and log in, though typing lagged tens of seconds. Switching between text consoles was fast, though. I killed xemacs, and the system was back to normal. Further investigation showed that xemacs was stuck in a nasty regexp match. If I was quick enough, I could interrupt it with C-g.
With X and the window manager reniced to -10, they seem to be able to get their job done. This leads me to believe that maybe xemacs is considered interactive, and given too high priority when it suddenly starts burning the cpu.
Quoted 4 lines
I'll try it later with other kernel versions, but right now I don't want to reboot.
What can I do to collect more information about the problem?
Run top in batch mode as root reniced to -11 so it doesn't get preempted and capture it happening before you kill XEmacs. Then try running XEmacs niced +10 and see if it doesn't happen there. Also if it was lucky enough that you booted with profiling enabled you could profile it, but top will tell if it's a simple scheduler starvation error.
Con
Quoted 5 lines · Con Kolivas
Quoted 2 lines
First the machine details. It's a Pentium4 running at 2 GHz. Linux version 2.6.0-test3 + O16int + softrr.
Softrr ? Which patch? Davide's? Noone has tried to make them compatible (yet?). Even so, this may be unrelated to softrr.
Are there more than one. I'm using something off xmailserver.org. Anyhow, no softrr tasks were running at the time.
Quoted 7 lines
Quoted 1 line
What can I do to collect more information about the problem?
Run top in batch mode as root reniced to -11 so it doesn't get preempted and capture it happening before you kill XEmacs. Then try running XEmacs niced +10 and see if it doesn't happen there. Also if it was lucky enough that you booted with profiling enabled you could profile it, but top will tell if it's a simple scheduler starvation error.
I'll do that, it's easily reproducible, at least.
Signature · 2 lines
Måns Rullgård [email protected]
Quoted 6 lines · Con Kolivas
Quoted 2 lines · Måns Rullgård
First the machine details. It's a Pentium4 running at 2 GHz. Linux version 2.6.0-test3 + O16int + softrr.
Softrr ? Which patch? Davide's? Noone has tried to make them compatible (yet?). Even so, this may be unrelated to softrr.
Almost certainly unrelated, since there is no effect unless he runs SCHED_RR applications as non-root.
Obviously, he should back the patches out one by one when he does get time to reboot.
Regards,
Daniel
Quoted 5 lines · Daniel Phillips
Quoted 4 lines · Con Kolivas
Quoted 2 lines · Måns Rullgård
First the machine details. It's a Pentium4 running at 2 GHz. Linux version 2.6.0-test3 + O16int + softrr.
Quoted 8 lines
Quoted 2 lines
Softrr ? Which patch? Davide's? Noone has tried to make them compatible (yet?). Even so, this may be unrelated to softrr.
Almost certainly unrelated, since there is no effect unless he runs
SCHED_RRapplications as non-root.Obviously, he should back the patches out one by one when he does get time to reboot.
No need, there is a known issue in my patches that can cause it. Check the email I just sent about a similar issue.
Con
Quoted 1 line · Måns Rullgård
What can I do to collect more information about the problem?
Look in top's "PRI" column, which is where you see the effects of the dynamic priority adjustment.
Regards,
Daniel