Re: Voluntary Preemption + concurent games

[Con Kolivas <kernel@kolivas.org>]

[-- Attachment #1: Type: text/plain, Size: 2372 bytes --]

Aivils writes:

> Hi All!
> 
> 	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?

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.

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.

Con

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]