Zanim Linus Torvalds stracił internet i zasilanie z powodu śnieżycy, która wpłynęła na okno integracji Linuksa 6.8, jego weekend był już w trudnej sytuacji ze względu na spadek wydajności z nowym kodem Linuksa 6.8, który był przyczyną budowania jego jądra Linuksa. To dwukrotnie więcej niż w przypadku poprzednich rdzeni. Inżynierowi AMD Linux udało się odtworzyć regresję, a dzięki współpracy z głównymi programistami potwierdzono rozwiązanie tego problemu w najnowszym kodzie planowania.
Podczas dyskusji na temat znacznego spadku wydajności zgłoszonego przez Linusa Torvaldsa, który wynikał ze zmian w harmonogramie w Linuksie 6.8, w przypadku podzielonego zatwierdzenia, dla zaangażowanego programisty nie było od razu jasne, co spowodowało regresję. W dyskusji, która wywiązała się, głos zabrał Wise Carney z AMD wspomniany Może także odtworzyć regresję. Zamiast wysokiej klasy procesora AMD Ryzen Threadripper, takiego jak ten, którego używa Torvalds, Wyes korzystał ze skromnego komputera stacjonarnego AMD Ryzen 5600G. Ważną informacją, którą poruszył, jest to, że jest to odtwarzane tylko wtedy, gdy wyłączysz ACPI CPPC w BIOS-ie i użyjesz ACPI CPUFreq z regulatorem Schedutil.
Większość systemów AMD Zen 2 i nowszych obsługuje ACPI CPPC, więc w przypadku nowoczesnych rdzeni po stronie Ryzen zazwyczaj korzystają z nowego sterownika AMD P-State. Jednak w przypadku systemów Zen 2 / Zen 3 i wcześniejszych (lub tych, które wyłączają CPPC w BIOS-ie), sterownik CPUFreq jest nadal używany, a domyślnym regulatorem częstotliwości procesora jest zwykle „Schedutil”, aby wykorzystać dane dotyczące użycia harmonogramu.
W tym wątku na liście mailingowej zasugerowano korektę i omówiono konkretne problemy związane z tą regresją. Ostatecznie Vincent Guiteau uwierzył, że ma rozwiązanie regresji i Wise był w stanie pomyślnie przetestować łatkę.
Guittot został już wysłany Zaplanowane/Dobre: Napraw wybór częstotliwości w przypadku niestabilnego przypadku Jako łatka naprawiająca tę złą regresję w nowym kodzie Linuksa 6.8 podczas korzystania z ACPI CPUFreq + Schedutil. Wyjaśnia z poprawką:
„Gdy nie jest włączone utrzymywanie częstotliwości, get_capacity_ref_freq(policy) zwraca bieżącą częstotliwość i margines wydajności zastosowany przez map_util_perf(), umożliwiając użytkownikowi przekroczenie maksymalnej mocy obliczeniowej i wybranie częstotliwości wyższej niż bieżąca częstotliwość.
Margines wydajności jest teraz stosowany na początku procesu, aby uwzględnić pewne ograniczenia użytkowania i nie możemy uzyskać wykorzystania powyżej maksymalnej mocy obliczeniowej.
Musimy użyć częstotliwości wyższej niż bieżąca, aby mieć szansę na ustawienie wyższego OPP, gdy bieżąca częstotliwość zostanie w pełni wykorzystana. Zastosuj ten sam margines i zwróć częstotliwość o 25% wyższą niż bieżąca częstotliwość, aby przejść do następnego OPP, zanim zużyjemy cały procesor w bieżącym procesorze.
Ostatecznie była to jednoliniowa poprawka kodu, mająca zaradzić spadkowi wydajności, które spowodowało, że kompilacje pustego jądra Linusa Torvaldsa wydłużyły się z 22 do 44 sekund.
Zakładając, że z nową łatką wszystko będzie dobrze działać, poprawka powinna trafić do kodu Git systemu Linux 6.8 po przywróceniu dostępu do Internetu i prądu Linusa Torvaldsa.