Re: [RESEND][RFC PATCH v2] waitfd

[Oleg Nesterov <oleg@redhat.com>]

On 03/02, Denys Vlasenko wrote:
>
> On Sat, Jan 10, 2009 at 4:57 PM, Oleg Nesterov <oleg@redhat.com> wrote:
> >
> > We do not need multiple signals in queue if we want to reap multiple
> > zombies. Once we have a single SIGCHLD (reported by signalfd or
> > whatever) we can do do_wait(WNOHANG) in a loop.
> >
> > Confused.
>
> I know I am terribly late for the party :)
>
> "do_wait(WNOHANG) in a loop" is a performance problem.

Yes.

> Oleg, do you remember that strace bug when it was swamped
> with gazillions of stop notifications from a multithreaded
> task, then by dealing with them one-by-one it was causing
> unfairness and ultimately "this program never finishes
> when run under strace" bug?

Yes. But, iirc, this was not connected to the performance problems
with do_wait(). The problem was, strace did a single do_wait()
instead of wait-them-all.

> And another typical nuisance that running multithreaded
> stuff under strace is much slower, even with -e option
> which limits the set of decoded syscalls?

IIUC, this is also because strace is single-threaded, I mean it
doesn't scale well.

> Having waitfd would help both cases: strace can gulp
> a lot of waitpid notifications in one go, and
> batch process them.

Perhaps.

I do not know how much do_wait() contributes to the slowness
though. And it is not exactly clear how we can implement the
"fast" waitfd.

For example, this patch (iirc!) just calls do_wait() in a loop.
I doubt very much it can really help to improve the performance.



Oh. Can't resist. The real problem is that ptrace API should
not be per-thread, and it should not use wait() at all. But
this is offtopic.

Oleg.