[HN Gopher] Better CPU selection for Linux timer expiration
       ___________________________________________________________________
        
       Better CPU selection for Linux timer expiration
        
       Author : chmaynard
       Score  : 50 points
       Date   : 2022-11-08 09:36 UTC (1 days ago)
        
 (HTM) web link (lwn.net)
 (TXT) w3m dump (lwn.net)
        
       | WJW wrote:
       | 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_ wrote:
         | 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]
        
       ___________________________________________________________________
       (page generated 2022-11-09 23:02 UTC)