Is it specific to 3D? I would not think so. dosbox, bochs should have
the same issue. Games with "a lot of motion" usually implement their event
handling and screen drawing in a busy loop to get the maximum possible
frame rate.
Usually, only the GL thread would need to run at full power, and reducing the
input subsystem to a simple event-based loop (for example reading a pipe in
blocking mode). This could IMO makes games a bit more responsive.
However, most games combine the input subsystem and graphics output in one
thread. Due to the way CFS works, it may mean that processes get scheduled
too fair, though I'd suspect that a GL busy loop has no interactivity bonus at
all anyway in the old scheduler or SD.
I/O is also something that can hurt games in their framerate and/or handling
(something the user cares most about). Since I have not tried 2.6.23-rc yet, I
can only speak for the old scheduler. I have always turned cron off so that
updatedb does not run, because it makes games sluggish for some reason,
even though updatedb (or subordinate processes) don't take a lot of CPU time
according to `top`. What's more, running BOINC in the background (nice 20)
while running unreal (nice 0), everything is ok.
(But not if BOINC is at nice 0).
Time to investigate...
Jan
--
-
