While I realize syscalls are not the whole picture, it's a nice easy
start. Note, the above was taken with libfasttime.so, without this,
gettimeofday would dominate my cpu.
3182 futex(0xf6e6e33c, FUTEX_WAKE_PRIVATE, 1) = 0
3182 futex(0xf6e6e358, FUTEX_WAIT_PRIVATE, 13044897, {0, 49981604}
<unfinished ...>
3182 <... futex resumed> ) = -1 ETIMEDOUT (Connection timed out)
3182 futex(0xf6e6e33c, FUTEX_WAKE_PRIVATE, 1) = 0
While there are quite a few time calls in between there, this is the
abridged version. EAGAIN only appeared with socket/network related
calls. I should probably also note my load wasn't nearly as high. I'll
verify it's the same case when SRCDS is maxed later today.
On Wed, May 25, 2011 at 9:53 AM, Gary Stanley <[email protected]> wrote:
> At 01:32 AM 5/25/2011, Kyle Sanderson wrote:
>>
>> While this has been discussed a number of times (atrocious over usage
>> of gettimeofday has been worked around). Can there be something done
>> regarding the abuse of syscalls? I mean, something like this
>> http://i.imgur.com/PdWTB.png isn't really that great. For instance,
>> every 1 out of 4 futex syscalls fail due to timing out (shown in that
>> picture). This is just expensive and downright silly. Not much can be
>> done on our end without the source to SRCDS, which no doubt will not
>> be released. The CPU usage that SRCDS manages to chug is borderline
>> suicidal for the end result, not to mention the countless places in
>> the engine where memory continues to leak like a sieve. This effects
>> and hurts everyone. The 'serious' people who host servers cannot use
>> Windows due to the lack of Symbols.
>
> Abuse of syscalls? No offense, but strace/ktrace/truss et al only show
> syscalls, not flow of code! It measures the amount of syscalls and usage of
> them in CPU time. I could write a program to loop main() and chew up 99% CPU
> and no syscalls will be generated.
>
> Maybe you could post what is timing out? It's probably doing EAGAIN over and
> over..
>
> strace -Ff -s 99999 -p whatever
>
>
>
>
>
> _______________________________________________
> To unsubscribe, edit your list preferences, or view the list archives,
> please visit:
> http://list.valvesoftware.com/mailman/listinfo/hlds_linux
>
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlds_linux
