Messages in this thread | | | Subject | Re: Linus 2.6.23-rc1 | From | Kasper Sandberg <> | Date | Mon, 30 Jul 2007 18:13:15 +0200 |
| |
On Sun, 2007-07-29 at 17:04 +0200, Ingo Molnar wrote: > hi Kasper, > > * Kasper Sandberg <lkml@metanurb.dk> 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-) >
I did respond to that one, but perhaps some mail have been getting lost, cause i cant find any more from you in my inbox.
> 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.
I must admit i havent tested the very very latest, will do
> > 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.
Sure.
> > 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:
Well, im not sure how good i would be at maintaining SD, my idea was more or less just do the bare minimum to get the thing running on newer kernels :)
> > 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. >
Actually, now that you mention ogg123, i've had some bugs on CFS with this, i thought it was an ogg123 bug, but now that i remember it its only on CFS i have it.. when i run multiple ogg123 instances, suddenly they will just stop playing and lock up. This happens when someone writes alot fast to me on kopete, where i use ogg123 to play a bling sound..
> 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 majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |