Kernel Traffic #168 For 2002/05/27

There were 416 different contributors. 214 posted more than once. 164 posted last week too.

Sporo rzeczy ostatnio zdarzyło się w serii 2.5.x; szczegóły możecie zobaczyć w plikach z listą zmian, które dołączane są do kolejnych wersji. Pomyślałem jednak, że napiszę o 2.5.14, jako że w tej wersji pojawiły się interesujące i fundamentalne zmiany tego, w jaki sposób w pamięci wirtualnej traktowane są ,,brudne'' strony.

(Wielkie zmiany tak naprawdę odbyły się w 2.5.12, ale 2.5.13 zawierało różne mniejsze poprawki i ulepszenia, a 2.5.14 zawiera kilka poprawek, szczególnie odnośnie funkcji truncate, więc mam nadzieję, że jest ono już całkiem _stabilne_ )

Główne zasługi należy przypisać Andrew Mortonowi, jego zmiany nie tylko sprawiają, że kod jest ładniejszy, ale wydaje się też, że dzięki nim poprawiła się wydajność w wielu sytuacjach.

W 2.5.x jest też sporo innych rzeczy, ale tylko parę jest tak istotnych. Testujcie proszę (ale bądźcie też ostrożni - trzymanie kopii zapasowych jest zawsze dobrym pomysłem).

Bert Hubert spytał o podsystem pamięci wirtualnej: gdzie w przestrzeni rozwiązań między rmap Rika van Riela, a przepisaniem VM w 2.4 przez Andreę Arcangeli, mieści się istniejący podsystem pamięci wirtualnej? Andrew Morton wyjaśnił:

,,VM'' jest szerokim pojęciem. Alokowanie pamięci, wymiana stron, partycja wymiany i wszystkie takie rzeczy są takie same jak w 2.4.bieżące. tzn: to jest VM Andrei z chwili, gdy jego zmiany przestały wchodzić do głównego jądra.

Zrobiłem tam minimalne modyfikacje mające na celu nauczenie algortymu alokującego strony, żeby cała brudna pamięć była z powrotem zapisywana przez strony, nie czasem przez strony, a czasem przez bufory. Dodałem też wsparcie dla nowego ,,zapisywania klastrowego'', które może być wykonywane przez address_spaces.

Całość nie jest prawdopodobnie tak dobrze podrasowana, jak mogłaby obecnie być, ale nie widzę powodu, by to dostrajać. Tak długo, jak VM nie wpływa na rozwój 2.5 i wydajność 2.5, najlepiej zostawić ten podsystem w spokoju, czekając na VM w 2.6.

Zmiana, o której napisał Linus jest następująca:

W 2.4 zabrudzone dane z wywołania systemowego write(2) są zawarte w buffer_heads i umieszczane na globalnej liście buforów do zapisania. Zabrudzone dane ze współdzielonych odwzorowań są dowiązywane do właściwego i-węzła.

W 2.5 zniknęła lista buforów, a brudne dane z write(2) są teraz obsługiwane w taki sam sposób, jak zabrudzone dane z mmap().

Ponieważ funkcje kupdate i bdflush działały na LRU buforów, zostały wprowadzone zmiany, które robiły to samo względem i-węzłów, zamiast względem buforów.

Teraz jest to zorientowane na strony.

Daniel Pittman, który doświadczył padu systemu plików ext3 w pewnych określonych okolicznościach, zapytał, czy może ,,oczekiwać'', że zobaczy to naprawione w bieżącej wersji. Linus odparł:

,,Oczekiwanie'' jest zbyt silnym słowem. Powiedziałbym raczej ,,nadzieja'' - pewna liczba błędów truncate została naprawiona, ale nikt nie wie, czy to było to, co akurat uderzyło w Ciebie.

Podejrzewam, że prawdziwa odpowiedź to taka, że bardzo chcielibyśmy, byś to przetestował, ale jeśli kolejne wystąpienie problemu będzie dla Ciebie zbyt bolesne do przeżycia, to może nie powinieneś tego robić...

