|
Kernel Traffic Latest | Archives | People | Topics |
Wine Latest | Archives | People | Topics |
GNUe Latest | Archives | People | Topics |
| Czech |
| Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic |
Table Of Contents
| 1. | 2 cze 2002 - 12 cze 2002 | (25 posts) | Stan kbuild i CML2 |
| 2. | 3 cze 2002 - 8 cze 2002 | (59 posts) | Adeos, nowe nanojądro dla Linuksa |
| 3. | 3 cze 2002 - 10 cze 2002 | (32 posts) | Stan integracji kbuild 2.5 |
| 4. | 4 cze 2002 - 12 cze 2002 | (17 posts) | Wskazówki dla schedulera |
| 5. | 4 cze 2002 - 6 cze 2002 | (31 posts) | Konserwacja baterii laptopa |
| 6. | 6 cze 2002 | (6 posts) | Nadawanie numerów wersjom jądra |
| 7. | 7 cze 2002 - 8 cze 200 | (3 posts) | Nowa wersja EVMS |
Mailing List Stats For This Week
We looked at 1177 posts in 5497K.
There were 376 different contributors. 179 posted more than once. 163 posted last week too.
The top posters of the week were:
1. Stan kbuild i CML2
2 cze 2002 - 12 cze 2002 (25 posts) Archive Link: "Ogłoszenie: dostępna jest wersja 3.0 Kernel Build dla 2.5"
Topics: Kernel Build System
People: Keith Owens
Keith Owens ogłosił kbuild 3.0 dla niestabilnej serii jądra. Jedną ze zmian w tej wersji było usunięcie obsługi CML2. Hayden A. James spytał, dlaczego tak się stało. Ktoś podrzucił odnośnik do archiwum listy dyskusyjnej, a Keith wyjaśnił, że Eric S. Raymond " został wyrzucony z listy. CML2 i kbuild 2.5 są w pełni niezależne i posiadanie dwóch systemów w jednej łacie powodowało coraz większy bałagan. Reguły konfiguracji w kbuild 2.5 są jasne, a obsługę innych wariantów CML można dodać w każdej chwili."
2. Adeos, nowe nanojądro dla Linuksa
3 cze 2002 - 8 cze 2002 (59 posts) Archive Link: "[OGŁOSZENIE] Nanojądro Adeos dla Linuksa"
Topics: Microkernels
People: Karim Yaghmour, Alessandro Rubini, Erik Andersen
Karim Yaghmour ogłosił:
Opublikowaliśmy pierwszą implementację nanojądra Adeos. Niniejszy tekst zawiera pełny opis jego podstaw, implementacji, API i potencjalnych zastosowań. Obejrzyjcie także proszę informację prasową (http://www.freesoftware.fsf.org/adeos/pr-2002-06-03.en.txt) oraz strony projektu (http://freesoftware.fsf.org/projects/adeos/). Kod Adeos jest rozpowszechniany na zasadach GNU GPL.
Nanojądro Adeos oparte jest o badania i publikacje dotyczące nanojąder, pochodzące z wczesnych lat dziewięćdziesiątych. Naszą podstawową metodą było odwrócenie podejścia opisanego w większości prac na ten temat. Zamiast budować najpierw nanojądro, a potem systemy klienckie, zaczęliśmy od żywego i uznanego za funkcjonalny systemu operacyjnego, Linuksa, i umieściliśmy nanojądro pod nim. Zaczynając od Adeosa, inne klienckie systemy mogą być teraz używane obok jądra Linuksa.
W tym celu Adeos umożliwia równoczesne istnienie wielu domen na tym samym sprzęcie. Żadna z tych domen nie widzi pozostałych, ale wszystkie one widzą Adeosa. Domena najczęściej jest całym systemem operacyjnym, choć nie zrobiono żadnych założeń co do tego, jak bardzo wyszukaną rzeczą może być domena.
Aby różne systemy operacyjne mogły współdzielić między sobą sprzęt, w Adeosie zaimplementowano potoki przerwań (ipipe). Każda domena systemu operacyjnego ma swoją pozycję w potoku przerwań. Każde przerwanie, które przychodzi do potoku przerwań jest przesyłane do każdej domeny w tym potoku. Zamiast włączać/wyłączać przerwania, każda domena w potoku przerwań może się zawiesić/odwiesić. Jeśli potok jest w stanie zawieszonym, to przerwania nie przechodzą przez potok, zanim stan nie zmieni się na odwieszony. W każdym stanie, potok może oczywiście zdecydować się na wykonanie różnych rzeczy z przerwaniem. Może na przykład zdecydować, że właśnie jest ostatnim odbiorcą danego przerwania. W takim przypadku, ipipe nie propaguje przerwania do reszty domen w potoku.
Niezależnie od operacji, które są wykonywane w potoku, kod Adeosa __nie__ bawi się maskami przerwań. Jedyny przypadek, w którym wpływa się na maski sprzętowe, to działania podczas dodawania/usuwania domen z potoku. To oznacza także, że żaden system operacyjny nie może używać prawdziwego, sprzętowego cli/sti (czyli realnego włączania i wyłączania przerwań). To jednak jest w porządku, ponieważ wołania zawieś/odwieś dają tę samą funkcjonalność.
Nasze podejście opiera się o następujące prace (odnośniki do nich podaję na końcu tego listu):
Jeśli nie chce się Wam pobierać całych prac, tu macie streszczenie. Pierwsze dwie opisują nanojądro Space, trzecia opisuje nanojądro cache, a czwarta exokernel.
Dokładny opis podejścia zastosowanego w Adeosie został dokładnie udokumentowany w pracy opublikowanej ponad rok temu, zatytułowanej ,,Adaptive Domain Environment for Operating Systems'' i dostępnej tutaj: http://www.opersys.com/adeos. Nasza implementacja jest troszeczkę inna. Przede wszystkim nie implementujemy funkcjonalności przenoszącej Linuksa poza ring 0. Jest to interesujące, ale takie podejście nie jest zbyt przenośne.
Zamiast tego, nasza łatka wmontowuje się w główne źródło kontroli sprzętu, czyli w kod rozsyłający przerwania i wstawia tam potoki przerwań, które mogą służyć wszystkim klientom nanojądra, włączając w to Linuksa.
Samo takie podejście nie jest żadną nowością. Inne systemy operacyjne były modyfikowane w ten sposób w różnych celach. Jeden z najbardziej interesujących przykładów został opisany przez Stodolsky'ego, Chena, i Bershada w pracy pod tytułem ,,Fast Interrupt Priority Management in Operating System Kernels'' opublikowanej w 1993 roku jako część sympozjum Usenix na temat mikrojąder i innych architektur jąder. W tamtym przykładzie cli/sti zostało zastąpione przez wirtualne cli/sti, które w żaden sposób nie modyfikowało realnych masek przerwań. Zamiast tego, przerwania były odkładane i przekazywane do systemu operacyjnego przez wołania wirtualnego sti.
Wynikiem przyjęcia takiego rozwiązania jest głównie poprawa wydajności systemu operacyjnego. Chociaż nie zrobiliśmy żadnego pomiaru wydajności obsługi przerwań w Linuksie z Adeosem, nasze nanojądro zawiera z definicji kod implementujący technikę opisaną we wspomnianym wyżej artykule Stodolsky'ego, której to techniki używamy do przekierowania przepływu przerwań sprzętowych do potoków.
Jeśli chodzi o szczegóły implementacyjne, to kod Adeosa jest raczej
krótki, bo skupiliśmy się na ustanowieniu podstaw współdzielenia przerwań
między domenami. Oto pliki, które dodaliśmy:
kernel/adeos.c: Niezależny od architektury kod domen.
arch/i386/kernel/adeos.c: Zależny od architektury kod domen.
arch/i386/kernel/ipipe.c: Kod potoków przerwań.
include/asm-i386/adeos.h: Plik nagłówkowy Adeosa zależny od architektury.
include/linux/adeos.h: Główny (niezależny od architektury) plik nagłówkowy
Adeosa .
Jak widać, obecnie obsługiwana jest tylko architektura i386. Jednakże większość kodu zależnego od architektury jest łatwo przenaszalna do innych architektur.
Zmodyfikowaliśmy także niektóre pliki, by wkręcić się w wysyłanie przerwań w Linuksie (wszystkie te modyfikacje są zawarte pomiędzy #ifdef CONFIG_ADEOS/#endif):
kernel/ksyms.c
arch/i386/kernel/apic.c
arch/i386/kernel/entry.S
arch/i386/kernel/i386_ksyms.c
arch/i386/kernel/i8259.c
arch/i386/kernel/irq.c
arch/i386/kernel/smp.c
arch/i386/kernel/time.c
arch/i386/kernel/traps.c
arch/i386/mm/fault.c
include/asm-i386/keyboard.h
include/asm-i386/system.h
Zmodyfikowaliśmy jałowe zadanie tak, że przekazuje ono sterowanie
z powrotem Adeosowi tak, by potok przerwań mógł kontynuować propagację:
arch/i386/kernel/process.c
Zmodyfikowaliśmy init/main.c tak, by Adeos był inicjalizowany bardzo wcześnie przy starcie.
Dodaliśmy oczywiście odpowiednie modyfikacje plików makefile i opcji konfiguracyjnych tak, że można wybrać, czy chce się włączyć Adeosa w trakcie konfiguracji jądra.
Oto publiczne API Adeosa:
int adeos_register_domain(adomain_t *adp, adattr_t *attr);
Rejestruje nową domenę używając własności zdefiniowanych przez atrybut.void adeos_unregister_domain(adomain_t *adp);
Usuwa domenę ,,adp''.void adeos_renice_domain(adomain_t *adp, int newpri);
Zmienia priorytet ,,adp'' w potoku przerwań.void adeos_suspend_domain(void);
Dana domena skończyła zajmować się bieżącym przerwaniem. To sygnalizuje ipipe, że powinien przekazać przerwanie do następnego stanu potoku.void adeos_virtualize_irq(unsigned irq, void (*handler)(void), int (*acknowledge)(unsigned));
Dostarcza funkcji obsługującej i powiadamiającej o ,,irq''.void adeos_control_irq(unsigned irq, unsigned clrmask, unsigned setmask);
Zmienia maskę przerwania ,,irq'' dla obecnej domeny. Najpierw stosuje się ,,clrmask'', a potem ,,setmask''.void adeos_stall_ipipe(void);
Wprowadza bieżącą domenę w stan zawieszenia w potoku. Alternatywa dla cli.void adeos_unstall_ipipe(void);
Odwiesza bieżącą domenę w potoku. Alternatywa dla sti.void adeos_restore_ipipe(unsigned x);
Odtwarza potok przerwań z zapamiętanego stanu. Alternatywa dla __restore_flags() i local_irq_restore(). Używane jest z następującymi definicjami:
#define adeos_test_ipipe() test_bit(IPIPE_STALL_FLAG,&adp_current->status)
#define adeos_test_and_stall_ipipe() test_and_set_bit(IPIPE_STALL_FLAG,&adp_current->status)
co zastępuje odpowiednio __save_flags i local_irq_save().
W przypadku Linuksa adeos_register_domain() jest wołane bardzo wcześnie, na początku startu systemu. Wtedy modyfikowane jest set_intr_gate() w arch/i386/kernel/traps.c tak, by wołać adeos_virtualize_irq(), aby Linux powiedział potokowi przerwań, że potrzebuje przekazywać przerwania do set_intr_gate().
Żeby dodać własną domenę do potoku przerwań, należy:
Tak to się robi. Jeśli tylko podano Adeosowi odpowiednie funkcje obsługi w kroku drugim, to przerwania będą dostarczane przez potok przerwań.
W trakcie działania można zmienić pozycję w potoku przerwań używając adeos_renice_domain(). Można także zawiesić/odwiesić potok i zmienić obsługę przerwań w potoku zgodnie z potrzebami.
Obecnie nie obsługujemy SMP, ale mamy obsługę APIC na UP.
Oto kilka możliwych zastosowań Adeosa (lista nie jest pełna):
Jesteśmy oczywiście zainteresowani wszystkimi komentarzami i sugestiami na temat Adeosa.
----------------------------------------------------------------------
Odnośniki do prac:
Z dyskusji, która nastąpiła później, można wyróżnić dwa główne tematy. Erik Andersen zapytał o wydajność. Tradycyjnie, ponieważ mikrojądra zawierają formalną komunikację i przekazywanie komunikatów między górnymi i dolnymi warstwami systemów, zwykło się myśleć, że z tego powodu mikrojądra mają istotny narzut na wydajność, co jednak nie dotyczy monolitycznego jądra, takiego jak Linux. Ale Karim odpowiedział, że zgodnie z pewnymi wstępnymi testami, ich implementacja jest mniej niż 1% wolniejsza od standardowego jądra.
Erik zapytał także w swoim liście o wpływ istniejących patentów na oprogramowanie. Czy Adeos pogwałci czyjekolwiek prawo do własności intelektualnej? Na ten temat odbyła się dysputa. Alessandro Rubini sądził, że: "Według mnie wynika to jasno z patentu FMSLabs, jako, że system RT i nie-RT żyją jeden obok drugiego i są równorzędne." Karim zgodził się i dodał: "zbierz artykuły, kod i patent i sam się temu przyjrzyj, zobaczysz, że jesteśmy czyści. Oprócz tego, że mamy dwa równorzędne jądra obok siebie, Adeosa oparliśmy o klasyczne prace o nanojądrach pochodzące z wczesnych lat 90-tych. Nie ma w tym żadnych tajemnic. " Ale Erik nie dał się przekonać. Zapytał: "czy wkrótce zobaczymy przeniesienie RTAI na moduł jądra Linuksa, który jest zaimplementowany jako oddzielna domena Adeosa, pozwalająca aplikacjom RTAI nie złamać amerykańskiego patentu 5995745? Szybkie spojrzenie na ten patent nie upewnia mnie wcale, czy to naprawdę omija fundamentalny ,,wynalazek procesu dla uruchomienia komputerowego systemu operacyjnego ogólnego przeznaczenia, używając systemu operacyjnego czasu rzeczywistego''. To ciągle wygląda dla mnie tak, jakby system operacyjny czasu rzeczywistego (Adeos) uruchamiał zadania czasu rzeczywistego i zadania, które nie są zadaniami czasu rzeczywistego wraz z systemem operacyjnym ogólnego przeznaczenia jako jednego zadania, które nie jest zadaniem czasu rzeczywistego... Czy mógłbyś krótko napisać (dla ludzi jak ja nie będących prawnikami) jak to pozwala obejść postanowienia patentu? " Alessandro odparł:
Zacytuję dla ciebie treść patentu:
Proces [...] dostarczający systemu operacyjnego ogólnego przeznaczenia jako jedno z zadań nie będących zadaniem czasu rzeczywistego; wywłaszczenie systemu operacyjnego dla zadań czasu rzeczywistego; uniemożliwienie systemowi operacyjnemu ogólnego przeznaczenia blokowania wywłaszczania zadań nie będących zadaniami czasu rzeczywistego.
Nic takiego nie ma w adeosie. I nic takiego nie pojawi się w ,,zadeosowanym'' RTAI.
W pewnym momencie Daniel Phillips podał odnośnik do wszystkich postanowień patentu RTLinux.
3. Stan integracji kbuild 2.5
3 cze 2002 - 10 cze 2002 (32 posts) Archive Link: "Jeśli chcecie kbuild 2.5, powiedzcie Linusowi"
Topics: Kernel Build System, Development Philosophy
People: Keith Owens, Nicolas Pitre, Kai Germaschewski, Kai Henningsen, Daniel Phillips, Tomas Szepe, Bill Davidsen
Keith Owens, sfrustrowany tym, że jest ignorowany przez Linusa Torvaldsa, podesłał prośbę do ludzi, by podręczyli Linusa o włączenie kbuild do głównej odnogi źródeł jądra. Zwrócił uwagę: "Dzień, w którym w pełni przetestowany i udokumentowany system, który jest szybszy i, przede wszystkim, lepszy, poprawniejszy, nie może trafić do jądra jest smutny. Linus ocenia kbuild 2.5 po jego popularności i trzymając się kwestii personalnych, a nie ze względu na sprawy techniczne." Nicolas Pitre odpowiedział: "Linus zainteresował się kbuild-2.5, gdy ktoś inny, nie Ty, zdecydował się na dostarczanie mu małych łatek, czyli zrobił dokładnie to, co ja Ci mówiłem jakiś czas temu i co nazwałeś ,,głupim komentarzem''." Parę wiadomości później dodał: "Keith oczywiście wykonuje pierwszorzędną pracę, nie ma co do tego wątpliwości. Niestety, na tym przykładzie okazało się jak bardzo nie potrafi dogadać się z Linusem. "
W innym miejscu Daniel Phillips dał odnośnik do: listu od Linusa pochodzącego sprzed paru tygodni, w którym prosi on Kaia Germaschewskiego o zajęcie się integracją kbuild. Parę wiadomości dalej w obecnym wątku, także Kai dodał: "Właśnie to robię! Nie krzyczcie aż tak bardzo. " W jeszcze innym miejscu Kai Henningsen napisał:
Nie udało mi się zrozumieć jak to ma działać, i sądzę, że Keithowi też nie.
Kai (inny Kai!) nie chce chyba integrować głównej części kbuild2.5. Wydaje się, że chce tylko wybrać to, co najłatwiejsze, a wokół reszty tylko niewiarygodnie pokrzyczeć, pozostawiając ją bez obsługi.
Linus wydaje się zaś chcieć ignorować fakt, że główny fragment kbuild2.5 jest z natury czymś, co nie może być włączane ,,stopniowo'' - tak jak ALSA, albo nowa architektura, nie może być tak naprawdę wprowadzana ,,stopniowo''. (A powiedział *także*, że nie interesuje go pseudostopniowość, to znaczy dzielenie wszystkiego na części, ale ciągłe wykonywanie wielkiej podmiany.)
Szczerze, nie widzę *absolutnie żadnego sposobu* w jaki obecne ,,włączanie'' Kaia i Linusa może się skończyć czymś choć trochę podobnym do kbuild2.5 Keitha. No chyba, że Linus zmieni radykalnie swoje podejście do sprawy.
Jeśli byłbym Keithem, też bym był zdenerwowany.
Ale Kai G. odpowiedział: " W żadnym wypadku nie powinien być. Sporo ludzi docenia jego pracę, a wielu z nas jest mu bardzo wdzięcznych. Tak, jak ja. To będzie długa droga, ale w końcu kbuild-2.4 nie może zostać, podczas gdy kbuild-2.5 (na szczęście) idzie wciąż naprzód. Weźmiemy go kiedyś, w przyszłości. " Ale Daniel napisał: "Niewątpliwie minęło już wystarczająco dużo czasu na podjęcie jakiejś akcji, ale żadnej nie widzę. Powiedziałbym, Kai" [Germaschewski] "się zawiesza i w ogóle nie chce współpracować. "
Jesse Pollard podrzucił propozycję, jak efektywnie włączyć kbuild do jądra, a Tomas Szepe ponarzekał: "Zauważ proszę, że było już niepoliczalnie wiele propozycji, jak włączyć kbuild 2.5 i wszystkie one zostały po cichu odrzucone." Bill Davidsen zaś odpowiedział: "W moim odczuciu problem polega na tym, że propozycja została odrzucona, albo odłożona na później, a niektórzy ludzie tego nie akceptują. Ja też bardzo chciałbym zobaczyć najlepsze kawałki O1 i preempt w 2.4, ale nie zamierzam prosić nikogo żeby napisał do Linusa, Marcelo lub Sen. Hollingsa żeby powiedział im, że mój pomysł jest dobry. Tak długo, jak tylko dostępne są łatki i mogę sobie je sam nałożyć, pomarudzę sobie pod nosem i będę dalej robił swoje. Głosuję za takim rozwiązaniem problemu włączenia kb25, to znaczy za tym, by zaakceptować fakt, że decyzja została podjęta i robić swoje."
4. Wskazówki dla schedulera
4 cze 2002 - 12 cze 2002 (17 posts) Archive Link: "[ŁATKA] wskazówki dla schedulera"
Topics: Scheduler
People: Robert Love, Rick Bressler, Simon Trimmer
Robert Love zaimplementował ,,wskazówki'' dla schedulera O(1). Wyjaśnił: "wskazówki schedulera są pewnym sposobem na to, by program mógł dawać ,,wskazówki'' schedulerowi na temat jego obecnego zachowania w nadziei, że scheduler równolegle podejmie lepsze decyzje co do przydziału czasu procesora." Podał przykład: "Rozważmy grupę wątków SCHED_RR, które dzielą między sobą semafor. Zanim jeden z wątków postanowi zgłosić się po semafor, może ,,wskazać'' schedulerowi, aby ten zwiększył pozostały przysługujący mu czas, by zapewnić, że uda mu się zakończyć pracę i zwolnić semafor zanim zostanie wywłaszczony. Robi się to po to, że gdyby taki wątek został wywłaszczony, to zostałby ponownie zaszeregowany, a inne wątki czasu rzeczywistego w końcu zablokowałyby się na zajętym semaforze." Rick Bressler odpowiedział:
Sequent miał interesującą wskazówkę, którą wyprodukowali z Oraclem (albo może to było odwrotnie). Jeśli dobrze pamiętam, to nazwali ją ,,twotask''. Procesy klientów Oracle spędzają sporo czasu na wymianie informacji z procesami serwera. Przywiązanie ich do tego samego procesora na maszynie SMP (a szczególnie na NUMA) ma zwykle sens. (Prawdopodobnie jest to oczywiste dla większości ludzi z tej grupy, ale generalnie lepiej jest komunikować się przez pamięć lokalną i cache niż przez magistralę NUMA.)
Z tego co pamiętam, zmieniło to istotnie wydajność Oracle i prawdopodobnie odniosłoby to podobny skutek dla wydajności w wielu sytuacjach, w których proces klienta i serwera wykonują dużo interakcji w środowisku SMP.
Ale Robert napisał, że to nie jest konieczne, bo w Linuksie 2.5 już zaimplementowano polecenie przywiązujące proces do konkretnego procesora.
W innym miejscu Simon Trimmer wspomniał:
To nie moja sprawa, ale mój współlokator zostawił na stole kopię solaris internals ;)
Wspomniano o tym około strony 384, wydaje się, że celem są tu procesy z przestrzeni użytkownika dokładnie w przypadkach, które sugerujesz (wstrzymywanie globalnych zasobów).
Dobrą pozycją na temat, w dokumentacji suna dostępnej w sieci, jest schedctl_init() - http://docs.sun.com/db?q=schedctl_init&p=/doc/816-0216/6m6ngupm0&a=view
Robert napisał, że myślał, że zawarto to w Solaris Internals, ale nie miał przy sobie własnej kopii, by potwierdzić swoje podejrzenia. Odnośnie dokumentacji online napisał zaś:
Hm, to co oni eksportują jest trochę inne. Zastanawiam się jak wygląda wewnętrzny interfejs jądra (tzn. jak podobny jest do sched_hint)?
Ponieważ oni mają start_hint i stop_hint, to właśnie tam mogą wymusić pewną uczciwość. Gdy wołasz stop, podejrzewam, że odejmują oni od Twojego czasu pewną wielkość podobną do czasu, który mija między start i stop. Jeśli nie zawołasz stop zanim nie zostaniesz przeszeregowany, to prawdopodobnie tracisz po prostu spory kawałek swojego kawałka czasu.
To powinno być możliwe do zrobienia z naszym schedulerem - prawdopodobnie przy minimalnych zmianach (co jest moim celem). Jednakże, ponieważ napisałem to bardziej jako ćwiczenie dla zabawy niż coś do włączenia, to nie wiem, czy warto budować wokół tego całą infrastrukturę. Ci którzy naprawdę widzą korzyści z tego wynikające (obliczenia naukowe, zastosowania czasu rzeczywistego czy cokolwiek) mogą sobie wziąć tę łatkę, wyrzucić z niej sprawdzanie uprawnień i napisać swoje aplikacje tak, by do tego pasowały -- oni wierzą podstawom własnych aplikacji.
Aby jakoś wzbudzić zainteresowanie, prezentuję trochę wyników testów porównawczych. Mam 5 wątków (pthreads) bijących się o pojedynczy semafor. Działają one w pętli, najpierw są bardzo zajęte, potem opuszczają semafor, znowu są zajęte w pętli, a potem podnoszą semafor. W ten sposób zużywają sporo przydzielanych im kawałków czasu, a resztę czasu spędzają blokując się na semaforze. Pozwalam im wykonywać ustaloną liczbę obrotów pętli zanim się zakończą.
(To średnio ~10 uruchomień)
Przy wołaniu sched_hint(HINT_TIME) po udanym opuszczeniu semafora średni czas działania wynosi 7233459 us. Bez sched_hint, średni czas działania to 7683220 us.
To daje poprawę około 6% - przy jedynie 5 wątkach.
Pobieżne przyjrzenie się, pokazuje redukcję w przełączaniu kontekstów, ale to, co się naprawdę liczy to to, że jeśli wchodzimy do schedulera i nigdy nie (a) szeregujemy dwa razy tego samego zadania, ani nie (b) uruchamiamy innego wątku, który szybko zablokuje semafor.
To wszystko jest w pewien sposób akademicką dyskusją...
5. Konserwacja baterii laptopa
4 cze 2002 - 6 cze 2002 (31 posts) Archive Link: "[rfc] "tryb laptopowy""
Topics: Laptop Support
People: Andrew Morton, Andreas Dilger
Andrew Morton ogłosił:
Załączam łatkę, która sprawia, że jądro lepiej obchodzi się z przenośnymi komputerami. Używam jej już od kilku dni i wydaje się pracować prawidłowo. Zastanawiam się, czy ktoś ma jakieś komentarze/sugestie/itp.
Aby przetestować kod będziecie potrzebować http://www.zip.com.au/~akpm/linux/patches/2.4.20/pdflush-sysctl.patch (hmm. Chyba umarł serwer. Więc wrzucam łatki do załącznika)
Oto algorytm z sekcji Documentation/filesystems/proc.txt opisującej /proc/sys/vm/:
laptop_mode
-----------
Ustawienie tej opcji na '1' przestawi algorytmy jądra zapisujące brudne dane do trybu, który jest lepiej dopasowany do laptopów/notebooków. Ten tryb jest zaprojektowany tak, aby zminimalizować obroty dysku. Tryb laptopa działa następująco:
- Brudne dane pozostają w pamięci przez dłuższy okres czasu (ograniczany przez laptop_writeback_centisecs).
- Jeśli są jakieś oczekujące brudne dane, a dysk się z jakiegoś powodu kręci (nawet dla odczytu), wszystkie brudne dane zostaną zapisane w krótkim czasie. tzn: jeśli dysk się kręci, wykorzystajmy to.
- Gdy zostaje podjęta decyzja o zapisaniu jakichkolwiek brudnych danych, jądro zapisuje wszystkie brudne dane.
laptop_writeback_centisecs
--------------------------
Ten parametr określa maksymalny wiek brudnych danych, gdy komputer znajduje się w trybie Laptop. Domyślna wartość to 30000 -- pięć minut. To oznacza, że jeśli aplikacje nie produkują zbyt dużo danych do zapisania, dysk będzie się kręcił raz na pięć minut.
Jeśli dysk kręci się z jakiegoś innego powodu (takiego, jak odczyt), wszystkie brudne dane zostaną wtedy zapisane, a licznik zostanie ustawiony na zero.
laptop_writeback_centisecs nie wpływa na zachowanie systemu, gdy komputer nie działa w trybie Laptop.
Ta implementacja nie próbuje być zbyt mądra -- jest bezpośrednie odwołanie z do_ide_request() do kodu zapisującego dane. To nie mogło być zrobione z ll_rw_blk.c, bo w takim wypadku zapis do ramdysku budziłby dysk. W postaci takiej, jak jest, odczyt z CD-ROM-u IDE będzie powodował obudzenie dysku i zapisanie na nim danych, więc to wywołanie w do_ide_request() powinno być wykonywane jedynie, jeśli urządzenie jest zapisywalne. Sugestie są mile widziane, ale nie przesadzajcie z udziwnieniami w tym miejscu...
Pomysł spotkał się z ciepłym przyjęciem i było trochę technicznej dyskucji. Andreas Dilger odniósł się do pięciominutowych okresów pomiędzy budzeniem twardego dysku. Powiedział: "FYI, to jest raczej bardzo zły wybór domyślnej częstotliwości budzenia dysku, ponieważ wiele laptopów usypia dyski w tym samym momencie. Powiedziałbym, że optymalne będzie 15-20 minut, a nawet więcej, o ile nie ma dużej presji ze strony VM czy czegoś takiego. W innym przypadku szybko zarżniesz twardy dysk w laptopie ze względu na zbyt częste cykle usypiania/budzenia." Andrew odpowiedział:
Ustawiłem na dwadzieścia. Dzięki.
BTW, pomysł ,,użycia gigabajta do odczytu z wyprzedzeniem'' spowoduje wariactwo w VM, jeśli będziesz probował odczytać 600 megabajtowy plik, więc będę się trzymał dwudziestu mega.
Ktoś inny zasugerował, aby uczynić tę cechę pełniejszą i obsługiwać stacje robocze z jednym uśpionym dyskiem itp. Do wykonania tego nie jest potrzebna nauka o budowie rakiet -- `struct backing_dev_info' oferuje specyficzny kanał komunikacyjny pomiędzy wysokopoziomowym kodem VFS i kolejką żądań. Ale wymagałoby to większej operacji na kodzie zapisującym dane, więc poluję na wymagania w tym względzie. Jeśli obecna (prosta) łatka jest wystarczająca, to cóż, jest wystarczająca.
Były różne życzenia na temat funkcjonalności i trochę dyskusji na temat implementacji.
6. Nadawanie numerów wersjom jądra
6 cze 2002 (6 posts) Archive Link: "Pytanie dotyczące specyfikacji "EXTRAVERSION""
Topics: Source Tree, Kernel Build System
People: John L. Males, Keith Owens, Alan Cox
John L. Males spytał:
Ostatnio musiałem użyć ,,EXTRAVERSION'' w serii jąder Linuksa 2.2.x. Moje pytania dotyczą jąder Linuksa zarówno z serii 2.2.x, jak i -- 2.4.x.
Pytania są następujące:
Na pytanie 1 odpowiedział Keith Owens: "Łączna długość $(VERSION).$(PATCHLEVEL).$(SUBLEVEL)$(EXTRAVERSION) nie może przekraczać 64 znaków. Gdy to przekroczysz, uname -r pokaże śmieci." Odnośnie drugiego pytania powiedział: "kbuild 2.5 wymusza to ograniczenie, natomiast system budowania z obecnych jąder -- nie. W czasach 2.4.15 wysyłałem Linusowi łatkę 4 razy, ale ją całkowicie zignorował. Linus nie dba o problemy z budowaniem jądra." Dodał, że wykopie tę łatkę i wyśle ją Marcelo do włączenia do 2.4. Alan Cox poprosił: "Proszę, wyślij do mnie kopię, abym mógł włączyć ją do -ac, na wypadek gdyby Marcelo ją zgubił lub nie chciał jeszcze przed 2.4.19." John spytał, czy jest jakakolwiek szansa na włączenie tej łatki do 2.2, ale nie doczekał się odpowiedzi.
7. Nowa wersja EVMS
7 cze 2002 - 8 cze 200 (3 posts) Archive Link: "[ANNOUNCE] EVMS wersja 1.1.0-pre1"
Topics: Disk Arrays
People: Kevin Corry, Svetoslav Slavtchev
Kevin Corry ogłosił:
Zespół EVMS ma przyjemność ogłosić ukazanie się następnej wersji rozwojowej Enterprise Volume Management System, która przypuszczalnie wkrótce stanie się EVMS 2.0. Pakiet 1.1.0-pre1 jest dostępny do pobrania ze stron projektu: http://www.sf.net/projects/evms
Ponieważ to jest tylko wersja pre, dostępna jest tylko paczka ze źródłami. RPM-y będą dostępne, gdy ukaże się wersja 1.1.0.
Z tego też powodu używajcie tej wersji ostrożnie. Jest kilka nowych rzeczy w funkcjonalności, które jeszcze nie przeszły dokładnych testów! Innymi słowy, nie będziecie chcieli używać tej wersji na krytycznych systemach.
Wszelkie problemy i błędy zgłaszajcie na listę dyskusyjną EVMS: evms-devel@lists.sf.net.
Najciekawsze cechy wersji 1.1.0-pre1 obejmują:
v1.1.0-pre1 - 6/7/02
Svetoslav Slavtchev spytał: "czy istnieje jakaś możliwość, aby używać tego z jądrem 2.5? Ostatni cvs jest zsynchronizowany z 2.5.11, a ostatnie 2.5 to 2.5.20 [2.5.20-dj3]" Ktoś odpowiedział mu prywatnie, że EVMS będzie zsynchronizowany z ostatnim jądrem 2.5 w ciągu mniej więcej tygodnia, a Svetoslav podziękował mu za informację.
Sharon And Joy
Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0. |