A Huawei mérnöke, Chen Jinghuang frissített, véleményezésre szánt (RFC) javításcsomagot küldött be a Linux kernel ütemezőjéhez, amelynek célja, hogy a mai, sokmagos szervereknél javítsa az összkihasználtságot. A javaslat lényege, hogy ha egy CPU-magnak épp nincs futtatható feladata, akkor ne csak „tétlenül várakozzon”, hanem próbáljon feladatot „ellopni” (task stealing) egy túlterhelt magtól – de csak a legutolsó szintű gyorsítótár (last level cache, LLC) azonos tartományán belül, ahol a migráció várhatóan kisebb költséggel jár.

A kernelben ma is létezik egy tétlenség előtti kiegyensúlyozási mechanizmus, az idle_balance(), amely akkor fut le, amikor egy mag épp üresjáratba kerülne, és megpróbál munkát találni neki. Chen szerint azonban ez a folyamat nem mindig elég agresszív vagy nem mindig fut le elég gyakran ahhoz, hogy a sokmagos rendszerekben a rövid idejű egyensúlytalanságokat hatékonyan kisimítsa. Az új megközelítés ezért egy „olcsóbb”, célzottabb keresést vezetne be: ha a mag kifogy a futtatható CFS-feladatokból (Completely Fair Scheduler, CFS), és az idle_balance() sem talál munkát, akkor jönne a gyors „lopás” a közeli, túlterhelt magoktól.

A patch-sorozat technikai összefoglalója szerint a megoldás egy túlterhelt CPU-kat jelölő bitképet (bitmap) tart fenn, hogy gyorsan azonosíthatók legyenek a potenciális „donor” magok. A keresési idő csökkentése érdekében a rendszer a bitkép bejárásakor az első migrálható feladatot vinné át, amit talál. A méltányosság (fairness) miatt pedig a túlterhelt magon a migrálható feladatokat a „következőként futtatandó” sorrendben vizsgálná, vagyis nem teljesen véletlenszerűen kapna el egy tetszőleges folyamatot.

A javaslat egyik kulcsállítása, hogy ez az egyszerű lopási stratégia önmagában is képes jobb kihasználtságot adni, mint az idle_balance() önmagában, mert a keresés olcsó, így akár minden alkalommal lefuthat, amikor a CPU épp tétlenedni készül. Ezzel szemben az idle_balance() szélesebb körben keres, igyekszik megtalálni a legterheltebb futási sort, ami több munkával jár; emiatt, ha a rendszer túl elfoglalt, visszafoghatja a keresést, hogy ne növelje túlzottan az ütemező saját CPU-idejét. Chen érvelése szerint a „simple stealing” nem feltétlenül a globálisan legzsúfoltabb sort tehermentesíti, viszont még mindig sokkal jobb, mint ha a mag semmit sem futtatna.

A beszámoló alapján az új, SCHED_STEAL néven bevezetett kapcsolóval engedélyezhető funkcióval mérhető gyorsulást is láttak: egy kétfoglalatos Intel Xeon Platinum szerveren a Hackbench futási ideje 17%-kal javult. Ez azért érdekes, mert a Hackbench tipikusan érzékeny az ütemezési döntésekre és a szálak közti kommunikációra, így gyakran használják az ütemező változtatásainak gyors, összehasonlító jellegű vizsgálatára.

A folytatás ugyanakkor egyelőre kérdéses. A levélváltásban Peter Zijlstra, a kernel ütemezőjének egyik meghatározó upstream fejlesztője azt vetette fel, hogy talán célravezetőbb lenne a jelenlegi viselkedés javítása, ahelyett hogy egy teljesen új mechanizmus kerülne be a feladatok CPU-ra juttatására. Ez a fajta visszajelzés az RFC fázisban megszokott: ilyenkor még nem az a kérdés, hogy „bekerül-e”, hanem hogy a probléma megoldásának legjobb iránya mi legyen, és a javasolt változtatás mennyire illeszkedik a kernel ütemezőjének hosszú távú koncepciójába.

A téma hátteréhez érdemes hozzátenni, hogy a modern, sokmagos szervereknél az ütemezés egyre inkább topológiaérzékeny feladat. Nem mindegy, hogy két szál ugyanazon az LLC-n osztozik-e, ugyanazon a NUMA-csomóponton (NUMA node) belül vannak-e, vagy épp távoli memóriát érnek el. Az LLC-n belüli migráció tipikusan kisebb cache-veszteséggel járhat, mint egy távolabbi áthelyezés, ezért a javaslat, hogy a lopás „LLC-n belül” történjen, a gyakorlatban a késleltetés és a cache-hatékonyság szempontjából is racionális kompromisszumnak tűnik. Ugyanakkor minden ilyen beavatkozásnál kényes pont a mellékhatások kezelése: például hogy a túl agresszív migráció ne okozzon felesleges „pingpongot” a feladatok között, és ne rontsa a cache-lokalitást olyan terheléseknél, ahol a feladatok erősen kötődnek a korábbi futási helyükhöz.

A javasolt RFC javítások tehát egy konkrét, mérhető eredményekkel alátámasztott irányt mutatnak a CPU-kihasználtság javítására, de az, hogy végül milyen formában – és egyáltalán – bekerül-e a mainline kernelbe, azon múlik, hogy a közösségi review során mennyire sikerül meggyőzően bizonyítani: ez a megoldás általánosan is előnyös, jól skálázódik, és nem hoz kellemetlen regressziókat más, eltérő jellegű terhelések alatt.