strace scheduling fairness
oleg at redhat.com
Thu May 17 17:53:04 UTC 2012
On 05/16, Denys Vlasenko wrote:
> On 05/16/2012 11:48 AM, Dmitry V. Levin wrote:
>>> One solution is to run waitpid() in a loop until it returns 0 "no more tracees
>>> to wait", then handle them all. It was NAKed a few years ago.
>> It would be nice to have a look at that discussion. Do you have a
>> reference? What was the rationale that time?
> I guess Roland saw it as "ugly" and "trying to work around ptrace API
> which is a hopelessly bad API anyway".
It is indeed ugly and hopeless. But perhaps Roland hoped we can have
something new. Now that utrace is dead, unlikely this is possible.
> On the technical note, it adds additional waitpid call per every
> syscall entry/exit, and serializes strace even more: instead of
> servicing and restarting a thread as fast as we can, we collect
> other threads - keeping ready threads stuck a bit longer.
But what else we can do to fix the problem? (lets not discuss
the vectorized do_wait right now ;)
Imho, you should reconsider your patch.
> I looked into in and _maybe_ signalfd may help us noticeably.
> for one, some SIGCHLDs can be lost.
yes, SIGCHLD doesn't queue.
More information about the Strace-devel