Noop harmonogram

Lokalizacja harmonogramów we/wy w uproszczonej strukturze jądra Linuksa.

Harmonogram NOOP jest najprostszym harmonogramem I/O dla jądra Linuksa . Ten harmonogram został opracowany przez Jensa Axboe .

Przegląd

Harmonogram NOOP wstawia wszystkie przychodzące żądania we/wy do prostej kolejki FIFO i implementuje scalanie żądań. Ten harmonogram jest przydatny, gdy ustalono, że host nie powinien próbować zmieniać kolejności żądań na podstawie zawartych w nich numerów sektorów. Innymi słowy, program planujący zakłada, że ​​host nie wie, jak produktywnie zmienić kolejność żądań.

Istnieją (ogólnie) trzy podstawowe sytuacje, w których taka sytuacja jest pożądana:

  • Jeśli planowanie we/wy będzie obsługiwane w niższej warstwie stosu we/wy. Przykłady niższych warstw, które mogą obsługiwać planowanie, obejmują urządzenia blokowe, inteligentne kontrolery RAID, pamięć masową podłączaną do sieci lub kontroler podłączony zewnętrznie, taki jak podsystem pamięci masowej, do którego dostęp można uzyskać za pośrednictwem przełączanej sieci pamięci masowej. Ponieważ żądania we/wy są potencjalnie zmieniane w harmonogramie na niższym poziomie, ponowne sekwencjonowanie IOP na poziomie hosta zużywa czas procesora hosta na operacje, które zostaną właśnie cofnięte na niższym poziomie, zwiększając opóźnienia/zmniejszając przepustowość bez produktywnego powodu.
  • Ponieważ dokładne szczegóły pozycji sektora są ukryte przed systemem hosta. Przykładem może być kontroler RAID, który samodzielnie nie wykonuje planowania. Chociaż host ma możliwość zmiany kolejności żądań, a kontroler RAID nie, systemowi hosta brakuje widoczności, aby dokładnie zmienić kolejność żądań, aby skrócić czas wyszukiwania. Ponieważ host nie ma możliwości oceny, czy dana sekwencja jest lepsza od innej, nie może optymalnie zrestrukturyzować aktywnej kolejki i dlatego powinien przekazać ją do urządzenia, które (teoretycznie) jest bardziej świadome takich szczegółów.
  • Ponieważ ruch głowicy odczytu/zapisu nie wpływa na wydajność aplikacji na tyle, aby uzasadnić zmianę kolejności. Dzieje się tak zwykle w przypadku nośników nieobrotowych, takich jak dyski flash lub dyski półprzewodnikowe (SSD).

Jednak NOOP niekoniecznie jest preferowanym harmonogramem we/wy dla powyższych scenariuszy. Typowe dla dostrajania wydajności, wszystkie wskazówki powinny opierać się na obserwowanych wzorcach obciążenia pracą (podważając zdolność do tworzenia uproszczonych reguł praktycznych). Jeśli istnieje rywalizacja o dostępną przepustowość we/wy z innych aplikacji, nadal możliwe jest, że inne programy planujące będą generować lepszą wydajność dzięki bardziej inteligentnemu podzieleniu tej przepustowości dla aplikacji uznanych za najważniejsze. Na przykład uruchomienie serwera katalogowego LDAP może skorzystać z terminu ostatecznego preferencje odczytu i gwarancje opóźnienia. Jednocześnie użytkownik z systemem stacjonarnym, na którym działa wiele różnych aplikacji, może chcieć mieć dostęp do CFQ lub jego możliwości nadawania priorytetu przepustowości dla określonych aplikacji nad innymi ( ionice ).

Jeśli nie ma konfliktów między aplikacjami, wówczas wybór programu planującego dla wyżej wymienionych trzech scenariuszy przynosi niewielkie lub żadne korzyści. Wynika to z wynikającej z tego niemożności zmiany priorytetów operacji jednego obciążenia w sposób, który udostępnia dodatkową pojemność dla innego obciążenia. Innymi słowy, jeśli ścieżki we/wy nie są nasycone, a żądania dotyczące wszystkich obciążeń nie spowodują nieuzasadnionego przesunięcia głowic dysków (o czym system operacyjny jest świadomy), korzyść z nadania priorytetu jednemu obciążeniu może spowodować sytuację gdzie czas procesora poświęcony na planowanie operacji we/wy jest marnowany, zamiast przynosić pożądane korzyści.

Jądro Linuksa udostępnia również parametr nomerges sysfs jako konfigurację niezależną od harmonogramu, umożliwiając całkowite wyłączenie logiki scalania żądań warstwy bloków lub tylko w przypadku bardziej złożonych prób scalania. Zmniejsza to zapotrzebowanie na program planujący NOOP, ponieważ narzut większości programów planujących wejścia/wyjścia jest związany z ich próbami zlokalizowania sąsiednich sektorów w kolejce żądań w celu ich połączenia. Jednak większość obciążeń we/wy korzysta z pewnego poziomu scalania żądań, nawet w przypadku szybkich pamięci masowych o małych opóźnieniach, takich jak dyski SSD.

Zobacz też

Linki zewnętrzne

Pobrano z „ https://en.wikipedia.org/w/index.php?title=Noop_scheduler&oldid=1061585289 ”