Yes, you are right: a "realtime scheduler" does not exists.

SCHED_RR is just a scheduler generally used in realtime linux
implementations ( SCHED_RR + PREEMPT_RT = process running in realtime)

BTW, back to the main issue: the process changes its own priority (to
-3) and the scheduler is changed to SCHED_RR ... why that happens? how
can I stop that from happening?

Il 29/09/2012 22:01, Russell Smith ha scritto:
> SCHED_RR is round robin scheduling, not real time.
>
> Marco Padovan <e...@evcz.tk> wrote: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
> _______________________________________________
> 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