Java Thread Affinity support for hyper threading.

Overview

A benefit of hyper-threading is the ability to support more threads without incurring the overhead of context switches. If your threads spend a high proportion of their time waiting for resources e.g. busy waiting on a data source, accessing main memory or waiting for short periods of time for IO, hyper threading can improve performance at little cost.

However, hyper threading can impact performance when the two threads on the same core start competing for resources, such as the FPU, Level 1 cache, or CPU pipeline. For these reasons, hyper-threading is often turned off in high performance systems.

A solution to get the best of both worlds

The Java Thread Affinity version 1.4 library attempts to get the best of both worlds, by allowing you to reserve a logical thread for critical threads, and reserve a whole core for the most performance sensitive threads. Less critical threads will still run with the benefits of hyper threading.

Example

Say you have a system e.g. an Intel i7 with four core and two logical threads per core.
You want to reserve two cores to dedicate to critical threads. On Linux you can do this but using isolcpus= in grup.conf
Say you have two critical thread which are busy waiting for resources and can share a core called "reader" and "writer" and you have an "engine" thread you want to dedicate a whole core to (so it doesn't have to compete for resources) You can assign the threads as follows.
The "engine" only uses "CPU 3" and "CPU 7" is reserved as idle.

How does this look in code

Sample code to allocate these thread/cores is as follows
AffinityLock al = AffinityLock.acquireLock();
try {
    // find a cpu on a different socket, otherwise a different core.
    AffinityLock readerLock = al.acquireLock(DIFFERENT_SOCKET, DIFFERENT_CORE);
    new Thread(new SleepRunnable(readerLock, false), "reader").start();

    // find a cpu on the same core, or the same socket, or any free cpu.
    AffinityLock writerLock = readerLock.acquireLock(SAME_CORE, SAME_SOCKET, ANY);
    new Thread(new SleepRunnable(writerLock, false), "writer").start();

    Thread.sleep(200);
} finally {
    al.release();
}

// allocate a whole core to the engine so it doesn't have to compete for resources.
al = AffinityLock.acquireCore(false);
new Thread(new SleepRunnable(al, true), "engine").start();

Thread.sleep(200);
System.out.println("\nThe assignment of CPUs is\n" + AffinityLock.dumpLocks());
This code declares that the "main" thread uses a cpu (it gets 7). The "reader" thread should use a different socket or a different core. It get a different core as there is no second socket. The "writer" thread tries to get a thread on the same core, or the same socket, or any thread. The AffinityStrategy is an interface which allows you to create your own thread allocation strategies.

The "engine" thread tries to allocate a whole core to the thread. (It finds a core where it can allocate all the threads for that core)

When run on an i7 with isolcpus=2,3,6,7 you get the following output

Assigning cpu 7 to Thread[main,5,main]
Assigning cpu 6 to Thread[reader,5,main]
Assigning cpu 2 to Thread[writer,5,main]
Releasing cpu 7 from Thread[main,5,main]
Assigning core 3: cpus 3, 7 to Thread[engine,5,main]

The assignment of CPUs is
0: General use CPU
1: General use CPU
2: Thread[writer,5,main] alive=true
3: Thread[engine,5,main] alive=true
4: General use CPU
5: General use CPU
6: Thread[reader,5,main] alive=true
7: Thread[engine,5,main] alive=true

Related topics

Java Thread Affinity support for ExecutorService
Java Thread Affinity supports groups of threads.
Thread Affinity library for Java supports JNA
Thread Affinity library for Java.

Comments

  1. this one sounds good, but is there any way to use Executors of Java instead of old new Thread approach??
    Coz we can rely on Executors in a long run but not on normal Thread

    ReplyDelete
  2. @Vivek I can see nothing preventing you from using AffinityLock inside just simple Runnable/Callable, which itself is running inside any kind of pool

    ReplyDelete
  3. @Vivek Japtap, Good idea. Its not hard to do but better if its supported in the library. I will add a description to a new post.

    ReplyDelete
  4. Nice work!
    Are you planning Windows port? I would be interested in doing that.
    I was curious if there is a Windows library to set Java thread afinity and found only http://perfinsp.sourceforge.net/java-api-sysutil.html.

    ReplyDelete
  5. I would be more than happy for some one to port the library. The JNI is based on sample code written for Windows originally, so it should work. (The two calls are POSIX standard). You could get either the JNI or JNA adapters working (ideally both)

    I have an outstanding issue for someone to port, test and document use on windows. https://github.com/peter-lawrey/Java-Thread-Affinity/issues/7

    I only have Linux machines to develop on and test.

    ReplyDelete

Post a Comment

Popular posts from this blog

Java is Very Fast, If You Don’t Create Many Objects

Low Latency Microservices, A Retrospective

Unusual Java: StackTrace Extends Throwable