18_kernel.pdf

aktualności

Kernel

Wiadomości z przyszłości

Czytając jedynie artykuły, można

odnieść wrażenie, że wszystkie problemy

z jądrem systemu rozwiązywane są, za-

nim się pojawią. Tak jednak niestety nie

jest. Wiele błędów ujawnia się tak rzad-

ko, że przez długi czas pozostają nie-

zauważone. Zaś jak już ktoś zauważy, to

i tak trudno je powtórzyć, więc i dojść

skąd się biorą. Przykładem takiego błędu

może być opisany niedawno przez Mi-

chaela Smitha błąd w zegarku ( gettime-

ofday ). Ujawnia się on na komputerach

wieloprocesorowych, on sam zauważył

go na maszynie o dwóch czterordzenio-

wych procesorach, powodując przesunię-

cie pojedynczych odczytów godziny

o 4398 sekund w przyszłość.

Jakby nie patrzeć, pomyłka o półtorej

godziny to już sprawa niebagatelna. Na

szczęście znalazł też od razu przyczynę.

Otóż jądro potrzebuje wspólnego źródła

czasu – czegoś co czytane z każdego ka-

wałka kodu poda ten sam czas. Przy pro-

cesorach Intela domyślnie jest to usta-

wiane na TSC (ang. time stamp coun-

ter, licznik znacznika czasu) dowolnego

CPU, gdyż powinny one być zsynchro-

nizowane.

Okazuje się, że jednak czasami nie są,

wynikiem czego jądro ,,cofa się w cza-

sie'' o nanosekundę. Że zaś normal-

nie czas płynie tylko do przodu, to je-

go upływ jest mierzony w typie unsigned

– zamiast przyjmować ujemne wartości,

,,przekręca się'' i przyjmuje maksymal-

ne... Problem występował w wielu wer-

sjach jądra, lecz na tyle rzadko, że nikt

wcześniej nie doszedł, co tak napraw-

dę się dzieje. Zaś poprawka jest trywial-

na – korzystać z dowolnego innego źró-

dła czasu.

http://lkml.org/lkml/2007/8/23/96

minowanym w Polsce przez Linuksa był

rynek drobnych routerów. W dobie rozkwitu

drobnych sieci osiedlowych, notabene moto-

ru rozwoju rodzimego Internetu, prawie każda

z nich instalowała na swoich serwerach wła-

śnie ten system. Dziś większość z nich zniknę-

ła z rynku – niektóre po prostu nie wytrzyma-

ły konkurencji gigantów, inne zaś stały się czę-

ścią tych najbardziej ekspansywnych. I wła-

śnie te ekspansywne osiedlówki osiągając wiel-

kości tysięcy komputerów, przekonały się, że

nawet sterownik karty sieciowej potrai zepsuć

dzień.

Sposób interakcji urządzeń peryferyjnych

z procesorem został określony dobre kilkadzie-

siąt lat temu. Kiedy wymagane jest zwrócenie

uwagi, na przykład przyszedł pakiet siecio-

wy, ustawiana jest specjalna laga. Zwyczajo-

wo procesor w momencie ustawienia takiej la-

gi przerywa, cokolwiek robił, i uruchamia od-

powiednią procedurę dla obsługi tego zdarze-

nia. Stąd też mechanizm ten zwany jest prze-

rwaniem.

Niezaprzeczalną zaletą przerwań jest

natychmiastowość reakcji. Jednak prawdzi-

wym powodem wprowadzenia takiego roz-

wiązania jest wygoda programisty. W cza-

sach wypracowania tej metody systemy ope-

racyjne były jedno zadaniowe – programy

już uruchomione pracowały bezpośrednio

na procesorze, bez pośrednictwa systemu.

Gdyby procesor nie robił tego automatycz-

nie, to programista musiałby pamiętać, aby

co chwilę sprawdzać stan wszystkich urzą-

dzeń.

Wadą przerwań jest to, że trzeba przery-

wać. Zmiana kontekstu zajmuje procesorowi

kilkadziesiąt mikrosekund. Kiedy pomno-

ży się to przez kilka tysięcy pakietów na se-

kundę okazuje się, że procesor nie robi pra-

wie nic innego, niż obsługiwanie przerwań.

A przecież rzadko która sieć osiedlowa dys-

