Messages in this thread | | | From | Con Kolivas <> | Subject | Re: [PATCH] mm: yield during swap prefetching | Date | Thu, 09 Mar 2006 10:00:02 +1100 |
| |
Zan Lynx writes:
> On Wed, 2006-03-08 at 14:05 +1100, Con Kolivas wrote: >> André Goddard Rosa writes: >> >> > [...] >> >> > > Because being a serious desktop operating system that we are >> >> > > (bwahahahaha) means the user should not have special privileges to run >> >> > > something as simple as a game. Games should not need special scheduling >> >> > > classes. We can always use 'nice' for a compile though. Real time audio >> >> > > is a completely different world to this. >> > [...] >> >> Well as I said in my previous reply, games should _not_ need special >> >> scheduling classes. They are not written in a real time smart way and they do >> >> not have any realtime constraints or requirements. >> > >> > Sorry Con, but I have to disagree with you on this. >> > >> > Games are very complex software, involving heavy use of hardware resources >> > and they also have a lot of time constraints. So, I think they should >> > use RT priorities >> > if it is necessary to get the resources needed in time. >> >> Excellent, I've opened the can of worms. >> >> Yes, games are a in incredibly complex beast. >> >> No they shouldn't need real time scheduling to work well if they are coded >> properly. However, witness the fact that most of our games are windows >> ports, therefore being lower quality than the original. Witness also the >> fact that at last with dual core support, lots and lots (but not all) of >> windows games on _windows_ are having scheduling trouble and jerky playback, >> forcing them to crappily force binding to one cpu. > [snip] > > Games where you notice frame-rate chop because the *disk system* is > using too much CPU are perfect examples of applications that should be > using real-time. > > Multiple CPU cores and multithreading in games is another perfect > example of programming that *needs* predictable real-time thread > priorities. There is no other way to guarantee that physics processing > takes priority over graphics updates or AI, once each task becomes > separated from a monolithic main loop and spread over several CPU cores. > > Because games often *are* badly written, a user-friendly Linux gaming > system does need a high-priority real-time task watching for a special > keystroke, like C-A-Del for example, so that it can kill the other > real-time tasks and return to the UI shell. > > Games and real-time go together like they were made for each other.
I guess every single well working windows game since the dawn of time is some sort of anomaly then.
Cheers, Con
[unhandled content-type:application/pgp-signature] | |