strace scheduling fairness

[Oleg Nesterov]

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.

unlikely, because

> for one, some SIGCHLDs can be lost.

yes, SIGCHLD doesn't queue.

Oleg.