A CPUID a jelenlegi interfész, azért írtam. Arra is pl van interfész, hogy a realtime scheduling igényeket jelezni tudd a kernel fele. Meg arra is, hogy a prioritást meg tudd adni (nice). Ez egy részét lefedi, annak amit írsz.
Amit vizionálsz, az viszont a jelenlegi programozási modell totális átalakítása, ehhez nem elég a kernel, hanem az ABI, a teljes userspace, library-k, linkerek, a komplett ökoszisztémának alapjaiban kéne megváltoznia. Mielőtt ebbe belefogna valaki, eléggé biztosnak kell lenni abban, hogy tényleg ez a valós probléma amit hosszútávon meg kell oldani. Ez nem 1-2 CPU generációra szól, hanem évtizedekre előre fogja meghatározni a modellt. Ha kiderül, hogy az alapprobléma mégiscsak egy múló divat következménye volt, vagy végül teljesen más irányba fut ki, a kompatibilitás miatt ott fognak időtlen-időkig maradni egy koloncként a bevezetett interfészek (pl mmap()-ben maradtak ilyen ősi relikviák a régi, KMS-előtti X11 verziók támogatása miatt, amikor userspace-nek kellett direkt hozzáférést adni meghatározott címen levő fizikai memóriához).
Egyáltalán, mint programozó, honnan tudod, hogy fpu vagy integer vagy vezérlési szerkezet intenzív lesz-e a thread? Behívsz egy library-be és hirtelen teljesen megváltozik a terhelésprofil, anélkül, hogy tudnál róla, hacsak nem debuggolod végig az összes tranzitív függőségedet. Le akarsz kezelni egy http request-et?
- Először - még mielőtt hozzád érne a vezérlés - IO intenzív
- aztán nagy számokat maradékosan osztunk és hatványozunk (kulccsere algoritmus)
- aztán jön egy teljesen másik crypto algoritmus, amire dedikált CPU utasítások vannak (stream titkosítás)
- aztán string trancsírozás jön ami sok elágazással jár, vezérlési-szerkezet intenzív (http header-ök kezelése)
- aztán hopp egyszercsak egy nagyon komplex tömörítőalgoritmusban (mondjuk zstd) vagyunk (content-encoding kezelése)
- aztán jön mondjuk egy kis json parse-olás
- most ért a futás ahhoz a kódhoz amit te írtál - ha éppenséggel képet kezelsz az adott http requestben - hirtelen egy fpu és SIMD intenzív tömörítőalgoritmus jöhet
Mindez egy szálon. Ha kellően nagy a body, és streamként próbálod feldolgozni, menet közben is sokszor oda-vissza ugrálás lesz az egyes lépések között. Futási időben ez mind teljesen dinamikusan változik. Esély nincs rá, hogy előre jobban megmondjad, amit a kernel másodpercenként párszáz- vagy ezerszer újra ki tud értékelni.
Kicsit az Itanium-ra emlékeztet az egész problémakör. Ott is az Intel az gondolta, hogy majd alapjaiban megreformálja az egész modellt. Hogy jobb lenne fordítási időben előre elvégezni azokat a műveleteket, amit a CPU egyre bonyolódó - kvázi-haszontalan overheadként egyre nagyobbra nővő - frontendje csinál. Mi lett belőle? Egy kisebb ország GDP-jét elégették, lett pár drága HP Superdome szerver, meg egy csomó NDA szerződés, ami megtiltotta, hogy bárki bármilyen benchmark adatot közöljön az Itaniumokról. Aztán szomorúan el kellett fogadják, hogy a CPU frontendje futási időben mégiscsak sokkal több konkrét információval rendelkezik, mint amivel a fordító valaha is rendelkezhet, hogy valósi időben kioptimalizálja az utasítások párhuzamosítását és végrehajtóegységekre szétdobását.