Daniel odważył się zrobić trochę testów i ogłosił: "Wydaje mi się, że 2.5.14 działa poprawnie z 2k systemami plików ext3, przynajmniej przy minimalnym używaniu. Nie wykonywałem żadnych testów przy ekstermalnym obciążeniu ani nic takiego, byłem ostrożny." Ale w trakcie startu system zgłosił ostrzeżenia. On i Andrew w poszukiwaniu problemu wymienili jeszcze parę listów i podwątek się skończył.

Co więcej, w odpowiedzi na początkowe ogłoszenie Linusa, Marcin Dalecki podesłał tonę łatek na kod IDE i ludzie debatowali na temat różnych technicznych spraw. W pewnym momencie Anton Altaparmakov wybuchnął: " Odkąd jesteś nowym opiekunem IDE, widzieliśmy tylko, że usuwasz jedną cechę za drugą, nazywając to porządkami, bez adekwatnego albo nawet bez żadnego (!) zastępnika, zmieniasz nazwy wszystkich funkcji wte i wewte i psując wszędzie podstawowe ide. Wszystkie krytyczne poprawki błędów wydają się być zasługą innych ludzi grzebiących w Twoim kodzie, który nie wyzwala przesadnego zaufania dla Ciebie... Nawet Alan Cox powiedział chwilę temu, że głosuje za tym by Ci nie ufać (trochę go tu przeformułowałem), ze względu na wprowadzane przez Ciebie zmiany." A Linus napisał:

Kogo to obchodzi? Czy znalazłeś _cokolwiek_ co Marcin usunął i co było było coś warte? Ja na pewno nie.

Ludzie, musicie sobie uświadomić, że warstwa IDE ma za sobą osiem LAT totalnego zaśmiecania. _Nigdy_ wcześniej nie była czyszczona. Jej części są tak okropne, że aż strach.

Uwierzcie mi: _dużo_ łatwiej uskuteczniać rzeźby i śmiecić mając czysty kod. Jeśli chcesz, możesz sam to zrobić. Nie będziesz potrzebował wtedy opiekuna, który będzie przyczepiał niepotrzebne rzeczy.

Cała informacja oferowana przez /proc/ide jest dostępna przez hdparm, a dla Twojego drogiego wbudowanego systemu to wyraźnie zabiera mniej miejsca, gdy jest w przestrzeni użytkownika. Na czym więc polega problem?

Głosuję za tym by usnąć tak wiele, jak to tylko jest w ludzkiej mocy.

"Everything should be made as simple as possible, but not simpler" - Albert Einstein

Pomyślcie o tym i naprawdę to _zrozumcie_.

W pewnym miejscu Alan Cox wskazał, że: "w /proc/ide są użyteczne informacje, których nie da się obecnie łatwo uzyskać innymi sposobami - który kontroler steruje dyskami, jakie są urządzenia itd." Linus zaś odparł:

Chciałbym bardzo, by ktoś dodał urządzenia do prawdziwego drzewa urządzeń, w którym to miejscu takie informacje byłyby widoczne..

W tej chwili devicefs nie jest nawet domyślnie montowany, ale to jest _naprawdę_ jedyny ogólny sposób na pokazywanie takich rzeczy. Jeśli ktoś jeszcze tego nie widział, niech zrobi:

mount -t driverfs /devfs /devfs

i niech tam popatrzy.. W szczególności, jeśli macie system PCI z drzewem urządzeń USB (albo _wiele_ takich drzew), zwróćcie uwagę na rzeczy takie jak:

/driverfs/root/pci0/00:1f.4/usb_bus/000/

i nie byłoby niemożliwe (nawet niekoniecznie trudne) zmuszenie kontrolera IDE do wyeksportowania ,,drzewa urządzeń IDE'' w taki sam sposób, jak kontroler USB teraz eksportuje ,,drzewo urządzeń USB''.

Myślę, że dla rzeczy takich jak hotplug itd, driverfs jest, w rezultacie, jedynym wyjściem, po prostu dlatego, że daje pełną (i jednoznaczną) ścieżkę do _każdego_ urządzenia i może zupełnie nic nie wiedzieć o magistrali.

Ale oczywiście istnieje tu potencjalna kwestia kompatybilności.

Peter Chubb ogłosił: "W Linuksie istnieje obecnie ograniczenie na systemy plików wynoszące 2TB i jest tak nawet na systemach 64-bitowych, ponieważ w wielu miejscach przesunięcie bloków na dysku jest określony zmienną unsigned lub zmienną będąca 32-bitową liczbą całkowitą." Podał odnośnik do łatki, implementującej "typ, sector_t. Zmienne tego typu mają trzymać offsety w sektorach i blokach." Dodał: "Na starym pentium mam teraz podmontowany jako JFS plik o rozmiarze 15Tb pod urządzenie loop -- i wydaje się, że wszystko działa. Niewiele jest programów w trybie użytkownika, które wymagałyby poprawienia (pewnie parted, mkfs.??? itp) tak, by dawały sobie radę z nowym błędem GETBLKSIZE (powinny używać innego mechanizmu, to znaczy GETBLKSIZE64, albo po prostu przechodzić do końca partycji i patrzeć na przesunięcie). " Andrew Morton odpowiedział: "Mój głos: włączyć cholerstwo gdy się jeszcze (prawie) daje nałożyć. 2TB powstrzymują teraz niektórych przed użyciem 2.4. Oczywiście 2.6 będzie już potrzebować 64. bitowych numerów bloków. Następną przeszkodą będą indeksy cache'u stron w mapowaniu blockdev. Limit, który tam występuje to 8TB lub 16TB, to zależy od poprawności znaków."

Łatka spodobała się to też paru innym gostkom. Marcin Dalecki, opiekun IDE, napisał, że nałożyłby kawałki łatki dotyczące IDE.

Trochę później Peter ogłosił poprawioną wersję łatki dla jądra 2.5.15, a Christoph Hellwig wyraził swoje poparcie, pisząc: "To naprawdę dobrze wygląda, chciałbym wkrótce zobaczyć coś takiego włączone do jądra!"

W trakcie prowadzonej dyskusji ludzie zaczęli mówić o tym, jak wiele czasu zabiera im kompilacja jądra. W pewnym momencie, w związku z rozmową o specyficznej przyczynie zwalniania, Andrew Morton zauważył: "Ostatecznym rowiązaniem wszystkich problemów jest włączenie kbuild-2.5, a potem nauczenie go używania względnych nazw ścieżek w trakcie wykonywania budowania z drzewa źródeł. Najprawdopodobniej nie jest to trudne, ale poważnie zamierzam się dowiedzieć dlaczego to nie jest możliwe." A Linus Torvalds odpowiedział:

Mam nadzieję, że możemy dotrzeć do tego małymi kroczkami, wolę to od wielkiego, traumatycznego włączenia. Chciałbym po prostu spróbować włączyć to po kawałeczku.

W szczególności dlatego, że moim zdaniem obecny system nie jest aż tak niedobry.

Keith Owens ponownie próbował uzyskać jakąś odpowiedź Linusa Torvaldsa w sprawie kbuild. Napisał:

Trzecia i ostatnia próba. Oryginał został wysłany 2. maja, drugi list wysłałem 14. maja i ciągle nie mam odpowiedzi od Linusa.

Linus, kbuild 2.5 jest gotowy do włączenia do głównego drzewa 2.5. Jest szybszy, lepiej udokumentowany, łatwiej pisać w nim reguły budowania, ma lepsze ułatwienia instalacji, pozwala oddzielić drzewo źródeł od drzewa plików obiektów, może wykonywać równoległe budowania z tego samego drzewa źródeł i jest istotnie lepszy od istniejącego systemu budowania jądra.

