3 ms·

Better CPU selection for Linux timer expiration

• WJW 4y ago
  It is a cool trick, but it was a surprise to me that they go to such lengths to get a "busy" CPU to handle the timer expiration. I would have thought that you'd want to handle extra work like timer expiration with an idle CPU, since the busy CPU has (by definition) other work to do. OTOH you could also argue that timer expiration does not take a lot of time and so the slowdown would be negligible. The power savings might be worth more. If it does matter you could always pin code and timers to specific CPUs I guess. This does seems to be one of the usecases that you would want to use the little cores in a big/little architecture for btw.
  • derf_ 4y ago
    There is latency associated with coming out of deeper C-states (from hundreds of microseconds to milliseconds, depending on the transition, which may include L1 and L2 cache flushes, etc.), so it isn't just the power. It's faster, too. It might reduce throughput of a single-threaded process, but perhaps not even that if it avoids bouncing cache lines around to different cores. Remember, though, that almost all timers never reach expiration, anyway, so the real savings here is the 25% reduction in the time to set or cancel a timer. That work, if it ever gets done, is now deferred to when a CPU is about to go idle, which (by definition) means it has nothing better to do.
    • deleted 4y ago
      [deleted]