Ok, it just happened again. Everything got slow, changing desktops,
starting new aterms,. etc. I flipped to a tty, and started a vmstat
log,
and went back into X, and reprioritised stuff with a terminal that was
just bearably slow enough to work. After renicing X stuff got a bit
better. A little. After renicing my aterms, it got slightly better
still.
alan@aries:~$ sudo renice -19 `pgrep X`
499: old priority 0, new priority -19
alan@aries:~$ sudo renice -19 `pgrep aterm`
686: old priority 0, new priority -19
818: old priority 0, new priority -19
1030: old priority 0, new priority -19
1130: old priority 0, new priority -19
1202: old priority 0, new priority -19
1691: old priority 0, new priority -19
1762: old priority 0, new priority -19
2013: old priority 0, new priority -19
2164: old priority 0, new priority -19
2281: old priority 0, new priority -19
2406: old priority 0, new priority -19
2490: old priority 0, new priority -19
2558: old priority 0, new priority -19
2559: old priority 0, new priority -19
2838: old priority 0, new priority -19
3050: old priority 0, new priority -19
3056: old priority 0, new priority -19
3158: old priority 0, new priority -19
After flipping back to my vmstat log tty, I found that vmstat had
segfaulted instead of run, I didnt see it because I ran it in the
background and ran a tail of the file it was supposed to log to. I'm
using procps 2.0.7 as distributed in RH8.0, which I assume is too old a
version. I attached an strace of it running if anyone is curious.
To give an example ofhow intermitently slow this is, I took one of my
reniced aterms, and tried running aterm with the options I usually use.
I started another instance of aterm elsewhere, and in my current terminal,
I ran the following:
alan@aries:~$ time /usr/local/bin/aterm -tr -trsb -fade 60 -bg blue -fg -e
exit
real 0m0.924s
user 0m0.017s
sys 0m0.014s
alan@aries:~$ time /usr/local/bin/aterm -tr -trsb -fade 60 -bg blue -fg -e
exit
real 0m4.895s
user 0m0.018s
sys 0m0.018s
alan@aries:~$ time /usr/local/bin/aterm -tr -trsb -fade 60 -bg blue -fg -e
exit
real 0m1.436s
user 0m0.014s
sys 0m0.018s
alan@aries:~$ time /usr/local/bin/aterm -tr -trsb -fade 60 -bg blue -fg -e
exit
real 0m0.797s
user 0m0.017s
sys 0m0.017s
alan@aries:~$ time /usr/local/bin/aterm -tr -trsb -fade 60 -bg blue -fg -e
exit
real 0m1.122s
user 0m0.017s
sys 0m0.019s
I had enough time to run aterm this way about four times before I got
that other instance of aterm to give me a usable prompt.
I'll go upgrade my procps so I have a working vmstat for you next time,
sorry about that. Whose shall I use? (riel/rml or calahan, or both?)
-alan
> Alan Willis wrote:
>>
>> > Why? We are preempting during the generic file write/read routines,
>> I bet, which can otherwise be long periods of latency. CPU is up
>> and I bet the throughput is down, but his test is getting the
>> attention it wants.
>>
>> I'm curious, would running contest after a fresh boot and with
>> profile=2
>> provide a profile that tells exactly where time is being spent? Since
>> about 2.5.45 I've had some strange slow periods, and starting aterm
>> would take a while, redrawing windows in X would slow down, it 'feels'
>> like my workstation becomes a laptop that is just waking up.
>> Sometimes this is after only a few minutes of inactivity, or after
>> switching virtual desktops in kde, or when I have alot of aterm
>> instances running.
>
> - Run `vmstat 1', and see if the slowdowns coincide with any unusual
> IO activity.
>
> - Could be the scheduler. Try
> renice -19 $(pidof X) $(pidof aterm) $(pidof other stuff)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Nov 15 2002 - 22:00:16 EST