Szerintem amit ő kiemel, hogy a userspace-ben futó ütemezőnek nincs akkora overheadje, hogy használhatatlanul lassú lenne. Hogy sikerült egy konkrét (még ha nagyon speciálisan tuningolt) példával megvernie a kernelen belüli ütemezőt, az neki azért fontos, mert ezzel támasztja alá, hogy nincs nagy overhead.
A rust cargo library-hez (https://docs.rs/scx_utils/latest/scx_utils/) írt dokumentáció szerint:
"... sched_ext scheduler implementations which use Rust for userspace component. This enables implementing hot paths in BPF while offloading colder and more complex operations to userspace Rust code which can be significantly more convenient and powerful."
Vagyis lehetséges kevert megoldást használni, a sebességkritikusabb részeket BPF-ben (kernel módban, de valamelyest sandboxolva) tudja futtatni, de a bonyolultabb dolgokat ki lehet szervezni userspace-be.
A mostani konkrét példa - ha jól értelmezem a szerző postját, a kódot nem rágtam át - az scx_rustland implementációt használta és teljes egészében userspace-be lett kirakva. Ezért volt annyira "meglepő", hogy még így is használható a sebessége.
De mégegyszer, itt nem azon van a hangsúly, hogy csinált egy "jobb ütemezőt" - mert nem csinált. Egy speciális esetre szélsőségesen elhangolt ütemezőt csinált. A lényeg az, hogy ez egy proof-of-concept volt annak alátámasztására, hogy a teljesen userspace ütemező is működőképes és a teljesítménye is használható marad.