Ingo Molnar wrote:* Al Boldi <a1426z@xxxxxxxxx> wrote:ok. I think i might finally have found the bug causing this. Could youOf course, things should get slower with higher load, but it should beThe problem is that consecutive runs don't give consistent resultswell, there's a natural saturation point after a few hundred tasks
and sometimes stalls. You may want to try that.
(depending on your CPU's speed), at which point there's no idle time
left. From that point on things get slower progressively (and the
ability of the shell to start new ping tasks is impacted as well),
but that's expected on an overloaded system, isnt it?
consistent without stalls.
To see this problem, make sure you boot into /bin/sh with the normal
VGA console (ie. not fb-console). Then try each loop a few times to
show different behaviour; loops like:
# for ((i=0; i<3333; i++)); do ping 10.1 -A > /dev/null & done
# for ((i=0; i<3333; i++)); do nice -99 ping 10.1 -A > /dev/null & done
# { for ((i=0; i<3333; i++)); do
ping 10.1 -A > /dev/null &
done } > /dev/null 2>&1
Especially the last one sometimes causes a complete console lock-up,
while the other two sometimes stall then surge periodically.
try the fix below, does your webserver thread-startup test work any
better?
It seems to help somewhat, but the problem is still visible. Even v20.3 on 2.6.22.5 didn't help.
It does look related to ia-boosting, so I turned off __update_curr like Roman mentioned, which had an enormous smoothing effect, but then nice levels completely break down and lockup the system.
There is another way to show the problem visually under X (vesa-driver), by starting 3 gears simultaneously, which after laying them out side-by-side need some settling time before smoothing out. Without __update_curr it's absolutely smooth from the start.