Dlaczego 12.04 usuwa smak jądra serwera?

13

Ubuntu usuwa smak serwera, jak określono w informacjach o wydaniu 12.04:

Podobnie jak w przypadku Beta-1, jądro Beta-2 nie przenosi już oddzielnych smaków serwera amd64 i generycznych odmian jądra. Zostały one połączone w jeden genowy smak jądra, aby zmniejszyć obciążenie związane z utrzymaniem przez cały okres użytkowania tej wersji LTS.

Różnice między -generic i -server wydają się być związane z wyprzedzaniem, przerwaniem timera i harmonogramem we / wy, jak podano na: https://help.ubuntu.com/10.10/serverguide/C/preparing-to-install .html # intro-kernel-diffs

Proszę o dane techniczne.

  1. Więc co się teraz dzieje?
  2. Czy wersja serwerowa uruchomi jądro pulpitu bez obniżenia wydajności?
  3. Czy to jest jakoś uzasadnione?
  4. Co dzieje się z tymi różnicami?
  5. Czy można je zmienić w przestrzeni użytkownika?
  6. Nie ma zastosowania od 12.04?
  7. Jeśli odpowiedź brzmi „tak”, ta zmiana pociąga za sobą obniżenie wydajności?

Wszystkie są pytaniami, na które można odpowiedzieć. Proszę o konkretną zmianę w pakiecie, a nie o nic innego.

gentakojima
źródło

Odpowiedzi:

10

Jak zauważyliście w ogłoszeniach o wydaniu, ogólne i jądra serwerów zostały połączone w wydaniu 12.04 w celu zmniejszenia obciążenia związanego z utrzymaniem przez cały okres użytkowania LTS. Te dwa warianty jądra różniły się tylko dwiema głównymi opcjami konfiguracji jądra: domyślnym harmonogramem we / wy i modelem wykluczania.

Zostało to szczegółowo omówione na liście mailingowej zespołu jądra Ubuntu

Jak zauważono w tym wątku, domyślny harmonogram we / wy zmienił się z „ostatecznego terminu” na „cfq”. Jednak każdy, kto chce pozostać przy harmonogramie we / wy Deadline, może to zrobić w czasie uruchamiania, ustawiając elevator=deadline.

Model poprzedzający zmienił się z CONFIG_PREEMPT_NONE na CONFIG_PREEMPT_VOLUNTARY. W tej chwili niestety nie mam pod ręką żadnych testów wydajności. Mam nadzieję, że to pomaga niektórym. Dzięki.

Leann Ogasawara
źródło
7

Odpowiedź na pytanie „dlaczego” znajduje się w podanym przez Ciebie cytacie - ponieważ łatwiej jest utrzymać ten sposób. Funkcjonalność jądra jest dość dobrze sparametryzowana, możesz zmieniać rzeczy takie jak planista w czasie wykonywania, więc nie ma naglącej potrzeby, aby kompilować różne ustawienia domyślne.

Dokładne powody i omówienie szczegółów, które musielibyście zapytać na liście mailingowej Ubuntu KernelTeam - informacje kontaktowe znajdują się na informacyjnej stronie Wiki KernelTeam .

syneticon-dj
źródło
2

Teraz dzieje się tak, że istnieje tylko jedno jądro dla serwera i komputera. Jeśli chcesz, możesz zmienić harmonogram we / wy w czasie wykonywania, ale CFQ jest najbardziej kompletnym i aktywnie utrzymywanym harmonogramem, więc jest dobrym ustawieniem domyślnym. Który z nich nie ma większego znaczenia przy większości obciążeń. Jądro serwera służyło do wyłączania nawet dobrowolnego wyłączenia jądra, ponieważ teoretycznie mogło to dać niecolepsza przepustowość, ale nie jestem świadomy żadnych pomiarów wydajności, które faktycznie wykazywałyby tam jakąkolwiek korzyść, więc w praktyce nie będzie miało wpływu na serwery, jeśli przejdzie do stacjonarnego modelu premiowania. Jądro jest również bezznaczne (CONFIG_NO_HZ), co oznacza, że ​​planuje przerwania timera tylko wtedy, gdy jest to potrzebne, w oparciu o aktualnie uruchomione timery aplikacji, a nie w ustalonych odstępach czasu, i uważam, że tak było w przypadku kilku wydań, pomimo tego, co mówi przewodnik po serwerze .

TL; DR: Utrzymanie innego jądra dla serwerów nie przyniosło żadnych korzyści, więc praktyka została zakończona.

psusi
źródło
I / O scheduler ma rzeczywiście coś zmienić, zwłaszcza dla wirtualizacji obciążeń. Spójrz tutaj: publib.boulder.ibm.com/infocenter/lnxinfo/v3r0m0/topic/liaat/... , podsumowuje „ogólnie, liczba ta pokazuje, że planista terminów we / wy przewyższa harmonogram we / wy CFQ, szczególnie w scenariusze wielowątkowe " .
syneticon-dj