hi Kasper, * Kasper Sandberg <[EMAIL PROTECTED]> wrote:
> Im still not so keen about this, Ingo never did get CFS to match SD in > smoothness for 3d applications, where my test subjects are quake(s), > world of warcraft via wine, unreal tournament 2004. And this is > despite many patches he sent me to try and tweak it. [...] hey, i thought you vanished from the face of the earth :-) The last email i got from you was more than 2 months ago, where you said that you'll try the latest CFS version as soon as possible but that you were busy with work. I sent 2 more emails to you about new CFS versions but then stopped pestering you directly - work _does_ take precedence over games =B-) CFS v14, v15, v16, v17, v18 and v19 was released meanwhile, CFS v20 went upstream, there were no 3D related CFS regressions open for quite some time and because i never heard back from you i assumed everything's peachy. In any case i'm glad you found the time to try CFS again, so please let me know in what way it regresses. In your most recent emails you did not indicate what specific problem you are having (and you did not reply to my last emails from May) - are your old regression reports against CFS v13 from May still true as of v2.6.23-rc1? If they are, could you please indicate which specific report of yours describes it best and send me (or upload to some webspace) the specific .config you are using on your box, and the cfs-debug-info.sh snapshot taken when you are running your game. (make sure you have CONFIG_SCHED_DEBUG=y enabled, for highest quality debug output) You can pick the script up from: http://people.redhat.com/mingo/cfs-scheduler/tools/cfs-debug-info.sh Giving us that info would help us immensely with tracking down any CFS problem you might still be having. Or, if you feel adventurous enough to look into the internals of the kernel (which, considering your offer to take up SD maintenance, you must be ;-), here's my kernel latency tracer: http://people.redhat.com/mingo/latency-tracing-patches/ ( see: latency-tracer-v2.6.23-rc1-combo.patch ) the simplest way to use it is to enable CONFIG_WAKEUP_TIMING, to set /proc/sys/kernel/preempt_max_latency back to 0 (after bootup) and to thus measure raw worst-case scheduler latencies - if you regularly see the kernel report above say 1000 usecs latencies to the syslog, on a PREEMPT kernel then there's definitely something foul going on. For example, that's how i found an audio playback latency problem in an early version of CFS: ( sshd-14614|#1): new 5 us maximum-latency wakeup. ( ogg123-6603 |#1): new 6 us maximum-latency wakeup. ( ogg123-6608 |#1): new 6 us maximum-latency wakeup. ( sshd-14614|#1): new 10 us maximum-latency wakeup. ( ogg123-6607 |#0): new 15 us maximum-latency wakeup. ( events/0-9 |#0): new 789 us maximum-latency wakeup. ( ogg123-6603 |#0): new 2566 us maximum-latency wakeup. that 2.5 msecs latency in the ogg123 task was definitely the sign of a kernel bug. If plain WAKEUP_TIMING does not show anything suspicious, you can use the latency tracer in more advanced ways as well to trace the whole system and figure out the precise cause of your game latencies - i'll be glad to help with that if no simpler measure helps. [see trace-it.c for some of those details.] > [...] As far as im concerned, i may be forced to unofficially maintain > SD for my own systems(allthough lots in the gaming community is bound > to be interrested, as it does make games lots better) i'd encourage you to do it - in fact i already tried to prod Peter Williams into doing exactly that ;) The more reality checks a scheduler has, the better. [ Btw., after the obvious initial merging trouble it should be much easier to keep SD maintained against future upstream kernels due to the policy modularity that CFS introduces. (and which policy-modularity should also help reduce the size and complexity of the SD patch.) ] Thanks, Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
