Thread (2 messages) flat view 2 messages, 2 authors, 2015-07-14

Re: [RFC PATCH] getcpu_cache system call: caching current CPU number (x86)

From: Mathieu Desnoyers <hidden>
Date: 2015-07-13 17:36:32

----- On Jul 13, 2015, at 7:17 AM, Ben Maurer bmaurer-b10kYP2dOMg@public.gmane.org wrote:
At Facebook we already use getcpu in folly, our base C++ library, to provide
high performance concurrency algorithms. Folly includes an abstraction called
AccessSpreader which helps engineers write abstractions which shard themselves
across different cores to prevent cache contention
(https://github.com/facebook/folly/blob/master/folly/detail/CacheLocality.cpp).
We have used this primative to create faster reader writer locks
(https://github.com/facebook/folly/blob/master/folly/SharedMutex.h), as well as
in an abstraction that powers workqueues
(https://github.com/facebook/folly/blob/master/folly/IndexedMemPool.h). This
would be a great perf improvement for these types of abstractions and probably
encourage us to use the idea more widely.

One quick comment on the approach -- it'd be really great if we had a method
that didn't require users to register each thread. This can often lead to
requiring an additional branch in critical code to check if the appropriate
caches have been initialized. Also, one of the most interesting potential
applications of the restartable sequences concept is in malloc. having a brief
period at the beginning of the life of a thread where malloc didn't work would
be pretty tricky to program around.
If we invoke this per-thread registration directly in the glibc NPTL implementation,
in start_thread, do you think it would fit your requirements ?

Thanks,

Mathieu

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help