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

[Agustina Arzille]

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:
> Hello,
>
> Did you actually try with rpctrace?  It seems to be breaking it. For
> instance:
> 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.