I upgraded from 2.4.19-r10 to 2.4.20-r1 and noticed, that when dnetc (distributed.net) client is running (at low priority) playing OpenGL games is almost impossible. Any serious OpenGL application basically runs for 0.5 sec, then freezes for 0.5, then runs again. Kernel config is unchanged, I compiled kernel without low-latency in kernel, also tried with low-latency compiled in and both states: disabled and enabled - no difference. OpenGL is NVIDIA drivers version 3123. System is P3 600MHz 512MB with GeForce2MX400. glxgears with dnetc enabled runs 10x slower than w/o dnetc. Sound in games is OK, some minor glitches compared to 2.4.19 in HalfLife under winex. Disabling dnetc solves the problem. Any directions worth to investigate? Preempt?
I'm talking about gentoo-sources.. Priorities doesn't work in 2.4.20-r1. Look at this top output: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ Command 1170 arkadi 25 0 1684 1684 1284 R 50.7 0.3 0:09.57 bash 1024 arkadi 39 19 540 540 480 R 47.4 0.1 15:55.29 dnetc dnetc have nice == 19, but it consume 50% of the cpu. bash is running while :;do echo >/dev/null; done On Debian 2.4.20 system: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ Command 966 arkadi 18 0 1736 1736 1608 R 85.1 0.3 0:07.54 bash 506 arkadi 19 19 512 512 452 R 13.9 0.1 227:56.34 dnetc
this also seems to happen in latest lolo ... but i havent done an quantitative tests
My niced processes like folding at home still take up about half the cpu time when they should be idleing with the latest gentoo, ck, and lolo sources. I think this is a result of some of ck's patches.
For all of those using background tasks such as sob (Sierpinski conjecture), zetagrid (numerous gentoo users are doing this) this bug makes this specific kernel almost unusable... (I experienced it too, the task that should have been idle was still indeed using 50% of the cpu) It looks like this bug has not been fixed. Is the time then appropriate to make it in the stable branch (x86) ? (I remember I had other problems, dependancies like, with this kernel as well, and if I can reproduce them, I will post them in a separate bug)
Gargle, this is terrible, I may have to move htis back ti unstable unless I can find a quick fix for it. Looking into it... (sorry I took so long to respond to this bug)
The gentoo-sources-2.4.20-r1 are still marked as stable. There is still this bug with them?
Yes, this is still present on my system; things to look for (which I'm going to play with tonight or tomorrow) are combinations of optimizations; does this occur with preemption and low-latency disabled? With Just low-latency or just pre-empt? Hopefully the issue is not with the scheduler itself, as to my knowledge it is providing the biggest boost in performance for general use.
For those with this issue. Please emerge the latest lolo-sources (lolo-2.4.20.2_pre5). Read the changelog before you play as this a prerelease. I just uploaded the new ebuild to CVS around 10 minutes ago. It should be available at least on OSU's mirror shortly. Thanks, Jay
This is of interest: * removed ck4 O(1) sched, ll, preempt patch * added rml preempt & ll Is there a difference between CK's ll & preempt and rml's? Or is it simply a matter of the patch rml created vs. ck's? Trying it now.
lolo-2.4.20.2_pre5 priorities works fine for me. My kernel is compiled w/o lowlat and w/o preempt.
gentoo-sources-2.4.20-r2 (which is ~x86) has the priorities fixes and the new ptrace patch. Jay
http://lists.q-linux.com/pipermail/plug/2002-November/022984.html This may be of interest with regard to the O(1) scheduler; evidently a further utility must be used to control the niceness of processes, chbatch. This is new and the indication is this will change in future revisions of the scheduler, either in userland or in-kernel, so the inclusion of the scheduler in gentoo-sources is still debatable. A USE flag would suffice, which would add an RDEPEND on schedutils and a post_install notice on how to use them.
schedutils is put out by rml. chbatch has been removed and replaced by chrt. the latest 1.1.0 has been tested by me but causes a hard lock when implemented with the O(1) sched and the stuff from ck4. i have looked at putting out an updated ebuild when O(1) is safely reintroduced. unfortunaltely until all is worked out this won't be ready for gentoo. Jay
process priorities were fixed in gentoo-sources-2.4.20-r2. Closing. Jay
