Linux 2.6.31
- Dodano: 8 September 2009
- Wprowadził: przemoc
- Komentarze: 48
Torvalds nie dotrzymał danego słowa i nie wydał nowej wersji jądra Linux w amerykańskie Święto Pracy (ang. Labor Day). Użytkownicy oraz deweloperzy musieli przełożyć świętowanie na 9 września z powodu spóźnionego anonsu. Jak zwykle mamy do czynienia nie tylko z usprawnieniami, ale też i licznymi nowościami. Przyjrzyjmy się więc bliżej niektórym zmianom, które zaszły w ciągu ostatnich 3 miesięcy, tzn. od wydania wersji 2.6.30.
Zacznijmy od najciekawszego, a mianowicie Performance Counters (tłum. liczniki wydajności), które wreszcie zostały włączone do jądra. Jest to podsystem eksponujący poprzez swoje API specjalne rejestry, dostępne w większości współczesnych procesorów, przechowujące wartości związane z konkretnymi zdarzeniami typu liczba wykonanych instrukcji (ang. instructions), chybień pamięci podręcznej (ang. cache-misses), źle przewidzianych rozgałęzień (ang. branches mis-predicted), itp. bez spowalniania samego jądra czy aplikacji. Rejestry te mogą także generować przerwania w przypadku przekroczenia progu na liczbę zdarzeń, dzięki czemu mogą być używane do profilowania kodu wykonywanego przez CPU.
Od strony użytkownika wykorzystanie ich wymaga skorzystania ze specjalnie do tego napisanego narzędzia perf, dostępnego w katalogu tools/perf/. Jest to oprogramowanie przestrzeni użytkownika (ang. userspace), więc trzymanie go w drzewie kernela jest nietypową decyzją, ale wydaje się, że uzasadnioną dotychczasowymi doświadczeniami – polecam przejrzenie wątku [GIT PULL] Performance Counters for Linux, gdzie Christoph Hellwig w odpowiedzi na mail Ingo Molnara wyraża sprzeciw wobec takiego rozwiązania, co jest początkiem dalszej dyskusji, w której głos zabrał również znany wszystkim Fin. Ów perf obsługuje kilka trybów pracy:
top– udostępniający interfejs podobny do znanej aplikacjitop, gdzie można ograniczać zakres interesujących nas zdarzeń, procesów czy rdzeni,recordireport– umożliwiające odpowiednio nagranie do pliku i odczytanie oraz pokazanie na ekranie profilu,annotate– pozwalający na odczytanie danych i pokazanie kodu uzupełnionego o dodatkowe kolumny z uzyskanymi wynikami,stat– wykonujący podaną komendę (wielokrotnie, jeżeli tak się zaznaczy) i zbierający statystyki dotyczące wydajności, które po zakończeniu drukuje na ekran,list– podający listę obsługiwanych zdarzeń przez posiadany sprzęt.
Po więcej szczegółów i kilka przykładów użycia zapraszam do lektury artykułu na LWN oraz ciekawych komentarzy do niego: Perfcounters added to the mainline, a także samego anonsu o ostatniej wersji tego podsystemu: Performance Counters for Linux, v8.
KMS (o którym można przeczytać w 13. akapicie utrzymanego w żartobliwym tonie niusa Czy będzie jądro Linux w wersji 2.6.29-rc9? Nie!) został wzbogacony o obsługę kości ATI R1xx, R2xx, R3xx, R4xx i R5xx, czyli Radeonów aż do kart X1950. Trwają prace nad obsługą R6xx i 7xx, czyli Radeonów z serii od HD2xxx do HD4xxx. Wymagało to włączenia do jądra pomocnika dla DRM w postaci podsystemu zarządzania pamięcią GPU nazwanego TTM, dedykowanego procesorom graficznym mającym dostęp do różnych rodzajów pamięci. [commity 771fe6b9, ba4e7d97]
Netfilter, czyli framework umożliwiający w jądrze Linuksa na wpinanie się i przechwytywanie oraz modyfikowanie pakietów sieciowych, został wzbogacony o pasywne rozpoznawanie systemów operacyjnych (ang. passive OS fingerprinting). Wypada dodać, że sam koncept przedstawiony został w oprogramowaniu Siphon, jednak było ono tak ułomne, że Michał Zalewski postanowił wykorzystać świetny pomysł i dokonać własnej implementacji. Tak też narodził się p0f v1, który był prawdopodobnie pierwszym pełnoprawnym narzędziem do rozpoznawania systemów operacyjnych na bazie analizy wysyłanych przez nie pakietów sieciowych. Później program był wielokrotnie aktualizowany doprowadzając do powstania używanego do dziś p0f v2. Jest on włączany do różnych systemów operacyjnych, a blisko 6 lat temu został w pewnej części wbudowany w OpenBSD PF firewall (od wersji 3.4). Krótki opis na LWN: Passive OS fingerprinting added to netfilter. Strona projektu to: http://www.ioremap.net/projects/osf. [commit 11eeef41]
Miłośników systemów plików i okolic niezmiernie ucieszy fakt dołączenia do jądra:
- CUSE, czyli rozszerzenia FUSE umożliwiającego implementację urządzeń znakowych w przestrzeni użytkownika – po szczegóły, także dotyczące wykorzystania tego dodatku, odsyłam do zeszłorocznego artykułu na LWN, pt. Character devices in user space
oraz strony projektu OSS Proxy [commit 151060ac], - Fsnotify, będącego ujednoliconym interfejsem po stronie jądra do informowania o zmianach w systemie plików (ang. filesystem notification), z którego zaczęły korzystać dnotify i inotify, a w przyszłości będzie to robić także fanotify (przybliża go bliżej wątek fanotify: the fscking all notification system), który wejdzie do jądra w przyszłych wersjach [commity 90586523^..e42e2773, a092ee20].
Podsystem zarządzania pamięcią nie został zapomniany. Wręcz przeciwnie.
- Dzięki zastosowaniu różnych heurystyk (opisanych szerzej w commitach), wyrzucenie zamapowanych wykonywalnych stron pamięci (ang. mapped executable pages) z listy aktywnych stało się dużo trudniejsze. Ich agresywne buforowanie jest istotne dla zapewnienia płynności działających aplikacji, gdyż w razie braku w pamięci potrzebnego do wykonania w danej chwili kodu (czy to pochodzącego z samego programu czy też wykorzystywanych przez niego bibliotekach), następuje odczyt z dysku, który jest bardzo wolny. [commity 56e49d21, 6fe6b7e3, 8cab4754]
- Sporo uwagi poświęcono też mechanizmom związanym z alokacją stron pamięci. Dzięki przeszło 20 łatkom, Page allocator jest teraz bardziej przejrzysty, “inteligentny” oraz wydajniejszy. [commity d239171e^..72807a74]
- Wprowadzono ponadto wykrywanie sekwencyjnych odczytów z obszarów mapowanych w wirtualnych przestrzeniach adresowych (np. anonimowych lub mapujących pliki) aby możliwe było przeprowadzenie odczytów z wyprzedzeniem (ang. readahead). Dodano także algorytm odczytu z wyprzedzeniem wykrywający sekwencyjność dostępu bazując na kontekście zbuforowanych stron (ang. page cache context based readahead algorithm), przez co jeżeli dwa lub więcej współbieżnych odczytów jest przemieszanych, ale każdy z osobna jest sekwencyjny, zostanie to wykryte. [commity 70ac23cf, 2fad6f5d, 10be0b37, 7ffc59b4]
Z punktu widzenia użytkownika powyższe zmiany oznaczają “przyspieszenie” (zmniejszenie czasu reakcji) aplikacji w środowisku o dużym obciążeniu pamięci, intensywnie alokujących pamięć, jak i ochoczo poruszających się po mapowanych obszarach.
Programistów jądra ucieszy natomiast wprowadzenie odpowiedników valgrindowego memchecka, Kmemcheck i Kmemleak. Pierwszy dodatek wykrywa i ostrzega o użyciu niezainicjowanej pamięci w jądrze. Jest to jednak funkcja typowo debugowa, ponieważ włączenie jej znacząco spowalnia pracę systemu i dwukrotnie zwiększa zużycie pamięci. Warto zajrzeć do jego dokumentacji: Documentation/kmemcheck.txt. Drugi – pozwala wykrywać wycieki pamięci w jądrze w sposób podobny do śledzącego śmieciarza (ang. tracing garbage collector), z tą różnicą, że osierocony obiekt nie jest zwalniany, za to wątek jądra skanując pamięć co 10 minut umieszcza informacje o takich nowych znikąd niewskazywanych obiektach w /sys/kernel/debug/kmemleak i ostrzega o nich użytkownika. Szerzej temat podejmuje artykuł z LWN: Detecting kernel memory leaks. Dokumentacja jest dostępna i w tym przypadku: Documentation/kmemleak.txt.
Warto wspomnieć o dodanej obsłudze urządzeń USB 3 i sprzętu implementującego interfejs xHCI, zgodnie ze specyfikacją w wersji 0.95. Póki co nie skorzystamy z ostatniego sterownika, gdyż nowa specyfikacja nie ma jeszcze na rynku promującego ją towaru.
Na koniec wprowadzone modyfikacje, które mogą zainteresować deweloperów.
- Zmieniono zachowanie odczytów z
/dev/zero, które obecnie mogą być przerwane przez sygnały, co ma pomóc z nieprzyjemnymi opóźnieniami przy dużych odczytach z tego wirtualnego urządzenia, niestety kosztem zmiany ABI w przestrzeni użytkownika. Według Linusa, czyli twórcy łaty, nie powinno to jednak niekorzystnie wpłynąć na żadną “dobrze wychowaną” aplikację. Rozumowanie takie wydaje się zasadne, ale tylko częściowo, ponieważ prawidłowo napisany program ma ustawione wznawianie przerwanych wywołań systemowych (w Linuksie jest to zachowanie domyślne, chyba że ustawimy własną funkcję obsługi sygnału poprzez wywołaniesignal()bez późniejszegosiginterrupt()z flagą równą0albo przekazując dosigaction()wskazanie do strukturysigaction, w której brak flagiSA_RESTART) lub przewiduje pojawianie się błęduEINTRi stosownie go obsługuje. O ile pierwszy przypadek jest w istocie bezproblemowy, o tyle w drugim programiści linuksowi mogli dotychczas pomijać obsługę błęduEINTRprzy odczycie z/dev/zero, wiedząc, że to nieosiągalna ścieżka. Tych ostatnich czeka drobne poprawianie kodu. [commit 2b838687] - Usprawniono wywołanie systemowe
splice()(służące do przenoszenia danych między dwoma deskryptorami plików, z których jeden musi być potokiem, z pominięciem kopiowania między przestrzenią adresowania jądra a użytkownika) o obsługę potoków podanych jednocześnie na wejściu jak i wyjściu. [commit 7c77f0b3] - Dodano wywołanie systemowe
rt_tgsigqueueinfo(), będące uzupełnieniem dotgkill()i wątkowym odpowiednikiemrt_sigqueueinfo(), które wysyła sygnał z pomocniczą informacją do grupy wątków. Jest to ułatwienie dla osób migrujących czy portujących aplikacje z innych systemów, gdzie tego typu mechanizm dostarczania okraszonych sygnałów na poziomie wątków już istnieje. [commit fcec9bf1]
W morzu zmian przytoczone powyżej wybrane zagadnienia nie mogą oddać trudu i wysiłku włożonego w przygotowanie nowej wersji jądra, dlatego obowiązkową jest lektura ChangeLoga. Można też zapoznać się z serią artykułów w serwisie heise pt. Jądro Linux – co przyniesie wersja 2.6.31:
- cz. I – Nowe sterowniki WLAN i inne zmiany w obszarze obsługi sieci,
- cz. II – KMS dla Radeonów, sterownik X-Fi, obsługa GPU Intela i urządzeń V4L/DVB,
- cz. III – podkręcony btrfs, podsystem IDE na bocznym torze,
- cz. IV – śledzenie kodu, zarządzanie pamięcią i wirtualizacja.
Szybsze będzie jednak przeczytanie w serwisie LWN.net wypunktowania, co przedostało się przez okno scalania:
Można tam też znaleźć jakie nowe sterowniki urządzeń pojawiły się w jądrze, więc nie będę już ich tutaj przepisywał (tak jak miało to miejsce w przypadku poprzedniego niusa nt. jądra w wersji 2.6.30).
Spakowane archiwum ze źródłami znajdziemy tam gdzie zawsze: http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.31.tar.bz2. Nie pozostaje nic innego, jak rozgrzać nasze łącza, szare komórki i procesory sekwencją git pull && make oldconfig && make oraz odpowiedzieć na pytanie: czy noszenie skarpetek gdy chodzimy w sandałach jest zbrodnią?
Więcej informacji: http://kernelnewbies.org/Linux_2_6_31
Znalazłeś literówkę? Zgłoś ją używając formularza!
Jeśli uważasz, że ten nius jest nieobiektywny, przedstawia nieprawdziwe wydarzenie, jest spamem lub nie spełnia standardów serwisu, napisz raport.
Niusy na podobny temat:
Komentarze są prywatnymi opiniami dodających je osób. Prosimy o zachowanie kultury wypowiedzi. Komentarze obraźliwe oraz obniżające poziom serwisu będą usuwane. Więcej w regulaminie komentowania.
48 komentarzy
Wszystkie autorskie niusy w serwisie publikowane są na licencji Creative Commons Uznanie autorstwa 2.5 Polska.
Wow, naprawdę imponujący (jak na "standard" osnews) artykuł.
Gdybym miał konto na naszej-klasie, autor mógłby liczyć na eurogąbkę donacji.
Często nie piszę, ale jeżeli już, to staram się, żeby nius chociaż trochę mięsa w sobie miał. Skoro co najmniej kilku osobom się podoba, tzn. że strategia ta ma sens, tym samym nie jestem "zniechęcony" przed pisaniem kolejnych niusów, które, jak słusznie kocio zauważył, nie powstają w 10 minut. Może przez 10 lat, do czasu 2.6.70, wyrobię się i sprawniej będzie mi to szło.
Zwracam też uwagę, że to nie jest artykuł! Treści jest tu raptem na 1,5 ekranu w układzie adz-dev przy rozdzielczości 1920×1200. Artykuł powinien zajmować kilka razy więcej (4,5-9 ekranów?). Gdy już powstaje (co dotychczas zdarzyło się tylko raz) i tak go tu nie umieszczam, a u siebie: http://wiki.przemoc.net/
Nie mam konta na naszej-klasie i jeżeli nie zmuszą mnie do tego jakieś bliżej nieokreślone czynniki zewnętrzne z pewnością nigdy mieć nie będę. Ciekawi mnie jednak czym jest eurogąbka donacji. Pytam, bo to może wiąże się z aktem jakiegoś zbiorowego oplucia czy wysyłania inwektyw w kierunku znienawidzonego przez określone środowiska (grupy/cokolwiek tam jest) interlokutora.
Rozumiem, że dla kart NVIDII musimy poczekać na "firmowe" wsparcie KMS-a?
IIRC nVidia odgraża się, że są gotowi z własnym KMS. Ale pamiętam jak przez mgłę (musiałbyś poszukać na phoronix.com).
Nouveau nad KMS właśnie pracuje.
No, to sie nazywa nius! Kupa czytania ;]
dlaczego wszystkie newsy tak nie wyglądają?
Może dlatego, że nikomu oprócz Przemka nie chce się ruszyć dupy i poświęcić nieco więcej czasu na napisanie czegoś porządnego?
Bo to bardzo dużo pracy. Przemoc bardzo solidnie się do niej przyłożył, za co został powszechnie doceniony (ja też się przyłączam), ale nie można oczekiwać, że wszystkie niusy będą aż takie. Można za to oczekiwać, żeby autorzy nie schodzili poniżej pewnego minimum, a czasem się cieszyć gdy ktoś wyskoczy wysoko ponad przeciętność.
A zrozumiałeś tak naprawdę chociaż część tego newsa?
Fantastyczny artykuł. Chylę czoła – czytało się jak masełko.
ale po co martwe linki do zasobow, ktorych jeszcze nie ma?
A ja się przyczepię
: w Polsce święto pracy obchodzimy 1 maja, natomiast treść artykułu odnosi się do święta amerykańskiego (pierwszy poniedziałek września).
A mi tam rybka czy to jajko 2.6.18 czy 2.6.31 jak wszystko działa na własnym sprzęcie i jest stabilne to poco zmieniać? Zabawny jest ten szpan niektórych osób ktore gonią za nowym jajkiem, jak by to była jakaś moda na to( Ej ja mam w Ubuntu 2.6.28 hehe a ja w najnowszej fedorze 2.6.31 i co
)
Zabawnie jest mieć stare jajko z lukami bezpieczeństwa?
Sam jestes luka bezpieczenstwa, redhat do dzisiaj backportuje latki do 2.6.18 i rhel kernel to wlasnie 2.6.18. Mozna? Mozna!
Czy ja napisałem "Zabawnie jest mieć stare, załatane jajko?"? Doskonale zdaje sobie sprawę że przygotowywane są łatki do starszych wydań Linuksa. Tyle, że tę łatę trzeba wpierw zainstalować, ale "jak wszystko działa na własnym sprzęcie i jest stabilne to poco zmieniać?":)
Dla odczucia wyższej (najczęściej placebo) prędkości ;]
W etchu też jest jeszcze wspierane 2.6.18.
Pewnie że można nie zmieniać, ale poprawa m.in. wsparcia sprzętu jaką można zauważyć w przeciągu 2-3 wydań jądra jest naprawdę spora – przynajmniej ja ją widzę. Oczywiście nie mówię tutaj o serwerach, gdzie wszelkie zmiany trzeba przeprowadzać bardzo ostrożnie, nie goniąc za nowinkami technicznymi.
Również chylę czoła – naprawdę dobry news.
O raju, super news. Nie interesuję się jądrem, a przeczytałem całość.
Za niusa plusa. A pytanie do znawców tematu: kiedy doczekamy się normalnej obsługi hibernacji/uśpienia? Na razie są pierdyliardy różnych rozwiązań, z czego rzadko komu one działają. Czy zostanie to w końcu rozwiązanie na poziomie jądra? Laikiem jestem, może ktoś pojętny, w temacie, wyjaśni dlaczego nie działa? Wiem, ze u niektórych tak, ale nie u większości.
Jak masz nvidie to najczęściej ich zamknięty sterownik nie wstaje z hibernacji, również jak masz swapu mniej niż pamięci ram to ci nie wstanie z hibernacji, gdyż hibernacja polega na zrzuceniu pamięci RAM na dysk, a w linuksie zrzuca do SWAPU. Ja tylko podejrzewam, że miałeś na myśli wstrzymanie/suspend, bo korzystania z hibernacji nie widzę sensu, przy dzisiejszych ilościach pamięci trwa to zbyt długo po prostu.
Mam Ati, x200, jadę na sterownikach xorga, nie fglrx. Swapa mam ciut większego (RAMu 854MB, zaś Swap 900MB)
Wróżką nie jestem dużo też zależy od płyty głównej, na mojej k9nu-neo nigdy wstrzymanie nie działało nawet w windowsie, a z hibernacji nie wychodzi mi system właśnie przez moduł nvidii. Ogólnie odczuwam, że na stacjonarnych maszynach jest gorzej ze wstrzymaniem niż na mobilnych.
To nie zrozumieliśmy się, a może źle, że nie napisałem, iż chodzi o laptopy. Mam Asusa F5R, na Windowsie działa bez niczego, raz kiedyś zaskoczyło na którejś wersji Susła, Ubuntu, bodajże 7.10 i nawet, olaboga, PLD, ale to za czasów kernela ok. 26.8-18, nie pomnę dokładnie teraz. Od tamtej pory już na żadnym distro nie działa, a wiele testowałem, oprócz wymienionych to Arch, Fedora, Sabayon, Pardus, PCLinuxOS.
Podobne doświadczenia mam. Od 5 lat nie zdarzyło mi się trafić na distro, na którym hibernacja działała by PRAWIDŁOWO, niestety. Wydaje się, że to jedna z tych rzeczy w linuksie, której dobrej obsługi szybko się nie doczekamy. Dla kontrastu na windowsie nigdy mi się nie zdarzyło żeby system nie wstał z uśpienia.
@qwak z uśpienia czy z hibernacji, bo różnica jest i to bardzo duża. W hibernacji cały komputer jest wyłączony, a zawartośc ramu ląduje na dysku, przy wychodzeniu z hibernacji następuje sytuacja odwrotna. W uśpieniu procesor i pamięć ram dalej są włączone i nie można odłączyć zasilania, bo się utraci ten stan.
Oczywiście hibernację miałem na myśli chociaż usypianie również pozostawia sporo do życzenia
@Paweł : Gdzieś nawet na OSNEWS był artykuł, że przechodzą na nowy kod – ponoć Linux wykorzystuje dane ze specjalnego deskryptora(jeśli można to tak ująć) przygotowanego dla Windows. Wystarczy w pliku konfiguracyjnym bootloadera podać jakiś specyficzny parametr jądra, by wszystko było po staremu.
Jednak w kwestiach niskopoziomowych jestem słaby. Nie jestem ani znawcą sprzętu, ani obsługi zdarzeń sprzętowych, itd. Na tak skomplikowanej sprawie, jak hibernacja się już kompletnie nie znam i nie śledzę, kiedy następują określone zmiany w takowych podsystemach jądra.
Oby tylko było to uniwersalne, nie uzależnione od distra oraz normalnie opisane, żeby było wiadomo co, gdzie i jak ustawić. Dzięki za info, poszukam.
Uśpienie chyba zawsze działało w przestrzeni jądra. Suspend2 działa natomiast na pewno w przestrzeni użytkownika. Tak poza tym, to wraz z KMS-em powinno się nieco, a nawet może sporo w tej materii poprawić.
U mnie działała normalnie, ale ostatnio się coś zkaszaniło (chyba przez stery nvidii) i wiesza się przy wybudzaniu. Klikam sobie w menu kde odpowiednią ikonkę i hibernuje lub usypia. Jest to chyba standardowe swsusp z kernela i pmutils w userspace, nie wiem po co szukać czegoś innego.
Mam dwa laptopy w tej chwili. W starszym, Aristo Prestige 1600, hibernacja i usypianie działają po odpowiednim tuningu a i to czasami są jakieś problemy (a to Xy nie wstaną, myszka nie działa etc.). W nowszym – Dell Precision M4300 – hibernacja i usypianie działają bez problemu out of the box na Kubuntu 9.04. Wszystko więc zależy od sprzętu.
Chcecie powiedzieć, że <code>iptables -A INPUT -s (XP|Vista|7) –protocol tcp -destination-port 80 -j DROP</code> i na mój portal nie wejdzie już wiecej żaden niewierny??? Fajowo
Świetny news, oby więcej takich.
Do wstrzymywania komputera pod Linuksem dziś trzeba mieć trochę szczęścia. Nawet jak 10 razy komputer prawidłowo się wstrzyma i wstanie, to za tym 11 zaprotestuje. Powody są różne, czasami po stronie jądra, czasami po stronie X11.
Odnośnie tematu newsa szczególnie ucieszył mnie jeden fragment:
"Dzięki zastosowaniu różnych heurystyk (opisanych szerzej w commitach), wyrzucenie zamapowanych wykonywalnych stron pamięci (ang. mapped executable pages) z listy aktywnych stało się dużo trudniejsze."
Bardzo irytujące było gdy podczas kopiowania plików o rozmiarach zbliżonych lub większych od ilości RAM w komputerze komputer zawsze niedomagał, jakakolwiek operacja trwała stosunkowo długo. Już wcześniej podejrzewałem że mogło to być wywołane wyrzucaniem z pamięci RAM kodu programów (i bibliotek) tylko po to, aby zbuforować kopiowany plik, co jest i tak bezcelowe jeśli plik/pliki mają łącznie większy rozmiar niż ilość ramu w komputerze. Teraz gdy kod programów będzie twardo siedział w pamięci RAM, komputer powinien funkcjonować normalnie podczas kopiowania nawet dużych plików.
Właśnie skompilowałem jądro i przetestowałem reakcję systemu na kopiowanie plików, i jestem bardzo zadowolony. Responsywność systemu jest bardzo dobra w trakcie tej czynności, programy w ogóle się nie przycinają, reagują natychmiast nawet gdy były dłuższą chwilę nieużywane. Różnica w porównaniu do zachowania na poprzednich wersjach jądra, to jak dzień a noc.
Linux właśnie zyskał u mnie ogromnego plusa.
Zawsze bardzo sobie cenię komentarze, które starają się coś wnieść do tematu, dając opinie na jakiś temat, nowe punkty odniesienia, linki do dodatkowych zasobów czy informacje "z frontu", tak jak ma to miejsce w Twoim przypadku. Fajnie, że sam przetestowałeś i podzieliłeś się wynikami z nami, nawet jeżeli są to tylko słowne informacje. Wiadomo, że jądrowi hakerzy wolą "raw numbers", ale to osnews.pl, a nie oshack.pl.
Innym przykładem jest podwątek Axboe'a w temacie BFS vs. mainline scheduler benchmarks and measurements, a szczególnie ciekawy jest jego ostatni mail (887354), gdzie BFS wreszcie zostaje poddany danemu testowi, niemniej dla odpowiedniego kontekstu polecam prześledzić całość: http://thread.gmane.org/gmane.linux.kernel/886319…
Właśnie czytam dyskusję, te wyniki (887354) są lekko porażające.
Właśnie, wyniki w tym mailu Jensa były zbyt porażające, a zawinił, jak to często bywa, czynnik ludzki – wartość timeout przekazywana do <code>poll()</code> nie była ujemna, co dawałoby nieograniczone czasowo oczekiwanie, a wynosiła 0, dając praktycznie natychmiastowy powrót z wywołania.
Opóźnienia, przynajmniej mierzone tak jak to robił Axboe, nie są więc tym "właściwym" miernikiem, co w dalszej dyskusji Con, tym razem już w grzecznym mailu (887636) i z przeprosinami za IMO wyjątkowo chamski poprzedni (886414), przyznaje. Czyli wciąż nie mamy "surowych liczb" na wyższość BFS nad CFS przy domowych zastosowaniach, za to efekt uboczny polegający na drobnych poprawkach mainline'owego schedulera, w tym pod kątem zwykłych śmiertelników nie posiadających setek rdzeni, jest.
Zdziwiłem się, że po tym co Kolivas napisał w pierwszym mailu, nawet po późniejszych przeprosinach, Ingo mu podziękował (887728). Podziękował mu za podniesienie problemu opóźnień poprzez anons swojego patcha i wzbudzenie zainteresowania wśród desktopowych userów co przełożyło się na ich chęć do testów. Świadczy to o tym, że Molnarowi zależy na tym, by CFS był "sprawiedliwy" nie tylko dla serwerów, co się chwali.
EDIT: Powaliła mnie odpowiedź Jensa (887757) na mail Ingo (887722). Bloody brilliant!
Bardzo dobra rzecz. Niegdyś plik wykonywalny z ustawionym bitem lepkości nie mógł zostać zesłapowany. Poprawiało to czas uruchamiania nowych instancji aplikacji, gdy poprzednia się już zakończyła.
Miejmy nadzieję, że nie wpłynie to jedynie na prędkość odtwarzania filmów na słabszych maszynach.
Myślę jednak, że po odłączeniu twardego dysku wciąż może być problem z uruchomieniem programu(który już raz został uruchomiony). W końcu w pamięci rezydują tylko sekcje oznaczone, jako wykonywalne.
Jednak sztuczka z Xine i LiveCD powinna nadal działać(mój ulubiony numer z Kubuntu).
Już sie nie moge doczekać 2.6.32. Ustabilizowanie KMS, może merge Xenowego paravirtualized ops, stabilizacja btrfs, poprawki w FUSE, może merge compcache.
A news bardzo dobry, śledzę na bierząco changlogi, czytam LWN, kilka wiki i mailing list, używam kilku dziwnych branchy jądra i orientuje się w temacie. Ale czasu na napisanie takiego przystępnego artykułu bym nie miał. Czekamy na następne!
hmmm… tylko kiedy poprawią support dla niestandardowych urządzeń HID? w bugzilli wisi ładnie opisany request użytkownika klawiatury logitech z zestawu mx 3200, może w końcu coś z tego będzie do 2.6.40 :/
Powiedzcie proszę jeśli wiecie, gdyż jest to dla mnie ważne:
Czy OSF pozwoli na standaryzację pakietów wychodzących tak jak dzieje się to w PFie OpenBSD? (ku przypomnieniu pf openbsd pozwala na takie zmiany nagłówka pakietów wychodzących, aby wyglądały one jakby pochodziły z innego systemu, np. z Windows XP SP2)
Ja w CUSE widzę jeden duży plus – emulacja urządzeń wejścia(mysz/klawiatura/itd.) przez aplikację. Obecnie mamy evdev-a, ale chyba twórcy Xorg-a/jądra nie bardzo go lubią. Teraz wystarczy, że np. Vine-server utworzy sobie takie pseudourządzenie znakowe, by wykorzystać MPX do zdalnego dostępu na pulpicie(wraz ze wszystkimi teoretycznymi usprawnieniami tego systemu, np. prawami dostępu do konkretnych okien). Kiedy ktoś robiący nam dziwne rzeczy z pulpitem się rozłączy, to dodatkowy kursor po prostu zniknie.
Nie wspominając też o emulacji napędu dyskietek, by niektóre dystrybucje nie miały problemów przy starcie, gdy na laptopie nie zainstalujemy paczek dla laptopa
. Łupss… Napęd dyskietek, to chyba urządzenie blokowe.
Nie wiem jak jądra ale deweloperzy Xorg evdev lubią bardzo (zalecają przejście ze starych xf86-input-keyboard i xf86-input-mouse na evdev właśnie).
Wersja finalna już jest, więc lekko zaktualizowałem niusa – tak jakby ktoś przeoczył wczorajszą informację.
Szybkie pytanko – czy korzystając ze sterowników fglrx na tym jajku będzie dostępne kernel modesetting dla podanych wyżej kart ati bez żadnych większych zabaw? Czy może KMS będzie dostępny jedynie dla otwartych sterowników? Jak to jest?