hi Kasper,
* Kasper Sandberg <lkml@metanurb.dk> wrote:
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.]
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
-
