On 01/10/2012 09:54, Marco Padovan wrote:
the problem is that in certain cases it is *LOWERING* it's own
priority... and more importantly *CHANGING* to a different scheduler...
And? You said running under root would have better performance - the
implication being that these calls would succeed
in that scenario and hence what it's doing is, in fact, a good thing tm.
Now you're arguing that the changes it makes are in fact detrimental to
the running of the game.
Either way, decide whether you want to allow the calls to succeed or
not, and you have the option to change your system the game runs on
to that end.
setting something SCHED_RR could cause big troubles if your system is
not setup properly
You know what I'm going to say next, don't you?
Set it up properly then :)
additionally there's no reason at all to keep spending time and throwing
away resources in trying to change the scheduler and the priority as on
99.999999999999% of the systems that will fail and will result just in
losted CPU cycles....
It'd be absolutely insignificant I'm sure of that.
Someone said "every map change" - that's not typically less than 30-40
minute intervals, quite often more than that, at a
time when there's nothing particularly performance critical happening.
Let's face it, to kludge around the issue with sv_pure changing between
servers, and possibly related to a crash at exit (that didn't really
matter because it was at exit)
Valve added, I'm guessing, a call to reload_allmaterials or something
completely lazy, slow and overkill like it. So the disconnect / map
change cycle on the client is now
painfully and embarrassingly slow (at least I hope they are embarrassed.
I would be. Even if my boss said I could write whatever code I thought
most important I wouldn't use
that privilege to hide ugly kludges to workaround things nor to ignore
bugs for months or years that I couldn't recreate)
So, feedback / rant aside, we all know that the whole game client hangs
and is unresponsive on map change, server disconnect and so on.
This happened anyway at map change but is now worse than ever (and it's
more noticeable when you put a 'cancel' button and the shift-tab interface
in there because obviously these are unresponsive too for a fair %age of
the cycle)
Now you can't even disconnect from a server without having to wait for a
few seconds thinking
"this Valve guy must have cribbed all the answers to the interview
puzzles from his Uni pals"
Although, to be fair, Valve solved the performance issue the above
created to anyone server hopping to find a good round by
getting rid of all their servers and / or configuring them so there are
no rounds at all, let alone good ones.
Clever, in a way, I suppose, but it does feel like having the rug pulled
from under your feet especially because pretty much
every 3rd party server has some screw up with it's configuration
(usually relating to sv_minrate but some are more creative)
Thank goodness borderlands 2 came out :)
But, give them the benefit of the doubt, perhaps these pthread_ things
are good. If they are called at map change be assured no one running the
client cares what the server is doing
certainly not whether it makes an extra system call or two, whether it
succeeds or not. They have their own performance issue - one that really
is worth fixing properly.
If it creates these worker threads more often than that, I'd be amazed
if there was any significant overhead added
to thread creation by it. But you can convince me.
Let's not wave hands. Do you have numbers? Is it quicker with the
priority changes or not? If we assume Valve applied
them for a reason you probably want to allow them (but not by running as
root) If it's not
quicker, then stop them but I wouldn't fret about overhead.
--
Dan
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux
