Additional CFS Benchmarks

Additional CFS Benchmarks
Kacper Surdy
Źródła
• http://kerneltrap.org/Linux/Additional_CFS_B
enchmarks
• http://apcmag.com/why_i_quit_kernel_devel
oper_con_kolivas.htm
CK, CFS, SD
• CK
– Con Kolivas
– Staircase Deadline (SD)
• CFS
– Ingo Molnar
– Completely Fair Scheduler
Hackbench
• Ma testowad wydajnośd, narzut i skalarnośd
• Procesy podzielone w grupy
• W grupie:
– Serwery nasłuchują na gniazdach
– Wszyscy klienci wysyłają wiadomości do
wszystkich serwerów w grupie
Hackbench
• Niżej jest lepiej
• Na osiach
– Pionowo: czas trwania testu (w sekundach)
– Poziomo: podpisane “liczba procesów”,
prawdopodobnie powinno byd “liczba grup”
• hackbench $i działa jak hackbench
• hackbench –g $i uruchamia $i grup procesów z
domyślną liczbą procesów w grupie (np. 40)
Hackbench
Hackbench
•
•
•
•
Wygrywa SD
Większe różnice dopiero > 50 procesów
Stary scheduler wyraźnie odstaje
CFS – ładny, gładki wykres (byd może większa
przewidywalnośd?)
Lat_ctx
• Ma mierzyd czas przełączania kontekstu
• Procesy połączenie w pierścieo przez pipe’y
• Przekazują sobie kolejno token
• Możliwe jest wykonanie dodatkowej pracy by
zaśmied cache (tutaj bez tej opcji – tylko
przekazywanie tokenu)
Lat_ctx
• Niżej jest lepiej
• Na osiach
– Pionowo: czas trwania testu (w mikrosekundach)
– Poziomo: liczba procesów połączonych w pierścieo
Lat_ctx
Lat_ctx
• Wygrywa SD (przy małej liczbie procesów)
• Standardowy dogania SD (przy dużej liczbie
procesów)
• CFS wyraźnie najgorszy
Pipe-test
• Dwa procesy wymieniające komunikat przez
pipe
• Niżej jest lepiej
• Na osiach
– Pionowo: czas obrotu pętli (w mikrosekundach)
– Poziomo: kolejne próby (dla wyeliminowania
losowości)
Pipe-test
Pipe-test
• Podobnie jak Hackbench
• Wygrywa SD (po raz trzeci!)
• Stary scheduler wyraźnie odstaje
Razem
• Hackbench
1. 2.6.22-ck1
2. 2.6.23-cfs-devel
3. 2.6.21
• Lat_ctx
1. 2.6.22-ck1
2. 2.6.21
3. 2.6.23-cfs-devel
• Pipe-test
1. 2.6.22-ck1
2. 2.6.23-cfs-devel
3. 2.6.21
CFS < CK ?
Ingo:
many things happened between 2.6.22-ck1 and
2.6.23-cfs-devel that could affect performance
of this test. My initial guess would be
sched_clock() overhead. *…+
hackbench 90: sched-devel.git vs.
sched-devel.git+lowres-sched-clock+dsp
-----------------------------5.555
5.149
5.641
5.149
5.572
5.171
5.583
5.155
5.532
5.111
5.540
5.138
5.617
5.176
5.542
5.119
5.587
5.159
5.553
5.177
-----------------------------avg: 5.572 avg: 5.150 (-8.1%)
hackbench 90: sched-devel.git vs.
sched-devel.git+lowres-sched-clock+dsp
• Dokładniejszy (ale wolniejszy) sched_clock()
z 2.6.23 daje ok. 8% stratę
• Na jądrze 2.6.22 CFS powinien wygrad
Benchmarki
Jos Poortvliet:
But this is all microbenchmarks, which won't have
much effect in real life, right? [...]
Ingo:
yeah, it's much less pronounced in real life - a
context-switch rate above 10,000/sec is already
excessive - while for example the lat_ctx test
generates close to a million context switches a
second.
Benchmarki
Con:
The main problem was that there simply was
not a convincing way to prove that staircase
was better on the desktop. User reports were
not enough. There was no benchmark. *…+
Benchmarki
• Nie ma dobrych, sprawdzonych metod
testowania
• Testy syntetyczne nie odzwierciedlają
prawdziwego użycia
• Wrażenia z użytkowania są trudno mierzalne
i mogą byd nie obiektywne
Cytaty
Con:
*…+ the audio would skip. Skip! Jigabazillion
bagigamaherz of CPU and we couldn't play
audio?
*…+ developer said he couldn't reproduce the
problem on his quad-CPU 4GB RAM machine
with 4 striped RAID array disks... (w 2003)
Cytaty
Con:
There is no friendly way to communicate normal
users' issues that are kernel related.
How scary do you think it is to say 'my Firefox
tabs open slowly since the last CPU scheduler
upgrade'?