You might want to look into the schedulers a bit more. Just because they're
different, doesn't necessarily mean that a typical server process (like srcds)
will run any more effectively under SCHED_RR versus SCHED_OTHER. To prove
this, someone would actually have to benchmark it.
While I
Hi,
thanks for the feedback.
I'm not sure either about the effects of such scheduler change on orangebox.
I'm just asking if *please* it's possible to have a switch into the
command line that disables those scheduler changes that orangebox tries
by itself anytime map is loaded.
Those tries
On 01/10/2012 20:35, Marco Padovan wrote:
Those changes happens only when running the server as root, if you do
not run it as root those changes fails and the scheduler/priority is not
changed...
Well no, that's not strictly the case. You can allow the changes without
being root
as others
On a clean centos or debian install the server will make use of a better
scheduling algorithm if run as root.
At this point if nothing changes I'm sure we will see many people
running it as root in order to achieve better performance without having
to modify a clean centos /debian install
Il
On 03/10/2012 20:21, Marco Padovan wrote:
On a clean centos or debian install the server will make use of a better
scheduling algorithm if run as root.
At this point if nothing changes I'm sure we will see many people
running it as root in order to achieve better performance without having
to
Sorry, I'm not much interested to discuss with you further about this
whole thing.
I'm just asking to the dev to please take out these lines of codes
making the processes self changing the scheduler and the priorities.
Il 03/10/2012 21:38, dan ha scritto:
On 03/10/2012 20:21, Marco Padovan
If Valve put thread priority changing code, they did it with a specific
purpose in mind.
I'm pretty sure they won't change it because one bad server operator who
runs a poorly configured server is complaining very ineloquently about how
it can mess up an improperly configured system.
On Wed,
Ok, thanks
Il 03/10/2012 22:45, Eli Witt ha scritto:
If Valve put thread priority changing code, they did it with a specific
purpose in mind.
I'm pretty sure they won't change it because one bad server operator who
runs a poorly configured server is complaining very ineloquently about how
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
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
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
Those changes happens only when running the server as root, if you do
not run it as root those changes fails and the scheduler/priority is not
changed...
So if you do not run srcds_linux as root nothing changes... it's like
those lines where not there :S
Leaving all the benchmarks and hyphotesis
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.
and
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
AM
To: hlds_linux@list.valvesoftware.com
Subject: Re: [hlds_linux] srcds_linux changing its own process priority at
start (centos)
: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
-
From: hlds_linux-boun...@list.valvesoftware.com
[mailto:hlds_linux-boun...@list.valvesoftware.com] On Behalf Of Marco Padovan
Sent: Saturday, September 29, 2012 10:38 AM
To: hlds_linux@list.valvesoftware.com
Subject: Re: [hlds_linux] srcds_linux changing its own process priority
...@list.valvesoftware.com [mailto:
hlds_linux-boun...@list.valvesoftware.com] On Behalf Of Marco Padovan
Sent: Saturday, September 29, 2012 10:38 AM
To: hlds_linux@list.valvesoftware.com
Subject: Re: [hlds_linux] srcds_linux changing its own process priority at
start (centos)
:D
btw I hope
Hi,
on centos5 and centos6 we are seeing srcds_linux that automatically
increase his own priority when creating the game threads
I just start tf2 using srcds_run with the usual commands line, but it
automatically tries to push his own priority higher as soon as it
creates the threads...
Is that
On my ubuntu system srcds_linux has a priority of 20 (nice value 0),
which is the default for regular user processes. So no, I'm not seeing
the behaviour you describe. I also don't see anything in the srcds_run
script that looks like it's trying to increase process priority.
On Sat, Sep 29, 2012
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
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
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
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, 10fps here I come :D
Il 29/09/2012 19:03, Marco Padovan ha scritto:
Hi,
thanks for your feedback, never run
Next step: Run the srcds_linux in kernel mode:
http://web.yl.is.s.u-tokyo.ac.jp/~tosh/kml/
2012/9/29 Marco Padovan e...@evcz.tk:
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
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
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
I see this spammed hundreds of times every map change:
7588 22:52:42.714760 sched_setscheduler(7588, SCHED_RR, { 0 }) = -1
EINVAL (Invalid argument)
7588 22:52:42.715275 sched_setscheduler(7588, SCHED_RR, { 2 }) = 0
... unexpected but has a nice side-effect for my servers - I have a
script
nice catch!!!
didn't notice those log lines.
faking sched_setscheduler seems an interesting way to make it act
normale again :)
hope valve will step in and add an official and supported way to take
this out :)
Il 29/09/2012 23:38, Adam Nowacki ha scritto:
I see this spammed hundreds of times
28 matches
Mail list logo
