the problem is that in certain cases it is *LOWERING* it's own priority... and more importantly *CHANGING* to a different scheduler...
setting something SCHED_RR could cause big troubles if your system is not setup properly (starvation for anything else running with the usual SCHED_OTHER) that's why doing such kind of radical changes should be up the system or to external hands that have a wider view of that specific server... btw the problem is not whatever or not should I do... but whatever or not should I be able to control what srcds_linux does by itself... 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.... Il 01/10/2012 08:58, dan ha scritto: > On 30/09/2012 16:52, Marco Padovan wrote: >> Il 30/09/2012 17:35, dan ha scritto: >>> On 29/09/2012 18:37, Marco Padovan wrote: >>>> :D >>>> >>>> btw I hope someone from Valve will clarify about this behaviour so at >>>> least we can understand if making servers run as root "better but more >>>> expensive" is an intender behaviour >>> No, running as root is obviously not intended for security reasons. >> But it gives better performance out of the box as things are currently. >> And you cannot argue on that. > > I can. Changing scheduling priority won't magically turbo boost the > program running. > It's only relative to other things running on the machine. > > (It seems from Tony's response they want some threads running at a > different priority from the rest of the game) > > Given that most game servers are usually only running the game, I > doubt it makes much difference to performance whether you run the game > as root or not. If it does because of these pthread_ calls, I'm sure > you don't need to run as root to allow them. > > Even with n copies of the game on a server, if they all set their > priority to the same higher or lower priority it'll make no difference. > > Years ago kids in CS 101 would set their programs running with higher > priority believing somehow the nice level was like a turbo boost. Of > course, for the first few to try it, it appears to be just that - > because they get more cpu cycles. Until every kid in the class does it > and then they are all back to square one with their programs running > just as fast as they would if they had left the priority at the default. > > So, if you've something running on your server that's hurting the > performance of TF2, you'd be better stopping that process rather than > running as root. > > >>>> and if there's a way around that to >>>> suppress this kind of "self changes tries" srcds_linux does :) >>> This is obvious too, don't give the user that runs the game the >>> privileges to change priority >> brilliant. >> >> what else should I expect from srcds_linux? >> what's the point in doing hundreds of system calls to >> sched_setscheduler() if it's expected to fail? >> will we see it doing a 32mb precision PI calculation every map change in >> future? should I deny access to some specific math function into the CPU >> in such case? > > Well, you asked if there's "a way around that to suppress it". I told > you how to easily workaround it. > So your sarcasm isn't really fitting. > > If you want the call overhead removing, remove the library / system > calls so the process does nothing. But that seems overkill. Perhaps > Valve will remove it, or justify it. > > (Did linux not come with source code anymore? People are telling me > that Linux 2.6.12 cannot do this and that. It can do anything you want > it to do and more. Making it not do something is no great task) > > I've even heard rumours they are getting it to run L4D2 :) > _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux
