[sajith at gmail.com: Google Summer of Code: a NUMA wishlist!]

Sajith T S sajith at gmail.com
Tue Mar 27 02:14:40 CEST 2012


Hi Simon,

Thanks for the reply.  It seems that forwarding the message here was a
very good idea!

Simon Marlow <marlowsd at gmail.com> wrote:

> >  -- From a very recent discussion on parallel-haskell [4], we learn
> >     that RTS' NUMA support could be improved.  The hypothesis is that
> >     allocating nurseries per Capability might be a better plan than
> >     using global pool.  We might borrow/steal ideas from hwloc [5] for
> >     this.
> 
> I like this idea too (since I suggested it :-).

I guess you will also be available for eventual pestering about this
stuff, then? :)

> >  -- Finally, a logging/monitoring infrastructure to verify assumptions
> >     and determine if/how local work stays.
> 
> I'm not sure if you're suggesting a *new* logging/monitoring
> framework here, but in any case it would make much more sense to
> extend ghc-events and ThreadScope rather than building something
> new.  There is ongoing work to have ThreadScope understand the
> output of the Linux "perf" tool, which would give insight into CPU
> scheduling activity amongst other things.  Talk to Duncan Coutts
> <duncan at well-typed.com> about how far this is along and the best way
> for a GSoc project to help (usually it works best when the GSoc
> project is not dependent on, or depended on by, other ongoing
> projects - reducing synchronisation overhead and latency due to
> blocking is always good!).

Again, thanks for all this information.  Surely, enhancing existing
machinery would make sense rather than building brand new ones.

There's a ticket for this proposal now, and it would be great to get
(more?) feedback there or in this list or some other suitable place.
Obviously we'd need to rework some of it, especially the "thread
pinning" part.

http://hackage.haskell.org/trac/summer-of-code/ticket/1618

Regards,
Sajith.

-- 
"the lyf so short, the craft so long to lerne."
                 -- Chaucer.




More information about the Glasgow-haskell-users mailing list