ponuje tysiącami zewnętrznych adresów,

więc te pakiety trzeba przed wysłaniem

przynajmniej NAT–ować.

Teraz właśnie wypadałoby sobie zadać

pytanie: po co nam całe to przerywanie?

Przecież jak widać, na szybkość działania ma

to skutek wprost negatywny. Wygodę progra-

misty zaś może zapewnić nam system opera-

cyjny, który sam co jakiś czas będzie spraw-

dzał, co trzeba zrobić.

Stąd też we FreeBSD od 2002 roku do-

stępny jest mechanizm device polling , który

robi właśnie to – wyłącza przerwania i co ja-

kiś czas sam sprawdza, czy nie trzeba obsłużyć

urządzenia. Twórcy Linuksa postanowili nie

zostać w tyle i ich mechanizm, nazwany NAPI

(od ang. New API), dwa lata później traił do

stabilnej wersji 2.4.20.

Od tego czasu NAPI zaimplementowane

zostało w około połowie sterowników kart

sieciowych. Pojawiło się także kilka testów,

z których jednoznacznie wynika, iż jest to zna-

czny krok do przodu. Niektórzy nawet suge-

rują, że bez NAPI nie dałoby się praktycznie

uzyskać gigabitowych transferów. Inni po

prostu stwierdzają, że jest to bardzo dobre

rozwiązanie.

Ale dobre nie oznacza automatycznie

idealne. Znalazło się więc i w NAPI drobne

niedopatrzenie. Część profesjonalnych kart

sieciowych ma po kilka portów. Jeden port

reprezentuje jeden interfejs sieciowy, więc

i jedno urządzenie w jądrze. Jednak znajdując

się na tej samej karcie, muszą korzystać ze

wspólnego przerwania, lecz przy planowaniu

traktowane są osobno, zmniejszając dokład-

ność planów.

Usunięcie tego rzadko uwidaczniające-

go się mankamentu zaproponowano dwa la-

ta później. Wraz z tym nadeszło kilka zmian

mających na celu uporządkowanie i uprosz-

czenie kodu. Między innymi wszystkie atry-

buty związane z NAPI przeniesione zostały

do osobnej struktury napi_struct , którą re-

jestruję się jako pole net_device za po-

mocą funkcji netif_api_add . Uproszczono

również planowanie czasu – jedyne czym musi

się martwić autor sterownika to ograniczenie

ilości pakietów do obrobienia na raz, poda-

wane jako argument dla funkcji poll.

W przeciągu roku od pierwotnej propo-

zycji zmiany się ustabilizowały i prawdopo-

dobnie już niedługo sterowniki będą mu-

siały być przepisane na nowe API. Jednak

zmiany w większości przypadków powinny

być trywialne. Zmiany zostały dobrze przy-

jęte przez społeczność i prawdopodobnie

wejdą w życie już z wydaniem 2.6.24.

Rodzina znowu razem?

Wszyscy dobrze wiemy, jak podobne

są do siebie architektury i386 i jej ,,cór-

ka'' x86_64. Jednak w Linuksie są one

rozwijane w dwóch oddzielnych gałę-

ziach kodu. Gałęzie te są jednak bardzo

do siebie podobne, często błędy występu-

jące w jednej, trzeba od razu poprawiać

w drugiej, podobnie z ulepszeniami.

Nawet opiekuna mają wspólnego.

Dlatego też Ingo Molnar zapropono-

wał połączenie obu architektur. Spo-

tkał się jednak z protestem Andi Kle-

ena, ich opiekuna. Twierdzi on, że choć

prowadzi to do częstej duplikacji wysił-

ków, to rozdzielenie architektur powin-

no zostać utrzymane choćby ze względu

na zmniejszenie potrzeby szukania regre-

sji przy każdej zmianie. Zapowiada się

więc ciekawa dyskusja, której efekt mo-

że mieć fundamentalne znaczenie dla ca-

łego systemu.

http://lwn.net/Articles/243992/

http://lwn.net/Articles/214186/

www.cyberus.ca/~hadi/usenix–paper.tgz

listopad 2007

dział prowadzi: Remigiusz Modrzejewski lrem@o2.pl

Nowsze NAPI na ukończeniu

P rawdopodobnie pierwszym rynkiem zdo-

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika: