aktualności
10
grudzień 2007
dział prowadzi: Remigiusz Modrzejewski l rem@o2.pl
Kernel
aktualności
11
www.lpmagazine.org
dział prowadzi: Remigiusz Modrzejewski lrem@o2.pl
Kernel
O dokumentacji
Michael Kerrisk, wieloletni opiekun
dokumentacji Linuksa, wygłosił cieka-
wą mowę na szczycie LinuxConf Europe
2007. Traktował w niej o pozytyw-
nym wpływie dokumentacji na jakość
kodu, a pisząc strony podręcznika do róż-
nych podsystemów znalazł w swojej ka-
rierze kilka poważnych błędów. Naj-
poważniejszym z nich był błąd w spli-
ce(), bo można było dzięki niemu zawie-
sić program w stanie, w którym nie dało
się go zabić. Dawało to łatwą możliwość
wykonania piorunującego lokalnego ata-
ku DOS. Większe znaczenie, a także bar-
dziej specyficzne dla piszących dokumen-
tację mają znalezione przez niego niedo-
ciągnięcia projektowe. Przykładem,
którym się posłużył były mlock()
i remap_file_pages(). Oba wołania syste-
mowe przyjmują, jako wielkość pamię-
ci dowolną liczbę, potem zaokrąglają do
pełnej strony. Problem polega na tym, że
mlock() zaokrągla w górę, a remap_fi-
le_pages() w dół. Niekonsekwencje
takie, jak ta utrudniają korzystanie z in-
terfejsów, co w efekcie może prowadzić
do błędów w korzystającym z nich ko-
dzie. Prawdą jest, że dokumentowanie
to jeden z podstawowych etapów każde-
go projektu, a Linux powstaje poprzez
burzliwe dyskusje i szybkie implemen-
tacje. Może warto jednak częściej przy-
siąść i opisać spokojnie, co zamierza się
wykonać.
Sysctl() znowu w niełasce
Już w jądrze 2.6.19 miało dojść do histo-
rycznego aktu – usunięcia wołania sys-
temowego sysctl(). Historycznego nie ze
względu na wagę tego wołania, lecz zła-
manie ABI przestrzeni użytkownika. To
według założeń powinno działać wiecz-
nie, ale samo sysctl() przegrało konkuren-
cję z podsystemem /proc/sys i praktycznie
nigdy przez nikogo nie było wykorzysty-
wane. Jako kod jest nieużywany
i rzadko przeglądany, a więc może
w przyszłości ulec jakiemuś przypadko-
wemu uszkodzeniu, a to może zaowoco-
wać poważnym błędem, szkodzącym ca-
łości jądra. Dlatego też Eric Biederman
podjął kolejną próbę uporania się z tą za-
szłością i zaproponował oznaczenie sy-
sctl(), jako przeznaczonego do usunięcia
w 2010 roku. I znowu spotkał się z pro-
testami osób, trzymających się kurczo-
wo zasad. Jak wypomniał Alan Cox, jeśli
ktoś ma praktyczny powód, by w ogóle
korzystać z sysctl(), to jest on na tyle po-
ważny, by nie móc z niego zrezygnować
cokolwiek by się nie działo.
Z drugiej strony Andrew Morton przeko-
nuje, że samo oznaczenie nie jest niczym
strasznym. Przez kilka lat osoby, używa-
jące tego wołania będą konfrontowane
z ostrzeżeniami o planowym usunięciu
– na na koniec zawsze się będzie można
wycofać. Choć dobrze byłoby mieć za
sobą te cykliczne burze w szklance wody.
Większe strony, większe problemy
J
ak powszechnie wiadomo, Linux bardzo
różni się od systemu Windows, a jedną
z poważniejszych niskopoziomowych róż-
nic jest zarządzanie pamięcią. Ostatnio
użytkownicy, kupujący komputery z komer-
cyjnymi systemami na pokładzie przekonu-
ją się, że mimo posiadania 4GB RAM-u
system ,,widzi” jedynie około 3GB. Co cie-
kawe problem ten występuje także w opar-
tym na Uniksie – Apple OSX. Jednak po-
ważniejszym problemem jest fragmentacja
pamięci. Użytkownicy Windows, którym
zdarza się trzymać system włączony całymi
tygodniami po pewnym czasie obserwują
coraz gorszą jego pracę. Ostatecznie nastę-
pują problemy z alokowaniem pamięci do
programów, mimo iż wolna jej ilość wie-
lokrotnie przewyższa potrzeby. Dzieje się
tak, dlatego że programy potrzebują dużych
i ciągłych obszarów pamięci, te jednak są
poszatkowane przez mniejsze zmienne,
a żaden z tych problemów nie dotyczy Li-
nuksa. Dzieje się tak ze względu na spo-
sób, w jaki Linux zarządza pamięcią. Me-
chanizm nazywa się pamięcią wirtualną,
co sugeruje od razu metodę jego działa-
nia. Programy egzystują w wirtualnej prze-
strzeni adresowej – niezależnej od rzeczy-
wistego rozkładu komórek pamięci w sprzę-
cie. Dzięki temu 32-bitowe programy nadal
są ograniczone do 4GB pamięci, ale każdy
program może zająć swoje osobne 4GB. Nie
grozi również brak ciągłej pamięci – pro-
gram zawsze ją dostanie. Programista nie
musi sobie zdawać sprawy, że to jądro skle-
ja ją z nieciągłych kawałków rzeczywistej
pamięci. Mechanizm jest stabilny i dzia-
ła poprawnie już od wielu lat, z pewnymi
zmianami praktycznie od początku. W prze-
ciągu tych lat ilość RAM-u jaką przecięt-
nie dysponujemy zwiększyła się tysiąckrot-
nie, lecz obsługiwana jest nadal tak samo.
W szczególności oznacza to wykorzysty-
wanie sprzętowych stron pamięci o rozmia-
rze 4 kilobajtów. Stronicowanie co praw-
da większości osób kojarzy się wyłącznie
z przestrzenią wymiany (ang. swap space
zarówno plik, jak i partycja), lecz w Linuk-
sie jest to właśnie podstawowy mechanizm
zarządzania wszelką pamięcią.
Mijają lata, a megabajty przekształci-
ły się w gigabajty, natomiast system zarzą-
dzania pamięcią zaczyna sapać. Nie tyl-
ko ze względu na samą obsługę pamię-
ci, która wciąż jest akceptowalnym narzu-
tem. Największym problemem są urządze-
nia wejścia/wyjścia. Karty sieciowe, prze-
znaczone do wysokich transferów w celu
ograniczenia liczby pakietów, a więc i prze-
rwań – stosują wielkie ramki. Aby przesłać
taką wielką ramkę potrzebny jest ciągły ob-
szar fizycznej pamięci, ewentualnie podzie-
lony na jakąś ograniczoną ilość mniejszych.
Systemy plików potrzebują większych blo-
ków na indeksy, aby zmniejszyć ilość ope-
racji wyszukiwania (ang. seek – najkosz-
towniejsza czasowo operacja wykonana
przez dysk) przy dostępie do dowolnego
pliku. Ostatecznie TLB (ang. Translation
Lookaside Buffer – bufor, odwzorowujący
adresy wirtualne na fizyczne wykorzysty-
wane przez pamięć podręczną) w nowych
procesorach Intel ma zaledwie 128 wpisów.
Przy czterokilobajtowej stronie pozwala to
wykorzystać zaledwie pół megabajta cache-
'u, a procesory te posiadają go nawet osiem
razy więcej.
Rozwiązanie nasuwa się samo – pod-
nieść rozmiar tych stron i po kłopocie. Roz-
sądny rozmiar wydaje się oscylować, w za-
leżności od zastosowania, między 8 a 32KB.
Tu jednak niespodzianka – procesory x86
takich rozmiarów nie obsługują. Wielkość
strony ustawić można na kilka różnych
potęg dwójki, lecz nie ma nic między 4KB
a 2MB. Niestety, pomysł ten odpada w przed-
biegach. Alokując po 2MB niezależnie, czy
potrzebny jest megabajt czy kilobajt bar-
dzo szybko zmarnowalibyśmy cały dostęp-
ny RAM. Potrzebne jest rozwiązanie cał-
kowicie programowe, a do tego najlepiej
by było niezależne od tego, na jakiej ar-
chitekturze działa. Oczywiście osoby zaan-
gażowane w rozwój systemu zarządzania
pamięcią zdawały sobie z tego sprawę od
dawna. Spotkali się niedawno na szczycie
w Cambridge, gdzie ustalili kilka sensow-
nych wyjść z tej sytuacji. Jednak, jak się
okazało później, każdy ustalił swoje – bez
wspólnego consensusu – przybliżę te po-
ważniejsze.
Najświeższy pomysł pochodzi od czło-
wieka najdłużej zaangażowanego – Andrea
Arcangeliego, twórcy znacznej części aktu-
alnego kodu pamięci wirtualnej. Jego łatka
CONFIG_PAGE_SHIFT jest realizacją pro-
stego pomysłu, sugerowanego już wcze-
śniej do jądra 2.4, pod wiele mówiącą na-
zwą large PAGE_SIZE. Jak łatwo się do-
myślić, to chodzi o separację pojęcia strony
