you were right ... if you run it as root it make use of the realtime
scheduler and set itself to -3 as priority...

is this normal?

"ZOMG running az r00t makes it quicker and faster, 100000fps here I come" :D

Il 29/09/2012 19:03, Marco Padovan ha scritto:
> Hi,
>
> thanks for your feedback, never run the server as root so I never
> noticed this *weird* behaviour :S
> This specific unprivileged user (/*not root*/) I'm doing the tests
> with is allowed to set realtime scheduler for its own processes.
>
> Kernel is: 2.6.32-279.9.1.el6.x86_64 (official binary shipped by centos)
>
> What I can't understand is why srcds_linux tries to do such change on
> its own... If I wanted to see it make use of realtime scheduler I
> would do that when starting... I do not like processes doing things by
> their own :S
>
> Additionally this kind of behaviour would make people run the
> gameservers as root because it will magically performs "better" thanks
> to the automatic scheduler changes :O
> Are we opening a Pandora's box? :D
>
>   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
> 13660 testtf2   -3   0  288m 174m  19m S  9.6  1.5   0:10.58 srcds_linux
> 13653 testtf2   20   0  103m 1568 1224 S  0.0  0.0   0:00.00 srcds_run
>
>
> pid 13660's current scheduling policy: SCHED_RR
> pid 13660's current scheduling priority: 2
>
> pid 13653's current scheduling policy: SCHED_OTHER
> pid 13653's current scheduling priority: 0
>
> let me see what happens when running as root :)
>
>
>
> Il 29/09/2012 18:35, Ulrich Block ha scritto:
>> Am 29.09.2012 18:30, schrieb Marco Padovan:
>>> Hi, thanks for your reply.
>>>
>>> In my case it is not srcds_run doing that, it's srcds_linux that does
>>> something.
>>>
>>> "priority" changes a few seconds after srcds_linux has started (right
>>> after "create 4 threads" gets printed into the console log).
>>>
>>> In my case it's changing its own scheduling parameters moving from the
>>> SCHED_OTHER into SCHED_RR.
>>
>> Which kernel are you using? And most importantly which user runs the
>> server? I saw such a behaviour when someone was running everything
>> with root.
>>
>> A normal system user should not have the permission to change the
>> prio or the scheduling. The root user does.
>>
>>
>>
>> _______________________________________________
>> To unsubscribe, edit your list preferences, or view the list
>> archives, please visit:
>> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux
>

_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives, please 
visit:
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux

Reply via email to