Re: 2.6 vs 2.4 regression when running gnomemeeting
From: Nick Piggin
Date: Fri Dec 19 2003 - 20:28:23 EST
Christian Meder wrote:
On Sat, 2003-12-20 at 01:48, Nick Piggin wrote:
Sounds reasonable. Maybe its large interrupt or scheduling latency
caused somewhere else. Does disk activity alone cause a problem?
find / -type f | xargs cat > /dev/null
how about
dd if=/dev/zero of=./deleteme bs=1M count=256
Ok. I've attached the logs from a run with a call with only an
additional dd. The quality was almost undisturbed only very slightly
worse than the unloaded case.
OK, its probably not that then. Try the find command though, it would
be closer to what make/gcc is doing.
You said it faired slightly better with my scheduler when renicing
gnome meeting to -10. How much better is that?
Worse than unloaded and worse than the disk loaded case from above. But
all (CPU) loaded cases were producing almost complete audio dropouts
while with your scheduler and renicing to -10 I got at least a
stuttering audio stream (a regular pattern of very short slices of audio
mixed with very short slices of silence).
So it does sound like scheduling latency then. Its difficult to find
out what is happening with top and vmstat because they don't give you
an idea of individual scheduling events, which is what is important
for things like this. I'll have a look into making up a patch to gather
what I want to know.
In the meantime, I have a newer scheduler patch against 2.6.0 you could
try: http://www.kerneltrap.org/~npiggin/v28p1.gz
Try nicing the compile to +19 if it still stutters.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/