On Tue, 8 Jul 2003 17:11, Szonyi Calin wrote:
> Con Kolivas said:
> > Thanks to Felipe who picked this up I was able to find the one bug
> > causing me grief. The idle detection code was allowing the sleep_avg to
> > get to ridiculously high levels. This is corrected in the following
> > replacement O3int patch. Note this fixes the mozilla issue too. Kick
> > arse!!
> > Con
> Not really.
Ok kick my butt instead so I can try and fix it.
> No change on my system.
> No fancy gui (just fvwm). Testing is very simple:
> In one xterm window make bzImage
> in other mplayer /some/movie.avi
> ... and the movie is jerky :-(
Can you tell me how it compares to vanilla at all, and can you watch top and
see what dynamic priorities are reported for the cc and mplayer processes
while it's running?
> In the weekend i did some experiments with the defines in kernel/sched.c
> It seems that changing in MAX_TIMESLICE the "200" to "100" or even "50"
> helps a little bit. (i was able to do a make bzImage and watch a movie
> without noticing that is a kernel compile in background)
Strong resistance to dropping the timeslices will remain. If you want to do
this, try adding the granularity patch instead which works better. Neither
will become mainline changes I'm afraid.
> system is AMD DURON chipset via KT/KM 133, Ati Radeon VE.
> I remeber with nostalgicaly about the times when i could (with a 2.5
> kernel) do a make -j 5 bzImage AND watch a movie in the same time
<sigh> If it were still the case I wouldn't be spending hundreds of hours
doing this :|
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Jul 15 2003 - 22:00:26 EST