Announcement

Collapse
No announcement yet.

Intel Advances Linux "IPC Classes" Design To Improve Load Balancing For Hybrid CPUs

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Intel Advances Linux "IPC Classes" Design To Improve Load Balancing For Hybrid CPUs

    Phoronix: Intel Advances Linux "IPC Classes" Design To Improve Load Balancing For Hybrid CPUs

    Back in September was a big patch set working out classes of tasks for hybrid CPUs and more properly implementing Intel Thread Director for Linux. This work to better the performance/efficiency of modern Intel Core CPUs with a mix of P and E cores has now advanced past the "request for comments" stage with a new patch series sent out on Monday...

    https://www.phoronix.com/news/Intel-...asses-Post-RFC

  • #2
    I thought the core scheduler was architecture agnostic.
    Seeing since ARM has ad big.little archs for a long time, I already thought that the kernel scheduler was well aware of non-symmetric cost scheduling.

    Comment


    • #3
      I lament that they're using the term "IPC", in this context. Any talk of IPC and tasks naturally evokes thoughts of Inter-Process Communication, for me. Furthermore "Instructions Per Cycle" is both overly-specific and not terribly accurate. So much confusion could've been avoided by using a better term, like ILP (Instruction-Level Parallelism) or Instruction-Level Concurrency.

      Anyway, the broader subject is rather interesting, because ILP is more accurately associated with specific code traces. Tying it to threads is bad, both because a given thread can spend time executing a variety of code with disparate amounts of ILP, and because multi-threading techniques like work-stealing can dispatch unrelated bits of code to a given worker thread, which could invalidate anything the OS previously knew about that thread.

      If we imagine a system which learns the ILP associated with different code traces, then you could have a Thread Director-type engine preemptively generating an interrupt when a thread veers onto a trace with substantially different ILP. At that point, the OS could decide whether to swap the thread over to a different core. I'd imagine that, someday, calling a function could almost directly swap you onto a different core. Yes, there are massive overheads that would make that impractical on today's CPUs and operating systems, but the idea is perhaps viable in some universe.

      Or, if the ILP metric of an entry-point were OS-visible, then a work-stealing implementation might even use it to decide to which threadpool a given function should be dispatched.

      Comment

      Working...
      X