(Please CC me your answers, thank you)
I'm seeing serious interactivity problems in 2.5.65, 2.5.66, 2.5.65-mm4
and 2.5.64-bk2.
I couldn't reproduce it on 2.5.64, 2.5.64-bk1.
I noticed that when I was archiving a directory with some CD ISO images
with tar & bzip2. After a while (~5 minutes) many programs took a long
time to respond, XMMS paused for several seconds, starting simple
programs (mc, ps, ls) took sometimes even 40s. Disk is idle most of the
time.
To reproduce I wrote a simple script:
#!/bin/sh
cat cedo.iso | bzip2 > /tmp/cedo.iso.bz2 &
for i in `seq 1 20`; do
sleep 30
date
ps x
date
echo -----
done
... where cedo.iso is a 700MB CD ISO image.
When run on 2.5.64-bk2 (and no X running) I've got this output:
Wed Mar 26 10:47:50 CET 2003
PID TTY STAT TIME COMMAND
325 tty2 S 0:00 -bash
713 tty2 R 0:00 /bin/sh ./test-interactivity.sh
714 tty2 R 0:00 tee inter-2.5.64bk2.log
715 tty2 S 0:00 cat cedo.iso
716 tty2 R 0:33 bzip2
720 tty2 R 0:00 ps x
Wed Mar 26 10:47:50 CET 2003
-----
Wed Mar 26 10:48:22 CET 2003
PID TTY STAT TIME COMMAND
325 tty2 S 0:00 -bash
713 tty2 S 0:00 /bin/sh ./test-interactivity.sh
714 tty2 S 0:00 tee inter-2.5.64bk2.log
715 tty2 S 0:00 cat cedo.iso
716 tty2 R 1:05 bzip2
724 tty2 R 0:00 ps x
Wed Mar 26 10:48:23 CET 2003
-----
Wed Mar 26 10:48:55 CET 2003
PID TTY STAT TIME COMMAND
325 tty2 S 0:00 -bash
713 tty2 S 0:00 /bin/sh ./test-interactivity.sh
714 tty2 S 0:00 tee inter-2.5.64bk2.log
715 tty2 S 0:00 cat cedo.iso
716 tty2 R 1:38 bzip2
728 tty2 R 0:00 ps x
Wed Mar 26 10:48:55 CET 2003
-----
Wed Mar 26 10:49:28 CET 2003
PID TTY STAT TIME COMMAND
325 tty2 S 0:00 -bash
713 tty2 R 0:00 /bin/sh ./test-interactivity.sh
714 tty2 S 0:00 tee inter-2.5.64bk2.log
715 tty2 S 0:00 cat cedo.iso
716 tty2 R 2:10 bzip2
732 tty2 R 0:00 ps x
Wed Mar 26 10:49:28 CET 2003
-----
Wed Mar 26 10:50:01 CET 2003
PID TTY STAT TIME COMMAND
325 tty2 S 0:00 -bash
713 tty2 S 0:00 /bin/sh ./test-interactivity.sh
714 tty2 S 0:00 tee inter-2.5.64bk2.log
715 tty2 S 0:00 cat cedo.iso
716 tty2 R 2:42 bzip2
736 tty2 R 0:00 ps x
Wed Mar 26 10:50:01 CET 2003
-----
Wed Mar 26 10:50:34 CET 2003
PID TTY STAT TIME COMMAND
325 tty2 S 0:00 -bash
713 tty2 S 0:00 /bin/sh ./test-interactivity.sh
714 tty2 S 0:00 tee inter-2.5.64bk2.log
715 tty2 S 0:00 cat cedo.iso
716 tty2 R 3:15 bzip2
740 tty2 R 0:00 ps x
Wed Mar 26 10:50:34 CET 2003
-----
Wed Mar 26 10:51:06 CET 2003
PID TTY STAT TIME COMMAND
325 tty2 S 0:00 -bash
713 tty2 R 0:00 /bin/sh ./test-interactivity.sh
714 tty2 S 0:00 tee inter-2.5.64bk2.log
715 tty2 S 0:00 cat cedo.iso
716 tty2 R 3:47 bzip2
744 tty2 R 0:00 ps x
Wed Mar 26 10:51:06 CET 2003
-----
Wed Mar 26 10:51:39 CET 2003
PID TTY STAT TIME COMMAND
325 tty2 S 0:00 -bash
713 tty2 S 0:00 /bin/sh ./test-interactivity.sh
714 tty2 S 0:00 tee inter-2.5.64bk2.log
715 tty2 S 0:00 cat cedo.iso
716 tty2 R 4:19 bzip2
748 tty2 R 0:00 ps x
Wed Mar 26 10:51:39 CET 2003
-----
Wed Mar 26 10:52:12 CET 2003
PID TTY STAT TIME COMMAND
325 tty2 S 0:00 -bash
713 tty2 S 0:00 /bin/sh ./test-interactivity.sh
714 tty2 S 0:00 tee inter-2.5.64bk2.log
715 tty2 S 0:01 cat cedo.iso
716 tty2 R 4:52 bzip2
752 tty2 R 0:00 ps x
Wed Mar 26 10:52:12 CET 2003
-----
Wed Mar 26 10:52:45 CET 2003
PID TTY STAT TIME COMMAND
325 tty2 S 0:00 -bash
713 tty2 R 0:00 /bin/sh ./test-interactivity.sh
714 tty2 S 0:00 tee inter-2.5.64bk2.log
715 tty2 S 0:01 cat cedo.iso
716 tty2 R 5:24 bzip2
756 tty2 R 0:00 ps x
Wed Mar 26 10:52:45 CET 2003
-----
Wed Mar 26 10:53:17 CET 2003
PID TTY STAT TIME COMMAND
325 tty2 S 0:00 -bash
713 tty2 S 0:00 /bin/sh ./test-interactivity.sh
714 tty2 S 0:00 tee inter-2.5.64bk2.log
715 tty2 S 0:01 cat cedo.iso
716 tty2 R 5:57 bzip2
760 tty2 R 0:00 ps x
Wed Mar 26 10:53:17 CET 2003
-----
Wed Mar 26 10:53:50 CET 2003
PID TTY STAT TIME COMMAND
325 tty2 S 0:00 -bash
713 tty2 S 0:00 /bin/sh ./test-interactivity.sh
714 tty2 S 0:00 tee inter-2.5.64bk2.log
715 tty2 S 0:01 cat cedo.iso
716 tty2 R 6:29 bzip2
764 tty2 R 0:00 ps x
Wed Mar 26 10:53:50 CET 2003
-----
Wed Mar 26 10:54:23 CET 2003
PID TTY STAT TIME COMMAND
325 tty2 S 0:00 -bash
713 tty2 R 0:00 /bin/sh ./test-interactivity.sh
714 tty2 S 0:00 tee inter-2.5.64bk2.log
715 tty2 S 0:01 cat cedo.iso
716 tty2 R 7:01 bzip2
768 tty2 R 0:00 ps x
Wed Mar 26 10:54:23 CET 2003
-----
Wed Mar 26 10:54:56 CET 2003
PID TTY STAT TIME COMMAND
325 tty2 S 0:00 -bash
713 tty2 S 0:00 /bin/sh ./test-interactivity.sh
714 tty2 S 0:00 tee inter-2.5.64bk2.log
715 tty2 D 0:01 cat cedo.iso
716 tty2 S 7:41 bzip2
772 tty2 R 0:00 ps x
Wed Mar 26 10:55:03 CET 2003
-----
Wed Mar 26 10:55:45 CET 2003
PID TTY STAT TIME COMMAND
325 tty2 S 0:00 -bash
713 tty2 S 0:00 /bin/sh ./test-interactivity.sh
714 tty2 S 0:00 tee inter-2.5.64bk2.log
715 tty2 D 0:01 cat cedo.iso
716 tty2 S 8:50 bzip2
776 tty2 R 0:00 ps x
Wed Mar 26 10:56:13 CET 2003
-----
Wed Mar 26 10:56:50 CET 2003
PID TTY STAT TIME COMMAND
325 tty2 S 0:00 -bash
713 tty2 R 0:00 /bin/sh ./test-interactivity.sh
714 tty2 S 0:00 tee inter-2.5.64bk2.log
715 tty2 S 0:01 cat cedo.iso
716 tty2 R 9:27 bzip2
780 tty2 R 0:00 ps x
Wed Mar 26 10:56:50 CET 2003
-----
Wed Mar 26 10:57:23 CET 2003
PID TTY STAT TIME COMMAND
325 tty2 S 0:00 -bash
713 tty2 S 0:00 /bin/sh ./test-interactivity.sh
714 tty2 S 0:00 tee inter-2.5.64bk2.log
715 tty2 D 0:02 cat cedo.iso
716 tty2 S 10:23 bzip2
784 tty2 R 0:00 ps x
Wed Mar 26 10:57:47 CET 2003
-----
Wed Mar 26 10:58:29 CET 2003
PID TTY STAT TIME COMMAND
325 tty2 S 0:00 -bash
713 tty2 S 0:00 /bin/sh ./test-interactivity.sh
714 tty2 S 0:00 tee inter-2.5.64bk2.log
715 tty2 D 0:02 cat cedo.iso
716 tty2 S 11:09 bzip2
788 tty2 R 0:00 ps x
Wed Mar 26 10:58:33 CET 2003
-----
Wed Mar 26 10:59:19 CET 2003
PID TTY STAT TIME COMMAND
325 tty2 S 0:00 -bash
713 tty2 S 0:00 /bin/sh ./test-interactivity.sh
714 tty2 S 0:00 tee inter-2.5.64bk2.log
715 tty2 D 0:02 cat cedo.iso
716 tty2 S 11:59 bzip2
792 tty2 R 0:00 ps x
Wed Mar 26 10:59:24 CET 2003
-----
(I interrupted the script here)
You can see that after less then 8 minutes running date, ps, and date
again takes a very long time. When this happens, ps shows cat process in
D-state and bzip2 in S-state.
I use Debian Woody on UP Athlon 800MHz, Asus A7V, 384MB RAM, disk WDC
WD800JB-00CRA1 connected to on-board Promise 20265, nVidia Geforce2 MX,
Realtek RTL-8139C, SB Live.
GCC is 2.95.4.
Let me know if you want me to provide more information/testing.
Michal Schmidt.
On Wed, 2003-03-26 at 11:51, Michal Schmidt wrote:
> I'm seeing serious interactivity problems in 2.5.65, 2.5.66, 2.5.65-mm4
> and 2.5.64-bk2.
> I couldn't reproduce it on 2.5.64, 2.5.64-bk1.
I'm seeing similar on 2.5.66; xmms pauses when doing disk intensive
tasks.
> I use Debian Woody on UP Athlon 800MHz, Asus A7V, 384MB RAM, disk WDC
> WD800JB-00CRA1 connected to on-board Promise 20265, nVidia Geforce2 MX,
> Realtek RTL-8139C, SB Live.
> GCC is 2.95.4.
My system details: Gentoo Linux 1.2, PIII 1Ghz, 256MB RAM, Ati Rage128,
tulip nic, es1371 based sound card, gcc 2.95.3.
I'd be prepared to test any proposed fixes.
thanks,
Andy
The contents of this e-mail and any attachments are confidential and may
be legally privileged. If you have received this e-mail and you are not
a named addressee, please inform us as soon as possible on
+44 118 901 2999 and then delete the e-mail from your system. If you are
not a named addressee you must not copy, use, disclose, distribute,
print or rely on this e-mail. Any views expressed in this e-mail or any
attachments may not necessarily reflect those of Tao's management.
Although we routinely screen for viruses, addressees should scan this
e-mail and any attachments for viruses. Tao makes no representation or
warranty as to the absence of viruses in this e-mail or any attachments.
Please note that for the protection of our business, we may monitor and
read e-mails sent to and from our server(s).
Andrew Ebling wrote:
>
>
> I'm seeing similar on 2.5.66; xmms pauses when doing disk intensive
> tasks.
>
This may be a different problem. My test is not very disk intensive. It
is more CPU intensive (bzip2 compression). The disk is only slightly
used when running my testing script.
Michal Schmidt.
On Wed, 2003-03-26 at 14:16, Michal Schmidt wrote:
> Andrew Ebling wrote:
> > I'm seeing similar on 2.5.66; xmms pauses when doing disk intensive
> > tasks.
> This may be a different problem. My test is not very disk intensive. It
> is more CPU intensive (bzip2 compression). The disk is only slightly
> used when running my testing script.
I just experienced the problem very badly when tarring/bzipping hundreds
of MB of source files - almost certainly CPU bound on that occasion ;-).
I could do this on 2.4.2x with no problem.
btw. xmms is playing via ALSA, but other apps are also being starved of
CPU time - 30 second screen redraws :-/.
Andy
The contents of this e-mail and any attachments are confidential and may
be legally privileged. If you have received this e-mail and you are not
a named addressee, please inform us as soon as possible on
+44 118 901 2999 and then delete the e-mail from your system. If you are
not a named addressee you must not copy, use, disclose, distribute,
print or rely on this e-mail. Any views expressed in this e-mail or any
attachments may not necessarily reflect those of Tao's management.
Although we routinely screen for viruses, addressees should scan this
e-mail and any attachments for viruses. Tao makes no representation or
warranty as to the absence of viruses in this e-mail or any attachments.
Please note that for the protection of our business, we may monitor and
read e-mails sent to and from our server(s).
On Wed, 2003-03-26 at 15:08, Andrew Ebling wrote:
> I'm seeing similar on 2.5.66; xmms pauses when doing disk intensive
> tasks.
Just out of curiosity, do mpg123 (or mpg321) and ogg123 behave in the
same manner? I have found that XMMS is prone to skips, pauses and hangs,
but not so ogg123.
________________________________________________________________________
Felipe Alfaro Solana
Linux Registered User #287198
http://counter.li.org
On 26 Mar 2003, Andrew Ebling wrote:
> On Wed, 2003-03-26 at 11:51, Michal Schmidt wrote:
>
> > I'm seeing serious interactivity problems in 2.5.65, 2.5.66, 2.5.65-mm4
> > and 2.5.64-bk2.
> > I couldn't reproduce it on 2.5.64, 2.5.64-bk1.
>
> I'm seeing similar on 2.5.66; xmms pauses when doing disk intensive
> tasks.
The only problem I see with X under 2.5.66 is that if you stop using it
long enough to have the screensaver kick in you can never unlock it. This
is in 2.5.6[56] and not in 2.5.59.
Having the screen locked certainly does hurt interactivity;-)
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
At 03:16 PM 3/26/2003 +0100, Michal Schmidt wrote:
>Andrew Ebling wrote:
>>
>>I'm seeing similar on 2.5.66; xmms pauses when doing disk intensive
>>tasks.
>
>This may be a different problem. My test is not very disk intensive. It is
>more CPU intensive (bzip2 compression). The disk is only slightly used
>when running my testing script.
Greetings potential victims :)
Care to see if the attached cures your woes?
This is a mixture of Ingo's last posted plus the scheduler tuning knobs
patch (/proc/sys/sched/*). I added three new knobs to watch the effect on
different loads. max_accel_slices limits the amount of sleep_time you may
add in one activation. retard_prct_slices is a percentage of a slice to
deduct from sleep_time each activation (negative feedback for heavy context
switchers.. dang irman process_load). force_switch is there because I'm
playing :) I didn't do much to the scheduler itself, only made it switch
arrays in something closer to a square wave. With the settings as in the
patch, and running a kernel build, top and irman, irman reports worst case
response times of 150ms for NULL load, 316ms for memory_load, 414 for
io_load, and 504ms for process_load.
Anyway, it's attached if you want to play with it ;-)
-Mike
Oh, it's against virgin 2.5.66.
At 06:50 PM 3/28/2003 +0100, Mike Galbraith wrote:
>Anyway, it's attached if you want to play with it ;-)
P.S. it's been beaten hard on my little UP (+preempt, but) box. It is
interesting to watch, and I haven't been able to piss it off yet.
Mike Galbraith wrote:
>
> Greetings potential victims :)
>
> Care to see if the attached cures your woes?
>
> This is a mixture of Ingo's last posted plus the scheduler tuning knobs
> patch (/proc/sys/sched/*). I added three new knobs to watch the effect
> on different loads. max_accel_slices limits the amount of sleep_time
> you may add in one activation. retard_prct_slices is a percentage of a
> slice to deduct from sleep_time each activation (negative feedback for
> heavy context switchers.. dang irman process_load). force_switch is
> there because I'm playing :) I didn't do much to the scheduler itself,
> only made it switch arrays in something closer to a square wave. With
> the settings as in the patch, and running a kernel build, top and irman,
> irman reports worst case response times of 150ms for NULL load, 316ms
> for memory_load, 414 for io_load, and 504ms for process_load.
>
> Anyway, it's attached if you want to play with it ;-)
>
> -Mike
>
> Oh, it's against virgin 2.5.66.
Thanks, running 2.5.66 with the patch applied I could no more reproduce
the problem. I haven't tried playing with the knobs.
Michal
At 12:51 AM 3/31/2003 +0200, Michal Schmidt wrote:
>Mike Galbraith wrote:
>>Greetings potential victims :)
>>Care to see if the attached cures your woes?
>>This is a mixture of Ingo's last posted plus the scheduler tuning knobs
>>patch (/proc/sys/sched/*). I added three new knobs to watch the effect
>>on different loads. max_accel_slices limits the amount of sleep_time you
>>may add in one activation. retard_prct_slices is a percentage of a slice
>>to deduct from sleep_time each activation (negative feedback for heavy
>>context switchers.. dang irman process_load). force_switch is there
>>because I'm playing :) I didn't do much to the scheduler itself, only
>>made it switch arrays in something closer to a square wave. With the
>>settings as in the patch, and running a kernel build, top and irman,
>>irman reports worst case response times of 150ms for NULL load, 316ms for
>>memory_load, 414 for io_load, and 504ms for process_load.
>>Anyway, it's attached if you want to play with it ;-)
>> -Mike
>>Oh, it's against virgin 2.5.66.
>
>
>Thanks, running 2.5.66 with the patch applied I could no more reproduce
>the problem. I haven't tried playing with the knobs.
Thanks for the info.
-Mike