Staircase scheduler v7.4
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
I just applied the patch against 2.6.7-bk7 and saw the following strange thing:
I was compiling some program, as suddenly compilation stopped. g++ was running (sorry, I didn't look at the process state. Maybe it was in T or something like that), but it didn't get any timeslice. (so didn't execute. Simply stayed around and didn't finish).
I noticed this since I switched from staircase 7.1 to 7.4 a few minutes ago. No such problems before.
I'm not really sure, if it's a staircase problem. Just wanted to let you know.
- --
Regards Michael Buesch [ http://www.tuxsoft.de.vu ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFA3FWNFGK1OIvVOP4RAhw1AJ9P50RtKh86EvHWRxJ8l2EdF7lWZACgnFV3 JATebGeaWIOOkBZs4ly6d3g=
=8SfQ
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Michael Buesch wrote:
| Hi, | | I just applied the patch against 2.6.7-bk7 and saw | the following strange thing: | | I was compiling some program, as suddenly compilation | stopped. g++ was running (sorry, I didn't look at the | process state. Maybe it was in T or something like that), | but it didn't get any timeslice. (so didn't execute. Simply | stayed around and didn't finish). | I noticed this since I switched from staircase 7.1 to 7.4 | a few minutes ago. No such problems before. | I'm not really sure, if it's a staircase problem. Just | wanted to let you know.
I haven't seen what is in -bk7 so I don't know if there's an issue with applying it to that. Anything's possible, though. See if you can reproduce it and isolate it to staircase or not and collect some more info about what is happening with the task from top, vmstat and /proc/$pid/status
Cheers,
Con
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFA3FbLZUg7+tp6mRURAhYpAJ0de38QQsNCSeM+t++OjOeCcTIN/wCfTLMj mZJ/IUxcRip4VInYzFsH1Nk=
=yXKm
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Quoted 5 lines · you
I haven't seen what is in -bk7 so I don't know if there's an issue with applying it to that. Anything's possible, though. See if you can reproduce it and isolate it to staircase or not and collect some more info about what is happening with the task from top, vmstat and
/proc/$pid/status
I just catched a stalled process:
mb 11000 0.4 0.6 4604 3180 tty2 S 20:32 0:01 /bin/sh ./configure --enable-debug
mb@lfs:/proc/11000> cat status
Name: configure State: S (sleeping) Burst: 0 Tgid: 11000 Pid: 11000 PPid: 1858 TracerPid: 0 Uid: 1000 1000 1000 1000 Gid: 100 100 100 100 FDSize: 256 Groups: 9 10 100 VmSize: 4604 kB VmLck: 0 kB VmRSS: 3180 kB VmData: 2356 kB VmStk: 132 kB VmExe: 572 kB VmLib: 1444 kB Threads: 1 SigPnd: 0000000000000000 ShdPnd: 0000000000000000 SigBlk: 0000000000010000 SigIgn: 8000000000000004 SigCgt: 0000000043817efb CapInh: 0000000000000000 CapPrm: 0000000000000000 CapEff: 0000000000000000
I don't know what the file wchan is good for, but here is it's output:
mb@lfs:/proc/11000> cat wchansys_wait4
Seems it's killable by SIGKILL only.
mb@lfs:/proc/11000> kill 11000
mb@lfs:/proc/11000> kill 11000
mb@lfs:/proc/11000> kill 11000
mb@lfs:/proc/11000> kill -9 11000
mb@lfs:/proc/11000> kill -9 11000
bash: kill: (11000) - No such process
Now it's some kind of reproducible (maybe because the machine has a higher uptime, now).
A ./configure run sooner or later stalls for sure, now.
mb@lfs:~> vmstat
procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa 13 0 92 42520 43696 235384 0 0 33 75 2201 1949 88 12 0 0
- --
Regards Michael Buesch [ http://www.tuxsoft.de.vu ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFA3HKHFGK1OIvVOP4RAvYoAKDG8rwiNotlMfDA8O1z67LC3NeiTwCgl+GT ADmS474ofisnFfT7/kq0IeU=
=qvC1
-----END PGP SIGNATURE-----
Hi Michael,
Quoted 4 lines · Michael Buesch
I don't know what the file wchan is good for, but here is it's output:
mb@lfs:/proc/11000> cat wchansys_wait4
I bet the process is waiting for a SIGCHLD from a previously forked process. Con, would it be possible that under some circumstances, a process does not receive a SIGCHLD anymore, eg if the child runs shorter than a full timeslice or something like that ? In autoconf scripts, there are lots of very short operations that might trigger such unique cases.
Cheers,
Willy
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Quoted 9 lines · you
Hi Michael,
Quoted 4 lines · Michael Buesch
I don't know what the file wchan is good for, but here is it's output:
mb@lfs:/proc/11000> cat wchansys_wait4
Quoted 6 lines
I bet the process is waiting for a SIGCHLD from a previously forked process. Con, would it be possible that under some circumstances, a process does not receive a SIGCHLD anymore, eg if the child runs shorter than a full timeslice or something like that ? In autoconf scripts, there are lots of very short operations that might trigger such unique cases.
Hm. 11000 is a bash, so it forked some process. Just wanted to note, that there are _no_ Zombies around, but this wait()ing bash.
load grows and grows:
top - 21:40:07 up 3:55, 7 users, load average: 10.59, 10.25, 9.99
Tasks: 91 total, 12 running, 79 sleeping, 0 stopped, 0 zombie Cpu(s): 13.7% user, 10.3% system, 76.0% nice, 0.0% idle, 0.0% IO-wait Mem: 515624k total, 466520k used, 49104k free, 43144k buffers Swap: 976712k total, 92k used, 976620k free, 207184k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ Command
2060 mb 39 19 38872 28m 2904 R 76.0 5.7 153:16.26 FahCore_78.exe
2270 mb 20 0 32428 7924 10m S 13.6 1.5 32:02.58 tvtime
2149 root 20 0 187m 41m 149m S 6.0 8.3 17:10.37 X
8936 mb 20 0 32736 20m 29m S 2.0 4.0 2:33.62 ksysguard
2238 mb 20 0 28628 15m 9m S 0.7 3.1 0:45.02 gkrellm
2315 mb 20 0 57052 11m 11m S 0.3 2.3 0:22.20 beep-media-play
8937 mb 20 0 2012 1072 1592 S 0.3 0.2 0:38.52 ksysguardd
1 root 20 0 1412 520 1252 S 0.0 0.1 0:00.30 init
2 root 39 19 0 0 0 R 0.0 0.0 0:00.00 ksoftirqd/0
3 root 10 -10 0 0 0 S 0.0 0.0 0:00.16 events/0... following more processes with 0.0% CPU.
As you can see, it's impossible to generate a load of 10.59 with these few processes running. There are two processes running full time. FahCore_78.exe at nice 19 and tvtime never uses more then 15% CPU.
But as the load grows, the system is usable as with load 0.0. And it really should be usable with 76.0% nice. ;) No problem here. This really high load is not correct.
- --
Regards Michael Buesch [ http://www.tuxsoft.de.vu ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFA3IGRFGK1OIvVOP4RAiemAKCnU2dTT9S3OWRRRKiFjYCfwVYk2gCeMVS6 nFs/eoY4VDwlQns4AK9te2c=
=NFUT
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Michael Buesch wrote:
| On Friday 25 June 2004 21:05, you wrote: | |>>Hi Michael, |>> |>>On Fri, Jun 25, 2004 at 08:44:22PM +0200, Michael Buesch wrote: |>> |>> |>>>I don't know what the file wchan is good for, but here is |>>>it's output: |>>>mb@lfs:/proc/11000> cat wchan |>>>sys_wait4 |>> |>>I bet the process is waiting for a SIGCHLD from a previously forked |>>process. Con, would it be possible that under some circumstances, |>>a process does not receive a SIGCHLD anymore, eg if the child runs |>>shorter than a full timeslice or something like that ? In autoconf |>>scripts, there are lots of very short operations that might trigger |>>such unique cases. | But as the load grows, the system is usable as with load 0.0. | And it really should be usable with 76.0% nice. ;) No problem here. | This really high load is not correct.
I think you're right about having no timeslice.
It does appear that I fixed two things and introduced 2 more bugs. I'll fix it in the next couple of days.
Con
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFA3NnqZUg7+tp6mRURAk7tAJ9bKHWsnnNOf9j0PGXKh23rvBAbPQCfWC+8 w+VCt4GhvaR/bL6s9+GjrOQ=
=KIkQ
-----END PGP SIGNATURE-----
Quoting Michael Buesch <[email protected]>:
Quoted 3 lines
But as the load grows, the system is usable as with load 0.0. And it really should be usable with 76.0% nice. ;) No problem here. This really high load is not correct.
There was the one clear bug that Adrian Drzewiecki found (thanks!) that is easy to fix. Can you see if this has any effect before I go searching elsewhere?
Con
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Quoted 2 lines · you
There was the one clear bug that Adrian Drzewiecki found (thanks!) that is easy to fix. Can you see if this has any effect before I go searching elsewhere?
Ok, I'll try it.
OT:
Some mails bounce on [email protected]:
This is the Postfix program at host bhhdoa.org.au.
####################################################################
# THIS IS A WARNING ONLY. YOU DO NOT NEED TO RESEND YOUR MESSAGE. #
####################################################################
Your message could not be delivered for 4.0 hours. It will be retried until it is 5.0 days old.
For further assistance, please send mail to <postmaster>
The Postfix program
<[email protected]>: connect to kolivas.org[211.28.147.198]: Connection timed
out
Final-Recipient: rfc822; [email protected]
Action: delayed
Status: 4.0.0
Diagnostic-Code: X-Postfix; connect to kolivas.org[211.28.147.198]: Connection
timed out
Will-Retry-Until: Wed, 30 Jun 2004 13:29:45 -0400 (EDT)
- --
Regards Michael Buesch [ http://www.tuxsoft.de.vu ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFA3aVtFGK1OIvVOP4RApVwAJ9ows81hLZoQtiFer5/F9DDZwKrHACdF/Cs y1sfWD8BusvvLWJMJbcT+yY=
=Kd+H
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Quoted 10 lines · you
Quoting Michael Buesch <[email protected]>:
Quoted 3 lines
But as the load grows, the system is usable as with load 0.0. And it really should be usable with 76.0% nice. ;) No problem here. This really high load is not correct.
There was the one clear bug that Adrian Drzewiecki found (thanks!) that is easy to fix. Can you see if this has any effect before I go searching elsewhere?
Con
The problem did not go away with this patch.
I did some stress test:
I downloaded latest kdeextragear-3 package from CVS and ran ./configure script many times.
Directly after booting the script runs fine.
But as the uptime increases (I'm now at 15 minutes, when the script is stuck completely for the first time), my problem gets worse.
At the very beginning, there was no problem running the script, but over time problems increased with uptime.
on 5 till 10 minutes of uptime, the configure began to stuck for 3 or 4 seconds on several (reproducable!) places.# (you can see these places as nice "holes" in the CPU graph of gkrellm)
Now (15 min) it's completely stuck and doesn't get a timeslice.
Now another "problem":
Maybe it's because I'm tired, but it seems like your fix-patch made moving windows in X11 is less smooth. I wanted to mention it, just in case there's some other person, who sees this behaviour, too. In case I'm the only one seeing it, you may forget it. ;)
- --
Regards Michael Buesch [ http://www.tuxsoft.de.vu ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFA3bJ9FGK1OIvVOP4RAjHVAKCt3li6/x1hGZM6xSXeC2FFyFm2KQCgugWL KJxX2zg0WcDSkIzP57JcrrY=
=IDNX
-----END PGP SIGNATURE-----
Quoted 32 lines · Michael Buesch
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1Quoted 10 lines · you
Quoting Michael Buesch <[email protected]>:
Quoted 3 lines
But as the load grows, the system is usable as with load 0.0. And it really should be usable with 76.0% nice. ;) No problem here. This really high load is not correct.
There was the one clear bug that Adrian Drzewiecki found (thanks!) that is easy to fix. Can you see if this has any effect before I go searching elsewhere?
Con
The problem did not go away with this patch.
I did some stress test:I downloaded latest kdeextragear-3 package from CVS and ran ./configure script many times.
Directly after booting the script runs fine.
But as the uptime increases (I'm now at 15 minutes, when the script is stuck completely for the first time), my problem gets worse.
At the very beginning, there was no problem running the script, but over time problems increased with uptime.
on 5 till 10 minutes of uptime, the configure began to stuck for 3 or 4 seconds on several (reproducable!) places.# (you can see these places as nice "holes" in the CPU graph of gkrellm)
Now (15 min) it's completely stuck and doesn't get a timeslice.
Quoted 6 lines
Now another "problem":
Maybe it's because I'm tired, but it seems like your fix-patch made moving windows in X11 is less smooth. I wanted to mention it, just in case there's some other person, who sees this behaviour, too. In case I'm the only one seeing it, you may forget it. ;)
Almost certainly they are one and the same thing. I have been away and unable to attend to this just yet but it appears there's some sanity check missing from the "I've just forked" logic I introduced to 7.4. I'll look into it further asap.
Con
Quoted 6 lines · Michael Buesch
Now another "problem":
Maybe it's because I'm tired, but it seems like your fix-patch made moving windows in X11 is less smooth. I wanted to mention it, just in case there's some other person, who sees this behaviour, too. In case I'm the only one seeing it, you may forget it. ;)
I can see the same with 7.4-1 (that's 2.6.7-ck2 plus the fix-patch): X11 feels sluggish while moving windows around. Simply by loading a Web page into Konqueror and dragging Evolution over it, makes me able to reproduce this problem.
Doing the same on 2.6.7-mm3 is totally smooth, however.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Quoting Felipe Alfaro Solana <[email protected]>:
Quoted 9 lines · Michael Buesch
Quoted 7 lines
Now another "problem":
Maybe it's because I'm tired, but it seems like your fix-patch made moving windows in X11 is less smooth. I wanted to mention it, just in case there's some other person, who sees this behaviour, too. In case I'm the only one seeing it, you may forget it. ;)
Quoted 6 lines
I can see the same with 7.4-1 (that's 2.6.7-ck2 plus the fix-patch): X11 feels sluggish while moving windows around. Simply by loading a Web page into Konqueror and dragging Evolution over it, makes me able to reproduce this problem.
Doing the same on 2.6.7-mm3 is totally smooth, however.
I think staircase-7.7 fixed this, too. (for me).
Have a try.
- --
Regards Michael Buesch [ http://www.tuxsoft.de.vu ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFA3x/2FGK1OIvVOP4RAnxTAJ9NUM6V1bccFgAauHx6sV6+80DjLQCg1hE8 c2krr3+fW/notHs8mc8it48=
=OQoZ
-----END PGP SIGNATURE-----
Quoted 18 lines · Michael Buesch
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1Quoting Felipe Alfaro Solana <[email protected]>:
Quoted 14 lines · Michael Buesch
Quoted 7 lines
Now another "problem":
Maybe it's because I'm tired, but it seems like your fix-patch made moving windows in X11 is less smooth. I wanted to mention it, just in case there's some other person, who sees this behaviour, too. In case I'm the only one seeing it, you may forget it. ;)I can see the same with 7.4-1 (that's 2.6.7-ck2 plus the fix-patch): X11 feels sluggish while moving windows around. Simply by loading a Web page into Konqueror and dragging Evolution over it, makes me able to reproduce this problem.
Quoted 4 lines
Quoted 1 line
Doing the same on 2.6.7-mm3 is totally smooth, however.
I think staircase-7.7 fixed this, too. (for me).
Have a try.
Staircase 7.7 over 2.6.7-ck2 still feels somewhat sluggish... Renicing X to -5 seems to improve a bit, but -mm3 is smoother and does not require renicing the X server.
Quoted 19 lines · Felipe Alfaro Solana
Quoted 18 lines · Michael Buesch
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1Quoting Felipe Alfaro Solana <[email protected]>:
Quoted 14 lines · Michael Buesch
Quoted 7 lines
Now another "problem":
Maybe it's because I'm tired, but it seems like your fix-patch made moving windows in X11 is less smooth. I wanted to mention it, just in case there's some other person, who sees this behaviour, too. In case I'm the only one seeing it, you may forget it. ;)I can see the same with 7.4-1 (that's 2.6.7-ck2 plus the fix-patch): X11 feels sluggish while moving windows around. Simply by loading a Web page into Konqueror and dragging Evolution over it, makes me able to reproduce this problem.
Quoted 8 lines
Quoted 4 lines
Quoted 1 line
Doing the same on 2.6.7-mm3 is totally smooth, however.
I think staircase-7.7 fixed this, too. (for me).
Have a try.Staircase 7.7 over 2.6.7-ck2 still feels somewhat sluggish... Renicing X to -5 seems to improve a bit, but -mm3 is smoother and does not require renicing the X server.
Hi
I seem to have an oversight with ck in the batch implementation that may be causing problems that wouldn't happen if you used the standalone staircase patch. Can you try the standalone s7.7 patch (not from the split out patches in the ck directory) that is in my patches/2.6/2.6.7 directory?
Thanks
Con
Quoted 30 lines · Con Kolivas
Quoted 19 lines · Felipe Alfaro Solana
Quoted 18 lines · Michael Buesch
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1Quoting Felipe Alfaro Solana <[email protected]>:
Quoted 14 lines · Michael Buesch
Quoted 7 lines
Now another "problem":
Maybe it's because I'm tired, but it seems like your fix-patch made moving windows in X11 is less smooth. I wanted to mention it, just in case there's some other person, who sees this behaviour, too. In case I'm the only one seeing it, you may forget it. ;)I can see the same with 7.4-1 (that's 2.6.7-ck2 plus the fix-patch): X11 feels sluggish while moving windows around. Simply by loading a Web page into Konqueror and dragging Evolution over it, makes me able to reproduce this problem.
Quoted 8 lines
Quoted 4 lines
Quoted 1 line
Doing the same on 2.6.7-mm3 is totally smooth, however.
I think staircase-7.7 fixed this, too. (for me).
Have a try.Staircase 7.7 over 2.6.7-ck2 still feels somewhat sluggish... Renicing X to -5 seems to improve a bit, but -mm3 is smoother and does not require renicing the X server.
Quoted 7 lines
Hi
I seem to have an oversight with ck in the batch implementation that may be causing problems that wouldn't happen if you used the standalone staircase patch. Can you try the standalone s7.7 patch (not from the split out patches in the ck directory) that is in my patches/2.6/2.6.7 directory?
I have tested 2.6.7-bk10 plus from_2.6.7_to_staircase_7.7 patch and, while it's definitively better than previous versions, it still feels a little jerky when moving windows in X11 wrt to -mm3. Renicing makes it a little bit smoother, but not as much as -mm3 without renicing.
What it shines on is the fact that the "while true; do a=2; done" loop has no apparent effect on interactivity, that is, the system feels as interactive as when not running this CPU hog.
Quoted 5 lines · Felipe Alfaro Solana
I have tested 2.6.7-bk10 plus from_2.6.7_to_staircase_7.7 patch and, while it's definitively better than previous versions, it still feels a little jerky when moving windows in X11 wrt to -mm3. Renicing makes it a little bit smoother, but not as much as -mm3 without renicing.
You know, if renicing X makes it smoother, then that is a good thing IMO. X needs large amounts of CPU and low latency in order to get good interactivity, which is something the scheduler shouldn't give to a process unless it is told to.
Quoted 8 lines · Nick Piggin
Quoted 5 lines · Felipe Alfaro Solana
I have tested 2.6.7-bk10 plus from_2.6.7_to_staircase_7.7 patch and, while it's definitively better than previous versions, it still feels a little jerky when moving windows in X11 wrt to -mm3. Renicing makes it a little bit smoother, but not as much as -mm3 without renicing.
Quoted 4 lines
You know, if renicing X makes it smoother, then that is a good thing IMO. X needs large amounts of CPU and low latency in order to get good interactivity, which is something the scheduler shouldn't give to a process unless it is told to.
But the problem here is that -ck3 with X reniced to -10 is not as smooth as -mm3 with no renicing. That's what worries me.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Felipe Alfaro Solana wrote:
| On Mon, 2004-06-28 at 18:49 +1000, Nick Piggin wrote: | |>Felipe Alfaro Solana wrote: |> |> |>>I have tested 2.6.7-bk10 plus from_2.6.7_to_staircase_7.7 patch and, |>>while it's definitively better than previous versions, it still feels a |>>little jerky when moving windows in X11 wrt to -mm3. Renicing makes it a |>>little bit smoother, but not as much as -mm3 without renicing. |>> |> |>You know, if renicing X makes it smoother, then that is a good thing |>IMO. X needs large amounts of CPU and low latency in order to get |>good interactivity, which is something the scheduler shouldn't give |>to a process unless it is told to. | | | But the problem here is that -ck3 with X reniced to -10 is not as smooth | as -mm3 with no renicing. That's what worries me.
The design of staircase would make renicing normal interactive things
- -ve values bad for the latency of other nice 0 tasks s is not recommended for X or games etc. Initial scheduling latency is very dependent on nice value in staircase. If you set a cpu hog to nice -5 it will hurt audio at nice 0 and so on. Nicing latency unimportant things with +ve values is more useful with this design. If you run X and evolution at the same nice value they will get equal cpu share for example so moving windows means redrawing evolution and X moving get equal cpu. Nicing evolution +ve will make X smoother compared to evolution redrawing and so on...
Con
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFA4ArqZUg7+tp6mRURAn2BAJ4hkK871JXO/R3AvwR0CzKoLg6f6wCeNBP/ Y1aOfCWLR5QtVZvq8wdpToI=
=xit3
-----END PGP SIGNATURE-----
Quoted 6 lines · Con Kolivas
The design of staircase would make renicing normal interactive things -ve values bad for the latency of other nice 0 tasks s is not recommended for X or games etc. Initial scheduling latency is very dependent on nice value in staircase. If you set a cpu hog to nice -5 it will hurt audio at nice 0 and so on.
i think using nice for both cpu share and latency is broken by design ... a typical use case on my system: for real-time tv recording i need mencoder to get some 80% of the cpu time on average. that means i have to nice -<something "big"> it to prevent compiles, flash plugins running amok, etc. from making mencoder explode (i.e., overrun buffers). but that entirely destroys interactivity; in fact the desktop becomes basically unusable.
greetings
Signature · 3 lines
Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Oswald Buddenhagen wrote:
| On Mon, Jun 28, 2004 at 10:11:22PM +1000, Con Kolivas wrote: | |>The design of staircase would make renicing normal interactive things |>-ve values bad for the latency of other nice 0 tasks s is not |>recommended for X or games etc. Initial scheduling latency is very |>dependent on nice value in staircase. If you set a cpu hog to nice -5 |>it will hurt audio at nice 0 and so on. |> | | i think using nice for both cpu share and latency is broken by design ... | a typical use case on my system: for real-time tv recording i need | mencoder to get some 80% of the cpu time on average. that means i have | to nice -<something "big"> it to prevent compiles, flash plugins running | amok, etc. from making mencoder explode (i.e., overrun buffers). but that | entirely destroys interactivity; in fact the desktop becomes basically | unusable.
You want mencoder to use 80% of your cpu and be scheduled fast enough to not drop frames. Sounds to me like both latency and cpu share are required, no? And if something uses up 80% of your cpu your interactivity drops. Why is that a surprise? If something wants lower latency but doesnt want a lot of cpu, it will only use what it wants. I don't see a problem here.
If X is not smooth, then that is a problem. This scheduler is still under development.
Con
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFA4DcTZUg7+tp6mRURAirZAJ9703erbnS4UikDhpXGn41JuHxaqgCeIshy 099yGuzDyg3BLCEI5/S5xLo=
=xuB1
-----END PGP SIGNATURE-----
Quoted 10 lines · Con Kolivas
| i think using nice for both cpu share and latency is broken by design ... | a typical use case on my system: for real-time tv recording i need | mencoder to get some 80% of the cpu time on average. that means i have | to nice -<something "big"> it to prevent compiles, flash plugins running | amok, etc. from making mencoder explode (i.e., overrun buffers). but that | entirely destroys interactivity; in fact the desktop becomes basically | unusable.You want mencoder to use 80% of your cpu
yes.
Quoted 2 lines
and be scheduled fast enough to not drop frames.
no. a) because the grabber runs in a separate thread that uses hardly any cpu and should be auto-classified as interactive and b) because the bttv driver can buffer a few frames in the kernel anyway.
greetings
Signature · 3 lines
Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done.
Quoted 10 lines · Con Kolivas
The design of staircase would make renicing normal interactive things
- -ve values bad for the latency of other nice 0 tasks s is not recommended for X or games etc. Initial scheduling latency is very dependent on nice value in staircase. If you set a cpu hog to nice -5 it will hurt audio at nice 0 and so on. Nicing latency unimportant things with +ve values is more useful with this design. If you run X and evolution at the same nice value they will get equal cpu share for example so moving windows means redrawing evolution and X moving get equal cpu. Nicing evolution +ve will make X smoother compared to evolution redrawing and so on...
OK, just a few thoughts...
1. Both -mm3 and -np2 suffer from delays when redrawing "damaged" windows (windows which were covered and now are being exposed): while moving heavily a window over the screen, "damaged" windows are not redrawn. I would say this is a sign of starvation. However, this does not happen with -ck3 that is able to redraw "damaged' windows even while heavily moving a window all over the screen.
I can see this by looking at some icons that are lying on my desktop. With -mm3 and -np2, they are hardly redrawn while heavily moving a window all around. With -ck3, I can see the icons and their respective labels all the time.
2. Both -mm3 and -np2 show a very smooth behavior when moving windows all around the screen. However, -ck3 is somewhat a little bit jerky. I think this is a consequence of point number 1.
3. Both -mm3 and -ck3 are inmune to CPU hogs when mantaining
interactivity: running "while true; do a=2; done" doesn't seem to affect the interactive behavior of them. I check this by running this CPU hog and hovering my mouse over KXDocker, which is a nice applet for KDE similar to the Mac OS X docker. KXDocker is another CPU hog by itself, but plays nicely with the "while true" loop. However, -np2 seems to suffer a little bit from starvation, as KXDocker animations don't feel smooth.
Quoted 24 lines · Felipe Alfaro Solana
Quoted 10 lines · Con Kolivas
The design of staircase would make renicing normal interactive things
- -ve values bad for the latency of other nice 0 tasks s is not recommended for X or games etc. Initial scheduling latency is very dependent on nice value in staircase. If you set a cpu hog to nice -5 it will hurt audio at nice 0 and so on. Nicing latency unimportant things with +ve values is more useful with this design. If you run X and evolution at the same nice value they will get equal cpu share for example so moving windows means redrawing evolution and X moving get equal cpu. Nicing evolution +ve will make X smoother compared to evolution redrawing and so on...OK, just a few thoughts...
1. Both -mm3 and -np2 suffer from delays when redrawing "damaged" windows (windows which were covered and now are being exposed): while moving heavily a window over the screen, "damaged" windows are not redrawn. I would say this is a sign of starvation. However, this does not happen with -ck3 that is able to redraw "damaged' windows even while heavily moving a window all over the screen.
Quoted 9 lines
I can see this by looking at some icons that are lying on my desktop. With -mm3 and -np2, they are hardly redrawn while heavily moving a window all around. With -ck3, I can see the icons and their respective labels all the time.
2. Both -mm3 and -np2 show a very smooth behavior when moving windows all around the screen. However, -ck3 is somewhat a little bit jerky. I think this is a consequence of point number 1.
Try having X at a lower priority (higher nice) and it shouldn't get as much of the CPU. I think this is really a fundamental tradeoff that you can't do much about.
Quoted 9 lines
3. Both -mm3 and -ck3 are inmune to CPU hogs when mantaining
interactivity: running "while true; do a=2; done" doesn't seem to affect the interactive behavior of them. I check this by running this CPU hog and hovering my mouse over KXDocker, which is a nice applet for KDE similar to the Mac OS X docker. KXDocker is another CPU hog by itself, but plays nicely with the "while true" loop. However, -np2 seems to suffer a little bit from starvation, as KXDocker animations don't feel smooth.
Hmm, in that case bash should go straight down to lowest priority, so it shouldn't impact too much on others' CPU usage... I'll see what I can do though, timeslices could still be a little too big.
Quoted 8 lines · Nick Piggin
Quoted 5 lines · Felipe Alfaro Solana
I have tested 2.6.7-bk10 plus from_2.6.7_to_staircase_7.7 patch and, while it's definitively better than previous versions, it still feels a little jerky when moving windows in X11 wrt to -mm3. Renicing makes it a little bit smoother, but not as much as -mm3 without renicing.
Quoted 4 lines
You know, if renicing X makes it smoother, then that is a good thing IMO. X needs large amounts of CPU and low latency in order to get good interactivity, which is something the scheduler shouldn't give to a process unless it is told to.
I agree. Although the X servers CPU usage is usually relatively low (less than 5%) it does have periods when it can get quite high (greater than 80%) for reasonably long periods. This makes it difficult to come up with a set of rules for CPU allocation that makes sure the X server gets what it needs (when it needs it) without running the risk of giving other tasks with similar load patterns unnecessary and unintentional preferential treatment.
However, I think that there is still a need for automatic boosts for some tasks. For instance, programs such as xmms and other media streamers are ones whose performance could worsen as a result of the X server being reniced unless it is treated specially and the boost they are given needs to be enough to put them before the X server in priority order. But renicing X would enable a tightening of the rules that govern the automatic dispensing of preferential treatment to tasks that are perceived to be interactive which should be good for overall system performance.
Peter
Signature · 4 lines
Peter Williams [email protected] "Learning, n. The kind of ignorance distinguishing the studious." -- Ambrose Bierce
Quoted 10 lines · Peter Williams
Quoted 8 lines · Nick Piggin
Quoted 5 lines · Felipe Alfaro Solana
I have tested 2.6.7-bk10 plus from_2.6.7_to_staircase_7.7 patch and, while it's definitively better than previous versions, it still feels a little jerky when moving windows in X11 wrt to -mm3. Renicing makes it a little bit smoother, but not as much as -mm3 without renicing.
Quoted 8 lines
Quoted 4 lines
You know, if renicing X makes it smoother, then that is a good thing IMO. X needs large amounts of CPU and low latency in order to get good interactivity, which is something the scheduler shouldn't give to a process unless it is told to.
I agree. Although the X servers CPU usage is usually relatively low (less than 5%) it does have periods when it can get quite high (greater than 80%) for reasonably long periods. This makes it difficult to come up with a set of rules for CPU allocation that makes sure the X server gets what it needs (when it needs it) without running the risk of giving other tasks with similar load patterns unnecessary and unintentional preferential treatment.
Well exactly. This is what the standard scheduler tries to do, and it does have weird starvation and priority problems that pop up.
Quoted 1 line
However, I think that there is still a need for automatic boosts for some tasks. For instance, programs such as xmms and other media streamers are ones whose performance could worsen as a result of the X server being reniced unless it is treated specially and the boost they are given needs to be enough to put them before the X server in priority order. But renicing X would enable a tightening of the rules that govern the automatic dispensing of preferential treatment to tasks that are perceived to be interactive which should be good for overall system performance.
I agree renicing X is helpful.
Quoted 22 lines · Nick Piggin
Quoted 10 lines · Peter Williams
Quoted 8 lines · Nick Piggin
Quoted 5 lines · Felipe Alfaro Solana
I have tested 2.6.7-bk10 plus from_2.6.7_to_staircase_7.7 patch and, while it's definitively better than previous versions, it still feels a little jerky when moving windows in X11 wrt to -mm3. Renicing makes it a little bit smoother, but not as much as -mm3 without renicing.
Quoted 9 lines
Quoted 4 lines
You know, if renicing X makes it smoother, then that is a good thing IMO. X needs large amounts of CPU and low latency in order to get good interactivity, which is something the scheduler shouldn't give to a process unless it is told to.
I agree. Although the X servers CPU usage is usually relatively low (less than 5%) it does have periods when it can get quite high (greater than 80%) for reasonably long periods. This makes it difficult to come up with a set of rules for CPU allocation that makes sure the X server gets what it needs (when it needs it) without running the risk of giving other tasks with similar load patterns unnecessary and unintentional preferential treatment.
Quoted 7 lines
Well exactly. This is what the standard scheduler tries to do, and it does have weird starvation and priority problems that pop up.
Quoted 1 line
However, I think that there is still a need for automatic boosts for some tasks. For instance, programs such as xmms and other media streamers are ones whose performance could worsen as a result of the X server being reniced unless it is treated specially and the boost they are given needs to be enough to put them before the X server in priority order. But renicing X would enable a tightening of the rules that govern the automatic dispensing of preferential treatment to tasks that are perceived to be interactive which should be good for overall system performance.
I agree renicing X is helpful.
I've seen different audio players react very differently in the same situations with the same kernel. Are people testing alternatives to make sure it's not just the program being bad? Maybe the people doing these scheduler tests are using all the popular media players and different widely available gui systems to make sure they're not tuning the kernel for a specific program. That should probably be clarified.
I think it ought to be made clear that the gain is being made for a type of program, and not a single one, a type of workload and not a workload consisting of this and that and this program. That can include different windowing systems (xfree86 vs non-free X implimentations or DirectFB) and gtk vs qt vs no toolkit.. This way obvious userspace bugs can be exposed and all this tuning wont be done for helping keep bugs and bad implimentations in use.
Quoted 4 lines · Ed Sweetman
I've seen different audio players react very differently in the same situations with the same kernel. Are people testing alternatives to make sure it's not just the program being bad? Maybe the people doing these scheduler tests are using all the popular media players and different widely available gui systems to make sure they're not tuning the kernel for a specific program. That should probably be clarified.
I think it ought to be made clear that the gain is being made for a type of program, and not a single one, a type of workload and not a workload consisting of this and that and this program. That can include different windowing systems (xfree86 vs non-free X implimentations or DirectFB) and gtk vs qt vs no toolkit.. This way obvious userspace bugs can be exposed and all this tuning wont be done for helping keep bugs and bad implimentations in use.
Unfortunately, the number of apps is far too large for one person to hope to give decent coverage here, let alone all the *combinations* that people use.
We simply have to rely on testers to report problems. Of course I do run my own changes on my desktop, and I have a selection of things to test that have been reported to cause problems in the past...
It would be an idea to set up some regression test machines somewhere for this sort of thing though. Unfortunately I don't have the resources.
Ok I found a problem which alost certainly is responsible in the conversion from nanoseconds to Hz and may if you're unlucky give a blank timeslice. Can you try this (against staircase7.4). I'm almost certain it's responsbile.
Cheers,
Con
P.S.
Sorry about all sorts of different ways I'm sending attachments. I'm away from home and use any email access I can find.
kernel/sched.c +3 -3
@@ -218,8 +218,8 @@ static void dequeue_task(struct task_strstatic void enqueue_task (struct task_struct *p,runqueue_t *rq) { -if (rq->curr->flags &PF_PREEMPTED ) { - rq->curr->flags &= ~PF_PREEMPTED ; +if (p->flags &PF_PREEMPTED ) { + p->flags &= ~PF_PREEMPTED ;list_add (&p->run_list, rq->queue + p->prio); }else list_add_tail (&p->run_list, rq->queue + p->prio);
@@ -330,7 +330,7 @@ static void recalc_task_prio(task_t *p, {unsigned long sleep_time = now - p->timestamp;unsigned long run_time =NS_TO_JIFFIES (p->runtime); -unsigned long total_run =NS_TO_JIFFIES (p->totalrun) + run_time; +unsigned long total_run =NS_TO_JIFFIES (p->totalrun + p->runtime);if ((!run_time &&NS_TO_JIFFIES (p->runtime + sleep_time) <RR_INTERVAL ) || p->flags &PF_FORKED ) { p->flags &= ~PF_FORKED ;
Quoted 5 lines · Con Kolivas
Ok I found a problem which alost certainly is responsible in the conversion from nanoseconds to Hz and may if you're unlucky give a blank timeslice. Can you try this (against staircase7.4). I'm almost certain it's responsbile.
Hmm that will be the problem but that may not compile because of the darn long long division thingy. I'll get a clean patch to you later on that does the same thing, sorry.
Con
Quoted 7 lines · Con Kolivas
Quoted 1 line · Con Kolivas
Ok I found a problem which alost certainly is responsible in the conversion from nanoseconds to Hz and may if you're unlucky give a blank timeslice. Can you try this (against staircase7.4). I'm almost certain it's responsbile.
Hmm that will be the problem but that may not compile because of the darn long long division thingy. I'll get a clean patch to you later on that does the same thing, sorry.
Here's a routine that I use for unsigned 64 bit divides. This is theoretically correct and (just to make sure :-)) thoroughly tested in a user space test program against a proper 64 bit divide. It can't be used to initialize static variables but that's OK because the compiler can do the 64 bit arithmetic itself to correctly initialize them.
static inline unsigned long long sched_div_64(unsigned long long a, unsigned long long b) {
#if BITS_PER_LONG < 64
/*
* Assume that there's no 64 bit divide available
*/
if (a < b)
return 0;
/*
* Scale down until b less than 32 bits so that we can do
* a divide using do_div() (see div64.h).
*/
while (b > ULONG_MAX) { a >>= 1; b >>= 1; }
(void)do_div(a, (unsigned long)b);
return a;
#else
return a / b;#endif
}
Peter
PS If we knew the calling conventions for the library routines (__udivdi3, etc.) that the compiler tries to use to do 64 bit divides we could implement them in the kernel (where necessary) and 64 bit divide problems would become a thing of the past.
Signature · 4 lines
Peter Williams [email protected] "Learning, n. The kind of ignorance distinguishing the studious." -- Ambrose Bierce
Here is an incremental patch from 2.6.7-staircase7.4 (without any later changes) to staircase7.6 which I hope addresses your problem of no timeslice tasks. Can you try it please? Sorry about the previous noise.
Con
P.S.
Those with ck kernels I'm about to post another diff for -ck addressing the same thing.
kernel/sched.c +36 -15
@@ -231,8 +231,8 @@static void enqueue_task (struct task_struct *p,runqueue_t *rq) { -if (rq->curr->flags &PF_PREEMPTED ) { - rq->curr->flags &= ~PF_PREEMPTED ; +if (p->flags &PF_PREEMPTED ) { + p->flags &= ~PF_PREEMPTED ;list_add (&p->run_list, rq->queue + p->prio); }else list_add_tail (&p->run_list, rq->queue + p->prio);
@@ -268,7 +268,10 @@ rq->nr_running++; } -// burst - extra intervals an interactive task can run for at best priority +/* +* burst - extra intervals an interactive task can run for at best priority +* instead of descending priorities. +*/ static unsigned int burst (task_t *p) {unsigned int task_user_prio;
@@ -297,7 +300,10 @@ p->burst--; } -// slice - the duration a task runs before losing burst +/* +* slice - the duration a task runs before getting requeued at it's best +* priority and has it's burst decremented. +*/ static unsigned int slice (task_t *p) {unsigned int slice =RR_INTERVAL ;
@@ -308,7 +314,9 @@return slice; } -// interactive - interactive tasks get longer intervals at best priority +/* +* interactive - sysctl which allows interactive tasks to have bursts +*/ int interactive =1 ;/*
@@ -346,20 +354,25 @@return prio; } +/* +* recalc_task_prio - this checks for tasks that run ultra short timeslices +* or have just forked a thread/process and make them continue their old +* slice instead of starting a new one at high priority. +*/ static void recalc_task_prio (task_t *p,unsigned long long now) {unsigned long sleep_time = now - p->timestamp; -unsigned long run_time =NS_TO_JIFFIES (p->runtime); -unsigned long total_run =NS_TO_JIFFIES (p->totalrun) + run_time; -if ((!run_time &&NS_TO_JIFFIES (p->runtime + sleep_time) < -rr_interval (p)) || p->flags &PF_FORKED ) { +unsigned long ns_totalrun = p->totalrun + p->runtime; +unsigned long total_run =NS_TO_JIFFIES (ns_totalrun); +if (p->flags &PF_FORKED || (!(NS_TO_JIFFIES (p->runtime)) && +NS_TO_JIFFIES (p->runtime + sleep_time) <rr_interval (p))) { p->flags &= ~PF_FORKED ;if (p->slice - total_run <1 ) { p->totalrun =0 ;dec_burst (p); }else { - p->totalrun += p->runtime; - p->slice -=NS_TO_JIFFIES (p->totalrun); + p->totalrun = ns_totalrun; + p->slice -= total_run; } }else {inc_burst (p);
@@ -786,7 +799,9 @@unsigned long flags;runqueue_t *rq =task_rq_lock (current, &flags); -//Forked process gets no burst to prevent fork bombs. +/* +* Forked process gets no burst to prevent fork bombs. +*/ p->burst =0 ;BUG_ON (p->state !=TASK_RUNNING );
@@ -1768,11 +1783,15 @@ cpustat->system += sys_ticks;spin_lock (&rq->lock); -// SCHED_FIFO tasks never run out of timeslice. +/* +* SCHED_FIFO tasks never run out of timeslice. +*/ if (unlikely (p->policy ==SCHED_FIFO )) goto out_unlock; rq->cache_ticks++; -// Tasks lose burst each time they use up a full slice(). +/* +* Tasks lose burst each time they use up a full slice(). +*/ if (!--p->slice) {set_tsk_need_resched (p);dequeue_task (p, rq);
@@ -3601,7 +3620,9 @@for (j =0 ; j <=MAX_PRIO ; j++)INIT_LIST_HEAD (&rq->queue[j]);memset (rq->bitmap,0 ,BITS_TO_LONGS (MAX_PRIO +1 )*sizeof (long )); -// delimiter for bitsearch +/* +* delimiter for bitsearch +*/ __set_bit (MAX_PRIO , rq->bitmap); }/*
Quoted 6 lines · Con Kolivas
Here is an incremental patch from 2.6.7-staircase7.4 (without any later changes) to staircase7.6 which I hope addresses your problem of no timeslice tasks. Can you try it please? Sorry about the previous noise.
Con
P.S.
Those with ck kernels I'm about to post another diff for -ck addressing the same thing.
Eeek that one I posted _was_ the one for ck kernels. This is the one for vanilla kernels with staircase7.4. Crikey I'm having a blowout here.
Con
kernel/sched.c +36 -15
@@ -218,8 +218,8 @@static void enqueue_task (struct task_struct *p,runqueue_t *rq) { -if (rq->curr->flags &PF_PREEMPTED ) { - rq->curr->flags &= ~PF_PREEMPTED ; +if (p->flags &PF_PREEMPTED ) { + p->flags &= ~PF_PREEMPTED ;list_add (&p->run_list, rq->queue + p->prio); }else list_add_tail (&p->run_list, rq->queue + p->prio);
@@ -255,7 +255,10 @@ rq->nr_running++; } -// burst - extra intervals an interactive task can run for at best priority +/* +* burst - extra intervals an interactive task can run for at best priority +* instead of descending priorities. +*/ static unsigned int burst (task_t *p) {unsigned int task_user_prio;
@@ -282,7 +285,10 @@ p->burst--; } -// slice - the duration a task runs before losing burst +/* +* slice - the duration a task runs before getting requeued at it's best +* priority and has it's burst decremented. +*/ static unsigned int slice (task_t *p) {unsigned int slice =RR_INTERVAL ;
@@ -291,7 +297,9 @@return slice; } -// interactive - interactive tasks get longer intervals at best priority +/* +* interactive - sysctl which allows interactive tasks to have bursts +*/ int interactive =1 ;/*
@@ -326,20 +334,25 @@return prio; } +/* +* recalc_task_prio - this checks for tasks that run ultra short timeslices +* or have just forked a thread/process and make them continue their old +* slice instead of starting a new one at high priority. +*/ static void recalc_task_prio (task_t *p,unsigned long long now) {unsigned long sleep_time = now - p->timestamp; -unsigned long run_time =NS_TO_JIFFIES (p->runtime); -unsigned long total_run =NS_TO_JIFFIES (p->totalrun) + run_time; -if ((!run_time &&NS_TO_JIFFIES (p->runtime + sleep_time) < -RR_INTERVAL ) || p->flags &PF_FORKED ) { +unsigned long ns_totalrun = p->totalrun + p->runtime; +unsigned long total_run =NS_TO_JIFFIES (ns_totalrun); +if (p->flags &PF_FORKED || (!(NS_TO_JIFFIES (p->runtime)) && +NS_TO_JIFFIES (p->runtime + sleep_time) <RR_INTERVAL )) { p->flags &= ~PF_FORKED ;if (p->slice - total_run <1 ) { p->totalrun =0 ;dec_burst (p); }else { - p->totalrun += p->runtime; - p->slice -=NS_TO_JIFFIES (p->totalrun); + p->totalrun = ns_totalrun; + p->slice -= total_run; } }else {inc_burst (p);
@@ -764,7 +777,9 @@unsigned long flags;runqueue_t *rq =task_rq_lock (current, &flags); -//Forked process gets no burst to prevent fork bombs. +/* +* Forked process gets no burst to prevent fork bombs. +*/ p->burst =0 ;BUG_ON (p->state !=TASK_RUNNING );
@@ -1746,11 +1761,15 @@ cpustat->system += sys_ticks;spin_lock (&rq->lock); -// SCHED_FIFO tasks never run out of timeslice. +/* +* SCHED_FIFO tasks never run out of timeslice. +*/ if (unlikely (p->policy ==SCHED_FIFO )) goto out_unlock; rq->cache_ticks++; -// Tasks lose burst each time they use up a full slice(). +/* +* Tasks lose burst each time they use up a full slice(). +*/ if (!--p->slice) {set_tsk_need_resched (p);dequeue_task (p, rq);
@@ -3564,7 +3583,9 @@for (j =0 ; j <=MAX_PRIO ; j++)INIT_LIST_HEAD (&rq->queue[j]);memset (rq->bitmap,0 ,BITS_TO_LONGS (MAX_PRIO +1 )*sizeof (long )); -// delimiter for bitsearch +/* +* delimiter for bitsearch +*/ __set_bit (MAX_PRIO , rq->bitmap); }/*
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Quoted 7 lines · you
Quoted 6 lines · Con Kolivas
Here is an incremental patch from 2.6.7-staircase7.4 (without any later changes) to staircase7.6 which I hope addresses your problem of no timeslice tasks. Can you try it please? Sorry about the previous noise.
Con
Quoted 7 lines
Quoted 3 lines
P.S.
Those with ck kernels I'm about to post another diff for -ck addressing the same thing.Eeek that one I posted _was_ the one for ck kernels. This is the one for vanilla kernels with staircase7.4. Crikey I'm having a blowout here.
No, sorry Con.
The problem did not go away.
I just verified, that it definately is no issue with -bk7. So I patched a clean vanilla 2.6.7 to staircase-7.6.
I just double verified that the patch is applied and the correct kernel is loaded.
Quoted 2 lines
Con
- --
Regards Michael Buesch [ http://www.tuxsoft.de.vu ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFA3sOFFGK1OIvVOP4RAkR1AKC/b04v2I5Dt2aoDRdTCiSwDSx7RQCfYJo2 EA2yhCP0Jukv9VbeOjaUrvo=
=WAYD
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Michael Buesch wrote:
| On Sunday 27 June 2004 14:04, you wrote: | |>>Con Kolivas wrote: |>> |>>>Here is an incremental patch from 2.6.7-staircase7.4 (without any later |>>>changes) to staircase7.6 which I hope addresses your problem of no |>>>timeslice tasks. Can you try it please? Sorry about the previous noise. |>>> |>>>Con |>>> |>>>P.S. |>>>Those with ck kernels I'm about to post another diff for -ck addressing |>>>the same thing. |>> |>> |>>Eeek that one I posted _was_ the one for ck kernels. This is the one for |>>vanilla kernels with staircase7.4. Crikey I'm having a blowout here. | | | No, sorry Con. | The problem did not go away. | | I just verified, that it definately is no issue with -bk7. So | I patched a clean vanilla 2.6.7 to staircase-7.6. | | I just double verified that the patch is applied and the correct | kernel is loaded.
The picture fit so well with this bug I fixed I must say I'm suprised. Well don't be sorry; you helped me indirectly track down something that was a real bug I had missed anyway, so this update is necessary regardless. I think for the sake of signal to noise ratio on lkml we should take this discussion off list. Can you email me all the info you have to date about the stalled processes and I'll take it from there?
Con
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFA3sh5ZUg7+tp6mRURAs/XAJ9RRJ1jYiebZaT4YJgsVHfbpYNUqgCeOHzk 8laXqLLVG/pNntdULUnby8w=
=Rvxm
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Quoted 5 lines · you
Hi,
I just applied the patch against 2.6.7-bk7 and saw the following strange thing:
Quoted 9 lines
I was compiling some program, as suddenly compilation stopped. g++ was running (sorry, I didn't look at the process state. Maybe it was in T or something like that), but it didn't get any timeslice. (so didn't execute. Simply stayed around and didn't finish).
I noticed this since I switched from staircase 7.1 to 7.4 a few minutes ago. No such problems before.
I'm not really sure, if it's a staircase problem. Just wanted to let you know.
Oh, forgot to say, that load was quite a bit too high. It was aprox 6.0, but should have been 2.0 (or at absolute maximum 3.0), as there were not so many running processes. There was the g++ at nice 0, some process running at nice 19 and tvtime at nice 0. All other processes were not taking much CPU and sleeping most of the time. (X and KDE was running, but I don't think they can cause this load.)
- --
Regards Michael Buesch [ http://www.tuxsoft.de.vu ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFA3FbzFGK1OIvVOP4RAlgbAJ9eOW2vI/8vv6ZGPDWe6ZmGMW2Y2QCfVN64 DuRJpB+G9FSrenG/rlWA8zo=
=YH0g
-----END PGP SIGNATURE-----