Kiedy luka w zabezpieczeniach Retbleed została wprowadzona na początku tego roku, złagodzenie jej dla rdzeni procesorów Intel Skylake i pochodnych Skylake wymagało nałożenia ograniczonej spekulacji typu Indirect Branch Restricted Speculation (IBRS), która jeszcze bardziej zatankowała out-of-the-wydajności pudełkowej dla tych starzejących się procesorów Intel. Ale wprowadzana teraz w Linuksie 6.2 to nowa technika ograniczania o nazwie Call Depth Tracking, która pomaga odzyskać część utraconej wydajności, a to z kolei zwiększa użyteczność procesorów pochodzących ze Skylake, które wciąż są w użyciu.
Call Depth Tracking było opracowywane przez ostatnich kilka miesięcy przez programistów jądra Intela i Linuksa w celu uniknięcia konieczności IBRS dla projektów procesorów opartych na Skylake/Skylake w łagodzeniu Retbleed. Twórcy jądra nazwali IBRS „wydajnym horrorem”, inżynierowie VMware narzekali na utratę wydajności i był to po prostu kolejny bolesny spadek wydajności w stosunku do standardowej szybkości procesorów Intel poprzedniej generacji.
Śledzenie głębokości połączeń zostało połączone dla cyklu jądra Linuksa 6.2, który jest obecnie opracowywany. Chociaż w Linuksie 6.2 łagodzenie IBRS jest nadal domyślne dla procesorów Skylake, ale śledzenie głębokości połączeń wbudowane w jądro można łatwo włączyć za pomocą opcji rozruchu „retbleed=stuff”.
Aby zobaczyć, jak głębokość połączeń Śledzenie (retbleed=stuff) wpływa na wydajność Skylake Linux, przeprowadziłem kilka świeżych testów łagodzenia na jądrze Git Linux 6.2. Z jądra Linux 6.2 Git na serwerze Xeon E3-1280 v5 (Skylake) przetestowałem następujące konfiguracje jądra:
Ustawienia domyślne — serwer E3-1280 v5 Skylake z uruchomionym standardowa konfiguracja ze wszystkimi domyślnymi ograniczeniami. Łagodzenie Retbleed domyślnie nadal aktywuje IBRS.
retbleeed=stuff-Łagodzenie Retbleed za pomocą nowego mechanizmu upychania (śledzenie głębokości połączeń).
retbleed=off — po prostu wyłącza zabezpieczenia Retbleed, ale pozostawia domyślne ustawienia wszystkich pozostałych zabezpieczeń procesora.
mitigations=off — brak aktywowania zabezpieczeń procesora o run-time dla tego serwera Skylake.
Stąd przeprowadzono różne testy porównawcze Linuksa, aby zobaczyć, co to oznacza dla wydajności Linuksa na sprzęcie z ery Intel Skylake teraz, gdy dostępne jest śledzenie głębokości połączeń, aby nadal łagodzić Retbleed, ale po niższych kosztach.
Od samego początku w teście porównawczym PostMark I/O nastąpiła wyraźna poprawa z retbleed=stuff w porównaniu z domyślną, gotową do użycia wydajnością jądra z aktywowanym IBRS na Skylake’u. Śledzenie głębokości połączeń przyniosło 24% poprawę w stosunku do domyślnej wydajności w PostMark, ale nadal tryb śledzenia głębokości połączeń miał około 84% wydajności działania bez żadnych ograniczeń Retbleed lub 69% wydajności podczas uruchamiania systemu bez żadnych ograniczeń bezpieczeństwa procesora.
W teście porównawczym interfejsu Sockperf Network Sockperf śledzenie głębi połączeń miało również wyraźną przewagę nad domyślną wydajnością w systemie Linux 6.2, ale wszystkie inne ograniczenia wiążą się ze znacznym obciążeniem.
Ale jeśli w tej chwili używasz Linuksa od razu po wyjęciu z pudełka w systemie z ery Skylake i używasz domyślnych zabezpieczeń, które narzucają IBRS, a przełączenie Linuksa 6.2+ na śledzenie głębokości połączeń może przynajmniej odzyskać część utraconej wydajności.
Operacja retbleed=stuff pomagała również w przypadku obciążeń OpenJDK Java w przywracaniu spadku wydajności IBRS na tym serwerze Xeon Skylake.
W wielu różnych obciążeniach ograniczenie śledzenia głębokości połączeń było pokazać w g ma wyraźnie mniejszy wpływ niż domyślna łagodzenie IBRS dla Retbleed.
W przypadku różnych obciążeń serwera Linux na tym systemie Intel Xeon E3-1280 v5, działanie ze śledzeniem głębokości połączeń zapewniło wzrost wydajności (retbleed=stuff) nad ograniczeniami zapasów, ale nadal występują wysokie koszty związane z innymi ograniczeniami bezpieczeństwa procesora.
Różnica w śledzeniu głębokości połączeń wyraźnie zwalnia w testach mikrotestowych jądra pod obciążeniem.
Czas przełączania kontekstu jest znacznie krótszy dzięki śledzeniu głębi połączeń w porównaniu z IBRS dla Retbleed.
Jeśli nadal polegasz na procesorze pochodzącym ze Skylake/Skylake, który teraz domyślnie korzysta z IBRS do walki z Retbleed, Call Łagodzenie Depth Tracking dostępne w systemie Linux 6.2+ za pomocą opcji retbleed=stuff wyraźnie jest w stanie pomóc odzyskać część utraconej wydajności. To prawda, że nadal istnieją znaczne koszty ogólne związane z innymi ograniczeniami bezpieczeństwa procesora wymaganymi w przypadku starszych procesorów Intela, ale przynajmniej jest to zauważalna poprawa w stosunku do status quo. Szczególnie w przypadku serwerów Intel Linux z ery Skylake, gdzie rozsądne ustawienia domyślne zabezpieczeń są szczególnie potrzebne, śledzenie głębokości połączeń może pomóc tchnąć trochę życia w platformy do momentu aktualizacji sprzętu.
Podczas obliczania średniej geometrycznej dla obciążeń, których dotyczy problem, przełączanie z gotowe jądro Linuksa 6.2 do uruchamiania z retbleed=stuff zwiększyło wydajność o 15%. Ale śledzenie głębokości połączeń (retbleed=stuff) działało z 89% szybkością zwykłego braku zabezpieczeń Retbleed (retbleed=off) lub 71% wydajności serwera Xeon E3-1280 v5, gdzie wszystkie zabezpieczenia procesora były wyłączone (łagodzenia=wyłączone).
