Re: Linus 2.6.23-rc1

[Kasper Sandberg <lkml@metanurb.dk>]

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/