Hi all,
Ever since I moved to 2.6.0, I have been experiencing something I'd
like to call scheduling problems while working in X. I have tried
using preemptive mode, and turning it off, but the symptoms are the
same:
whenever there is continuous disk access (e.g. tar, rsync, dd),
X will not respond for a couple of seconds every couple of seconds.
With that I mean that the mouse will freeze as well as all screen
output, and then resume after a couple of seconds.
I wonder if I am the only one with that problem. The machine in
question is a dual AMD 2400+ with 2Gb of RAM and a Maxtor DiamondMax
drive spinning at 7200 RPM. The drive is configured as follows
(hdparm):
multcount = 16 (on)
IO_support = 1 (32-bit)
unmaskirq = 0 (off)
using_dma = 1 (on)
keepsettings = 0 (off)
readonly = 0 (off)
readahead = 256 (on)
geometry = 16383/255/63, sectors = 241254720, start = 0
Model=IC35L120AVV207-0, FwRev=V24OA63A, SerialNo=VNVD06G4C1NXZL
Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=52
BuffType=DualPortCache, BuffSize=1821kB, MaxMultSect=16, MultSect=16
CurCHS=65535/1/63, CurSects=4128705, LBA=yes, LBAsects=241254720
IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 udma2 udma3 udma4 *udma5
AdvancedPM=yes: disabled (255) WriteCache=enabled
Drive conforms to: ATA/ATAPI-6 T13 1410D revision 3a:
I would appreciate any pointers to the source of the problem, or
general hints!
--
martin; (greetings from the heart of the sun.)
\____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
invalid/expired pgp subkeys? use subkeys.pgp.net as keyserver!
"never try to explain computers to a layman.
it's easier to explain sex to a virgin."
-- robert heinlein
(note, however, that virgins tend to know a lot about computers.)
martin f krafft wrote:
>Hi all,
>
>Ever since I moved to 2.6.0, I have been experiencing something I'd
>like to call scheduling problems while working in X. I have tried
>using preemptive mode, and turning it off, but the symptoms are the
>same:
>
>whenever there is continuous disk access (e.g. tar, rsync, dd),
>X will not respond for a couple of seconds every couple of seconds.
>With that I mean that the mouse will freeze as well as all screen
>output, and then resume after a couple of seconds.
>
>I wonder if I am the only one with that problem. The machine in
>question is a dual AMD 2400+ with 2Gb of RAM and a Maxtor DiamondMax
>drive spinning at 7200 RPM. The drive is configured as follows
>(hdparm):
>
Can you post 20 or so lines of 'vmstat 1' captured while the problem is
happening? See if you can see which lines correspond to X freezing (ie.
watch the xterm), but that might be impossible if everything freezes.
also sprach Nick Piggin <[email protected]> [2004.01.07.1630 +0100]:
> Can you post 20 or so lines of 'vmstat 1' captured while the problem is
> happening? See if you can see which lines correspond to X freezing (ie.
> watch the xterm), but that might be impossible if everything freezes.
procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
2 2 0 1137424 235064 456972 0 0 736 712 4303 8686 15 6 17 62
0 3 0 1135696 236116 457008 0 0 1000 688 4321 8004 11 15 14 61
2 2 0 1132336 237724 457304 0 0 1508 40 4475 10604 25 12 19 44
1 2 0 1129008 238852 457400 0 0 1036 1616 4476 9232 17 11 13 59
1 2 0 1125488 240740 457552 0 0 1836 1408 4509 9179 15 10 4 72
0 3 0 1121328 243212 457732 0 0 2340 988 4634 11376 27 14 12 47
2 5 0 1117744 245336 457920 0 0 2040 44 4538 9344 17 17 16 51
1 1 0 1115632 246228 458116 0 0 776 784 4339 9230 22 9 5 63
0 3 0 1112624 247448 458256 0 0 1108 1424 4456 9141 22 10 22 46
1 5 0 1110896 248104 458416 0 0 576 536 4294 8767 18 8 6 68
3 1 0 1107728 250068 458492 0 0 1876 792 4626 9652 20 10 23 47
1 2 0 1105872 251028 458620 0 0 916 1236 4399 8839 16 17 19 48
0 2 0 1102224 253096 458864 0 0 1956 500 4583 9880 29 11 13 49
2 1 0 1098896 255128 459008 0 0 1972 464 4628 9729 18 8 23 51
0 2 0 1096448 256500 459132 0 0 1316 920 4476 9485 18 10 3 71
0 3 0 1094016 257884 459244 0 0 1280 1004 4467 9896 23 9 8 59
0 3 0 1091328 258800 459416 0 0 848 824 4316 8754 17 17 12 53
1 2 0 1087744 260236 459476 0 0 1392 28 4447 9077 13 8 16 62
0 2 0 1086096 261028 459704 0 0 692 788 4226 8918 24 8 12 56
0 3 0 1085776 261284 459652 0 0 256 760 4200 7934 6 4 29 63
4 2 0 1083632 262220 459872 0 0 796 504 4321 9680 29 10 10 51
0 3 0 1082800 262924 459848 0 0 704 456 4227 7885 6 13 17 64
2 2 0 1081824 263500 460020 0 0 512 28 4228 9024 19 6 13 62
1 2 0 1080608 264360 460044 0 0 824 388 4238 9320 14 7 13 66
2 2 0 1079648 264964 460188 0 0 544 388 4260 8962 19 7 13 60
0 2 0 1078160 265800 460304 0 0 808 360 4264 8831 15 9 28 48
Although I can't see a clear pattern of when exactly it froze, it
definitely froze everytime right before outputting a line with
r > 1. Sometimes, it also froze when r == 1 and sometimes even with
r == 0.
Thanks!
--
martin; (greetings from the heart of the sun.)
\____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
invalid/expired pgp subkeys? use subkeys.pgp.net as keyserver!
"wer ein warum hat, dem ist kein wie zu schwer."
- friedrich nietzsche
martin f krafft wrote:
>also sprach Nick Piggin <[email protected]> [2004.01.07.1630 +0100]:
>
>>Can you post 20 or so lines of 'vmstat 1' captured while the problem is
>>happening? See if you can see which lines correspond to X freezing (ie.
>>watch the xterm), but that might be impossible if everything freezes.
>>
>
>procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
> r b swpd free buff cache si so bi bo in cs us sy id wa
> 2 2 0 1137424 235064 456972 0 0 736 712 4303 8686 15 6 17 62
> 0 3 0 1135696 236116 457008 0 0 1000 688 4321 8004 11 15 14 61
> 2 2 0 1132336 237724 457304 0 0 1508 40 4475 10604 25 12 19 44
> 1 2 0 1129008 238852 457400 0 0 1036 1616 4476 9232 17 11 13 59
> 1 2 0 1125488 240740 457552 0 0 1836 1408 4509 9179 15 10 4 72
> 0 3 0 1121328 243212 457732 0 0 2340 988 4634 11376 27 14 12 47
> 2 5 0 1117744 245336 457920 0 0 2040 44 4538 9344 17 17 16 51
> 1 1 0 1115632 246228 458116 0 0 776 784 4339 9230 22 9 5 63
> 0 3 0 1112624 247448 458256 0 0 1108 1424 4456 9141 22 10 22 46
> 1 5 0 1110896 248104 458416 0 0 576 536 4294 8767 18 8 6 68
> 3 1 0 1107728 250068 458492 0 0 1876 792 4626 9652 20 10 23 47
> 1 2 0 1105872 251028 458620 0 0 916 1236 4399 8839 16 17 19 48
> 0 2 0 1102224 253096 458864 0 0 1956 500 4583 9880 29 11 13 49
> 2 1 0 1098896 255128 459008 0 0 1972 464 4628 9729 18 8 23 51
> 0 2 0 1096448 256500 459132 0 0 1316 920 4476 9485 18 10 3 71
> 0 3 0 1094016 257884 459244 0 0 1280 1004 4467 9896 23 9 8 59
> 0 3 0 1091328 258800 459416 0 0 848 824 4316 8754 17 17 12 53
> 1 2 0 1087744 260236 459476 0 0 1392 28 4447 9077 13 8 16 62
> 0 2 0 1086096 261028 459704 0 0 692 788 4226 8918 24 8 12 56
> 0 3 0 1085776 261284 459652 0 0 256 760 4200 7934 6 4 29 63
> 4 2 0 1083632 262220 459872 0 0 796 504 4321 9680 29 10 10 51
> 0 3 0 1082800 262924 459848 0 0 704 456 4227 7885 6 13 17 64
> 2 2 0 1081824 263500 460020 0 0 512 28 4228 9024 19 6 13 62
> 1 2 0 1080608 264360 460044 0 0 824 388 4238 9320 14 7 13 66
> 2 2 0 1079648 264964 460188 0 0 544 388 4260 8962 19 7 13 60
> 0 2 0 1078160 265800 460304 0 0 808 360 4264 8831 15 9 28 48
>
>Although I can't see a clear pattern of when exactly it froze, it
>definitely froze everytime right before outputting a line with
>r > 1. Sometimes, it also froze when r == 1 and sometimes even with
>r == 0.
>
OK so its not VM stalls. In fact, it looks like your system is
only under a moderate load.
You could try my alternate CPU scheduler which would tell us if your
problem is the scheduler or something else. Its against the mm tree.
http://www.kerneltrap.org/~npiggin/v29p6.gz
also sprach Nick Piggin <[email protected]> [2004.01.08.1634 +0100]:
> You could try my alternate CPU scheduler which would tell us if your
> problem is the scheduler or something else. Its against the mm tree.
> http://www.kerneltrap.org/~npiggin/v29p6.gz
From a quick glance, it mentions the Pentium 4 and Hyperthreading.
This *is* an SMP system, but it uses Athlon XPs. Will your scheduler
still work?
--
martin; (greetings from the heart of the sun.)
\____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
invalid/expired pgp subkeys? use subkeys.pgp.net as keyserver!
government announcement - the government announced today that it is
changing its mascot to a condom because it more clearly reflects the
government's political stance. a condom stands up to inflation, halts
production, destroys the next generation, protects a bunch of pricks
and finally, gives you a sense of security while you're being screwed!
martin f krafft wrote:
>also sprach Nick Piggin <[email protected]> [2004.01.08.1634 +0100]:
>
>>You could try my alternate CPU scheduler which would tell us if your
>>problem is the scheduler or something else. Its against the mm tree.
>>http://www.kerneltrap.org/~npiggin/v29p6.gz
>>
>
>From a quick glance, it mentions the Pentium 4 and Hyperthreading.
>This *is* an SMP system, but it uses Athlon XPs. Will your scheduler
>still work?
>
Yeah, my interactivity stuff has to be applied after my SMP stuff,
so I had to give you both ;)
You'll want to run make oldconfig after patching, and you needn't say
yes to CONFIG_SCHED_SMT, although if you did it wouldn't hurt either,
it just wouldn't do anything.
Nick
also sprach Nick Piggin <[email protected]> [2004.01.08.1634 +0100]:
> OK so its not VM stalls. In fact, it looks like your system is
> only under a moderate load.
I would not expect so. I find it kinda hard to load a system with 2Gb
of RAM and a dual Athlon XP 2400+ using only rsync... the
harddrive bottleneck prevents it from breaking a sweat.
--
martin; (greetings from the heart of the sun.)
\____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
invalid/expired pgp subkeys? use subkeys.pgp.net as keyserver!
linux is like a wigwam.
no gates, no windoze, and an apache inside.