lkml.org 
[lkml]   [2002]   [Nov]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [BENCHMARK] 2.5.46-mm1 with contest
From
  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)


[unhandled content-type:application/octet-stream]
\
 
 \ /
  Last update: 2005-03-22 13:30    [W:0.037 / U:0.492 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site