Van értelme, hidd el. Mondom, például egy többfelhasználós rendszerben. Azok se szívjanak, akiknek csak egy shell vagy egy mc fut, ha közben mások nagy gépigényû feladatokat futtatnak.

Az üresjárat így néz ki: amikor feláll a kernel, rögtön elindítja az init programot, ami a rendszer inicializálását, szolgáltatások indítását végzi. Ha mindez kész van (elindította a démonokat az adott futási szinten), akkor a háttérbe megy minimális prioritással, és õ lesz az üresjárati folyamat. Ugyanúgy megy ez, mint WinNT alatt.

Ez azért fontos, mert ha nincs üresjárati folyamat, és egyik process sem áll készen a futásra, akkor az ütemezõ ugyan mit csinálna? Ehelyett ha nincs más folyamat, akkor az üresjárat „megeszi” az idõszelet hátralévõ részét, ezt lehet látni a top-ban, vagy a KDE system guard-jában, mint a CPU „idle” ideje. Ennek még az az elõnye is megvan, hogy ilyenkor a CPU végre tud hajtani egy HLT utasítást, azaz leállítja a belsõ órajelet, egészen egy interrupt beérkezéséig. A következõ idõzítõ megszalítás fogja újraindítani a procit. Ezért van az, hogy a CPU hõmérséklete és fogyasztása üresjáratban le tud csökkenni.

Vannak olyan folyamatok, amik mindig annyi CPU-idõt használnak, amennyit csak tudnak: játékok, emulátorok, GCC stb. Pl. ha egy vmware és egy OpenOffice fut egyszerre, az OpenOffice akadozni fog, pedig neki csak néhány százalék CPU-idõ kéne. A gond nem is itt van, mert ezt le lehet kezelni prioritáskezeléssel, abban nincs is hiba – ha az OpenOffice magasabb prioritáson van, akkor elvileg simán fut, és a vmware annyi idõt használhat csak, amit az OO átenged neki.

A gond akkor kezdõdik, ha egyszerre két olyan program fut, ami amúgy megenné az összes CPU-idõt. Ha jól értem a dolgot, akkor ha azonos prioritáson vannak, gyakorlatilag round robin ütemezés érvényes, azaz 50%-ot kap mindkettõ.