scheduling problems in X with 2.6.0
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!
Signature · 10 lines
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.)Quoted 12 lines · martin f krafft
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.
Quoted 5 lines
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]:
Quoted 3 lines
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!
Signature · 7 lines
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 nietzscheQuoted 36 lines · martin f krafft
also sprach Nick Piggin <[email protected]> [2004.01.07.1630 +0100]:
Quoted 4 lines
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
Quoted 5 lines
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]:
Quoted 3 lines
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?
Signature · 10 lines
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!
Quoted 11 lines · martin f krafft
also sprach Nick Piggin <[email protected]> [2004.01.08.1634 +0100]:
Quoted 4 lines
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.gzFrom 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]:
Quoted 2 lines
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.
Signature · 7 lines
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.