Odnosząc się prawdopodobnie do dyskusji, którą opisano w wątku ,,[ANNOUNCE] Wycofanie się z Otwartych Projektów NDS/NTFS/M2FS dla Linuksa'', Nicolas Pitre napisał: "Linus to drań. Zapomniałes?" A Tomas Szepe dodał:

To się staje rzeczywiście śmieszne.

Linus, co powoduje, że ignorujesz wyniki pracy Keitha?

Czy sądzisz, że spędził tyle czasu pracując nad kbuild25 by zakończyć całą sprawę informacją: linus-cholera-czy-w-końcu-spojrzysz-na-to-nie-zamierzam-cię-pytać-w-nieskończoność?

Nie zamierzam odpowiadać za Linusa, ale powiem, że Linus bierze łatki poprawiające i ulepszające istniejący w 2.5 system kbuild.

Być może należałoby pozwolić Linusowi i innym spróbować ponaprawiać istniejącego kbuilda, a gdy/jeśli nie będzie działał, będziemy mieli coś, co działa.

Wayne Brown w pewnym momencie wtrącił: "Z drugiej strony, ci z nas, którzy nie wyczekują na kbuild 2.5 są wdzięczni za każde możliwe opóźnienie. "

W innym miejscu Jeff Millar odpowiedział na początkowe ogłoszenie Keitha. Zapytał, czy którakolwiek z gałęzi jądra (takich jak gałąź, którą opiekuje się Dave Jones), wzięłaby nowy kbuild. Keith odpowiedział, że gdy tylko Linus to weźmie, wszyscy inni pójdą za nim. Także Dave odpowiedział Jeffowi:

Myślałem o tym kilkakrotnie w ciągu ostatnich tygodni, ale włączenie tbh do któregoś z drzew innych niż drzewo Linusa nie ma sensu większego ponad to, że być może dałoby to możliwość przetestowania tego we wczesnym stadium.

Obecne łaty kbuild2.5 będą się dobrze nakładały na jądra z mojego drzewa, ale ze względu na rzeczy takie jak nowa warstwa wejścia, nie dają się włączyć do drzewa Linusa. Niektóre pliki są w innych miejscach, więc pliki Makefile.in w kbuild2.5 wskazują na niewłaściwe miejsca.

Jasne, mogę to włączyć, ale tbh nie jest obecnie warte wysiłku, który trzeba by włożyć w poprawianie tych plików, przynamniej do chwili, w której Linus powie y-hy albo e-e.

Halil Demirezen spytał, czy modem HCF Conexant na PCI jest obsługiwany pod Linuksem. Alok K. Dhir odesłał go pod adres: http://www.mbsi.ca/cnxtlindrv/ i dodał: "Uwaga: Działa tylko dla jąder bez SMP. Moja maszynka SMP zamiera na dobre, gdy stara się dogadać z modemem przez ten sterownik HCF." W innym miejscu Halil zaobserwował, że część kodu jest dostępna na na GPL, a część na licencji BSD. Ktoś inny zwrócił uwagę na to, że sam kod jest dostępny w formie źródeł, ale skonsolidowany z biblioteką dostępną jedynie w fromie binariów, zawierającą główny kod dla modemów z Conexant.


Kernel Traffic Latest \| Archives \| People \| Topics	Wine Latest \| Archives \| People \| Topics	GNUe Latest \| Archives \| People \| Topics
Czech

1.	5 maj 2002 - 21 maj 2002	(283 posts)	Stan VM, ext3 i kodu IDE w 2.5
2.	9 maj 2002 - 17 maj 2002	(41 posts)	Stan obsługi dużych plików
3.	16 maj 2002 - 17 maj 2002	(22 posts)	Stan kbuild
4.	16 maj 2002 - 20 maj 2002	(60 posts)	Więcej dyskusji na temat kbuild
5.	21 Maj 2002 - 22 Maj 2002	(7 posts)	Stan obsługi modemu HCF

Kernel Traffic #168 For 2002/05/27

By Zack Brown

Translated By: Maja Królikowska