Re: Voluntary Preemption + concurent games

[Aivils]

On Monday 12 July 2004 12:51, Con Kolivas wrote:
> > 	I still use in my home minicomputer under Linux, where
> > 3 users use one CPU/RAM , but own video.
> > 	By default 2.6.XX task scheduler don' t like concurent applications
> > at all. 2.6.XX task scheduler allways raise on top of tasks only one
> > task and keep it on top until user stop it.
> > 	This rule is very unwanted for minicomputers, because multile
> > local users will use one CPU and feel lucky.
> > 
> > 	As point of reference i use 2.4.XX tack scheduler, which is very
> > "righteous" and allways give CPU time for all tasks. Under 2.4.XX
> > concurent games run smooth.
> > 
> > 	2.6.XX non-preemptive and 2.6.XX voluntary-preemptive task
> > scheduling looks very similar. My gamer' s eye report me very
> > thiny and very subjective difference - preferable is voluntary-preemtive.
> > Anyway all concurent CPU intensive tasks should be started with
> > nice -n +19 game-bin . Any other nice value remake one of
> > running game to slide show or both running games became slide show.
> > 
> > 	So we should start any game with nice +19. In is this set goes in
> > netscape and konqueror because of java web-chat and games.
> > 
> > 	At least voluntary-preemptive allow me move away from 2.4.26
> 
> I'm not sure I understand you. You said that voluntary preempt and 
> preempt look the same yet in your last line you say voluntary preempt 
> allows you to move away from 2.4.26?

Before moving away from 2.4.26 was insane for me. I check out
vanilla and Your kernels and reboot back to 2.4.26 as soon as i can.
My decision is _subjective_.

I will more play games neither measure miliseconds :)
I do not know how to profile all 4-5 threads of game, epspecialy if
runs two copies. Video, audio, net, game-logic latency ?

> Anyway apart from that comment I'm not really sure how you can address 
> this because if nice +19 works at smoothing out the games then that 
> almost surely suggests a yield() implementation in your games. 
> Unfortunately this, I noticed while coding my new scheduler policy, 
> seems to be _very_ common. There were lots of "big name" new games that 
> did the same thing. It was decided quite a while back in 2.5 development 
> that applications that use yield() for locking were broken by design. If 
> nice +19 fixes the problem then all I can suggest for the time being is 
> to use nice +19. The fact that the current processor is much more 
> out-of-order in it's scheduling is what is fooling these applications 
> now, and their unfortunate programming suffers in that setting.

Seems magic touch is "nice +19" , scheduler independ.

> What you need to cope with this is gang scheduling, but that's absurd to 
> implement such a complicated policy to cope with poor application 
> coding. Gang may be implemented in the future for different reasons, though.

Actulay i do not need because 2.4.XX do all things. 
I will notify developers about exisiting of trouble.
sched.c developers do all counter my needs :)

Aivils
-
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/