[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 2/2] Rewrite gsync so that it works with remote tasks v2

From: Agustina Arzille
Subject: Re: [PATCH 2/2] Rewrite gsync so that it works with remote tasks v2
Date: Mon, 06 Mar 2017 15:24:16 -0300

Hello, Samuel

On 2017-03-04 18:45, Samuel Thibault wrote:

Do we really want to keep that list sorted?  That makes waking up two
times less expensive, but it makes waiting much more expensive, so
overall it's just the same.

And I'd think that in practice, there is more probability that the
thread to be woken up was queued last, for temporal locality reasons,
and so keeping the list sorted is actually more expensive than just
queueing at the head and looking up starting from the head :)

You make a good point, and it's likely that sorting the list is simply
a case of "premature optimization". I'll try things out without sorting.

On 2017-03-04 18:54, Samuel Thibault wrote:
There is the broadcast case which would then have to go through the
whole list instead of half of the list in average.  I'd however tend to
prefer to optimize the non-broadcast case over the broadcast case, since
broadcasts are rare.

Indeed, broadcasts are really only used for shared condvars, and in some
places internally, by glibc.

On 2017-03-04 19:00, Samuel Thibault wrote:
Ah, there is also the splicing done in requeue. Is that a common
scenario?  I don't see it used within glibc, for instance.

Requeue is only used for task-local condvars, as an optimization, in order
to avoid the infamous 'thundering herd' issue.

On 2017-03-04 19:35, Samuel Thibault wrote:

Did you actually try with rpctrace?  It seems to be breaking it. For
AIUI, the problem is that rpctrace uses only one thread to do the
tracing, and since gsync_wait is blocking the RPC, the whole rpctrace
gets blocked.  Unfortunately, that prevents from commiting such change,
since not being able to rpctrace a threaded program is really a concern.

Ah, my bad. No, I didn't manage to try it with rpctrace. What I tried was passing around the rights for a task, and have a different task wait on a
remote address, or wake a waiter with gsync.

I think this is a limitation with rpctrace. From what I gather, it used to
work on multi-threaded programs because libpthread used to use barebones
'mach_msg', which, not being a true RPC, wasn't being traced.

I'll see what I can do, although I'm not at all familiar with how rpctrace
internally works.

On 2017-03-04 19:44, Samuel Thibault wrote:
(thus related with Brent's "multithread rpctrace to avoid deadlocks in
the kernel" patch)

Could be. I'm a bit puzzled as to why rpctrace uses a single thread to trace
every RPC in a program.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]