[concurrency-interest] spinLoopHint() JEP draft discussion

Andrew Haley aph at redhat.com
Sat Oct 10 08:24:10 EDT 2015


On 06/10/15 21:15, Nathan Reynolds wrote:

> Some people are very afraid of context switches.  They think that
> context switches are expensive.  This was true of very old Linux
> kernels.  Now a days, it costs 100s of nanoseconds to do a context
> switch.

In practice people don't use threads as much as they could because of
the cost of such switches.

Say you've constructed a block of data and you want to encrypt it
before saving it somewhere.  What most people do today is call
encrypt() synchronously.  But chances are you have cores on the same
machine which are stopped, so you could hand that task to another
core.  But to do that you have to signal to the stopped core, and the
latency between a FUTEX_WAKE and a stopped thread starting is at least
a couple of microseconds.  You can encrypt at about 1ns/byte, so
that's a couple of kbytes of encryption just to wake the thread.  And
of course there's the cache overhead too.

In practice, all this latency means that it's not worth waking another
core unless your block of data is pretty large.  So how do you solve
this problem?  You spin.  And then the time to start a waiting thread
is not a couple of microseconds but tens of nanoseconds, the time it
takes to encrypt tens of bytes.

Andrew.


More information about the Concurrency-interest mailing list