0

In Peter Lawrey's Vanilla Java blog, he demonstrates the jitter caused by busy-waiting threads on isolated vs non-isolated CPU cores in an experiment measuring the distance between consecutive calls to nanoTime. I'm trying to better understand why there's such a large spike at the 100μs range happening almost 30 times per second. He said that it has to do with the minimum time unit being 100μs and the scheduler sleeping and then waking the thread at the next time unit. However, I don't quite understand how this is causing the 100μs delay—does this mean that the minimum time quanta for the CFS is likely set to 100μs, the experiment is pre-empted and another process/thread is running for those 100μs at which point this timer experiment is then context-switched to run again?

Having a time quantum of 100μs seems extremely short, however, given that the Linux default from my understanding is set to about 40 times that. But it also seems much too long to spend 100μs running the scheduler kernel code if there's no context switching (but I could be mistaken). So I'm curious as to why this might be happening so often at 100μs spikes and is consistently reproducible in his tests.

enter image description here

rb612
  • 5,280
  • 3
  • 30
  • 68
  • Looks like a timer somewhere, I could rather think of JVM itself. Does it have tick driven model to schedule the threads? – 0andriy May 21 '20 at 13:00
  • @0andriy that would make sense to me, however I'm curious why running the thread on an isolated CPU would then cause the purple lines in the graph, where it no longer occurs. Could it be related to the Linux scheduler or is that unlikely with the timings? – rb612 May 22 '20 at 00:28
  • Edit: it looks like the JVM uses the [native OS scheduler](https://stackoverflow.com/a/2816023/3813411) – rb612 May 22 '20 at 00:42
  • Okay, the point is *look for a timer* somewhere (it even can be some microcontroller, like EC which by some reason pings the host CPU or polling mode of some driver). Either Linux scheduler or bad test case or something which has not been off during the test... Post from 2013. Try to find similar from recent kernels. That said, I can't found the mentioned test clean in terms of what **machine** limitations are. – 0andriy May 22 '20 at 09:59

0 Answers0