Mintha a héten mondtam volna már, hogy az ütemezők fejlesztésének fénykorát éljük. Úgy látszik, hogy most ez a terület a legvonzóbb az operácis rendszer fejlesztők számára. Talán azért is, mert egy jól megtervezett ütemező nagyon-nagy mértékben képes a rendszer teljesítményét növelni.
Jeff Roberson éppen azon dolgozik, hogy újratervezze a FreeBSD ütemezőjét, és a munkája során ötletekre, visszajelzésekre van szüksége. A dolog lényege, hogy egy olyan ütemezőt hozzon létre, amelyik a jelenlegi modern rendszerekben megtalálható scheduler-ekre hasonlít. Konkrétan a terve az, hogy egy O(1) ütemezőt hozzon létre. Ilyen ütemezőt találhatunk többek között a solaris/linux/és egyéb más rendszerekben is. A fejlesztés lényege, hogy az új ütemező végleg felváltsa a jelenlegi megoldást.
Jeff a "make -j4 buildworld" futtatásával tesztelte az új scheduler-t (ez tulajdonképpen lefordítja a rendszert újra saját magán), és az alábbi megfigyelésekhez jutott: a 'sys time' és az 'user time' nagy mértékben csökkent. A csökkenés mértéke 35%, és 10% egyenként.
Email bejelentés:Date: Thu, 23 Jan 2003 01:38:44 -0500 (EST)
From: Jeff Roberson
To: arch@freebsd.org
Subject: New scheduler
I'm sure many of you have seen me discussing my new scheduler in relation to the scheduler framework. I'd like to show what I have so far and get opinions/feedback.
First, let me describe the features and general design of this scheduler. It is a queue switching O(1) scheduler much like solaris/linux/many others. It has per cpu run queues. It supports some notion of affinity. It is designed as a general purpose replacement for the current scheduler.
It is not complete by any means. What is currently lacking is a good cpu balancing algorithm. I've been working on that for a little while now. The version I'm going to post has some temporary code that just decides where to place a proc at fork time. It never moves them after that.
Its interactivity is very good in the situations that I've put it in. I have written some code to prove its latency, priority computations, nice effectiveness, etc. that I will post along with results as compared to the old scheduler and linux.
There are some aspects of priority computation that I am very happy with and some that need more work. The most notable problem I have right now is what I'd call priority drift. The scheduler uses voluntary sleep time to calculate priority. A process which sleeps exactly one tick longer than it runs will eventually accumulate enough sleep time to reach the highest priority. I need to fix this.
Oh, also, the pctcpu calculations are still a little off. I need to look into that.
I have just started doing performance tests. Prior to this I was focusing on interactive response and priority calculation with nice. Some interesting early results:
make -j4 buildworld on a 2 way Athlon 1800MP with one ata disk.
new sched:
1933.193u 1156.398s 56:31.33 91.1% 2628+2106k 18752+4863io 8538pf+0w
old sched:
2153.557u 1803.705s 48:25.07 136.2% 2462+1925k 17250+4666io 7113pf+0w
What you can see here is that the sys time and user time were greatly reduced. By approx. 35% and 10% respectively. But, since we're not evenly balancing the load across both cpus the real time suffered. I don't expect the speedup to be this good once both cpus are well utilized due to memory bus contention.
Anyway, I'm still waiting on single cpu results. If you have some free compute resources I'd love to have reports from different loads comparing this to the old scheduler.
I'd also like feedback on how people would like to see this added to the build.
You just need one file. It's available at
http://www.chesapeake.net/~jroberson/sched_smp.c
Cheers,
Jeff