Kernel Traffic #163 For 2002/04/22

Nie używaj, proszę, łat bk; okazały się one zupełnie nieużyteczne.

Albo stwórz (kontrolowane) drzewo bk, z którego daje się wyciągać zmiany, albo użyj starych łat.

BK nie pozwoli Ci zaakcpeptować łaty jeśli otrzymujące repozytorium nie jest przodkiem łaty. Innymi słowy -- to nie zadziała.

bk clone bk://linux.bkbits.net/linux-2.5
<jakieś tam zmiany>
bk commit (lub bk citool) # tworzy changeset 1.800
<jakieś tam zmiany>
bk commit (lub bk citool) # tworzy changeset 1.801
 
# Teraz, jeśli chcesz wysłać drugą łatę Linusowi wykonujesz:
bk send -r+ - | mail linux-kernel@vger.kernel.org

Próby Linusa zaakceptowania łaty zakończą się niepowodzeniem, bo nie ma Twojego 1.800.

Bieżący kod wywłaszczający jądro otwiera małe okno pomiędzy sprawdzeniem need_resched w schedule, a ustawieniem preempt_count na zero w preempt_schedule. Ponieważ to okno jest dość krótkie (kilka cykli), to wynikowy okres niewywłaszczalności może trwać aż do następnego tyknięcia zegara, ale tak naprawdę, to znacznie dłużej jeśli w międzyczasie założona zostanie blokada.

Ta łata sprawdza need_resched w preempt_schedule po ustawieniu preempt_count na zero, przed powrotem. Narzut jest zaniedbywalny, a jest arcyważny, aby nie stracić żadnej szansy na wywłaszczenie.

Z dwóch powodów:

1. W 2.5 mamy model wywłaszczania jądra, który czyni je w pełni wywłaszczalnym, z zachowaniem blokad SMP i jeszcze kilku innych reguł. Bez tej łaty ten model nie jest zachowany i nie pozwala na wywłaszczenie, gdy tak naprawdę jest ono pełnoprawne.
2. Jak już powiedziałem, może upłynąć chwila, zanim będziemy mogli ponownie wywłaszczyć. Jeśli założymy blokadę po powrocie ze schedule, a przez następnym przerwanie, mogą upłynąć dziesiątki (lub setki) milisekund zanim podniesiemy blokadę i będziemy mogli dokonać wywłaszczenia. Jeśli need_resched było ustawione w odpowiedzi na żądanie ważnej aplikacji czasu rzeczywistego, oczekiwanie może być szkodliwe. W każdym razie, obsługiwanie aplikacji, tak szybko, jak tylko mogą działać, jest celem wywłaszczalnego jądra.

Nie to arcyważne w sensie, że coś psujemy; raczej w sensie, że skoro pracujemy nad udostępnieniem bardzo efektywnego mechanizmu odpowiedzi i przetworzenia żądań dla aplikacji interaktywnych i działających w czasie rzeczywistym, więc _musimy_ odpowiadać im tak szybko, jak to możliwe.

Jestem członkiem małego zespołu, który próbuje przenieść Linuksa na procesor TriCore Infineona. Jedyną wersją gcc dostępną dla wzmiankowanego procesora jest 2.8.1. Z drugiej strony ten procesor nie zawiera MMU, więc używamy łaty uClinux dla jąder 2.4.x.

Zastanawiam się, czy używając gcc 2.8.1 będziemy w stanie uzyskać działające jądro 2.4.x. Zgodnie z /Documentation/Changes wymagane jest gcc 2.95.3...

Pomiędzy wersjami gcc 2.8.1 i 2.95.3 zostało dodanych kilka flag i opcji, ale czy są one wymagane dla WSZYSTKICH procesorów???

W żaden sposób nie jestem związany z pisaniem tego sterownika. To duża firma :) Jestem nim zainteresowany, bo mam starą kartę ServeRAID w domu.

Wiem, że żaden z oryginalnych autorów nie pracuje nad poprawieniem tego.

Czy łata może zostać zaakceptowana jako tymczasowa pomoc, zanim dotychczasowi opiekunowie nie zdecydują się zaopiekować sterownikiem dla 2.5, czy też raczej chcemy zmusić autorów do przepisania sterowników, które nie używają nowego schematu DMA?

Mówiąc szczerze, to po kilku miesiącach, gdy sterownik był zepsuty i nikt nie spróbował go naprawić, to zdecydowanie będę chciał akceptować tymczasowe rozwiązania dla sterowników SCSI, nawet jeśli będą działać tylko na x86.

,,Nieakceptowalne'' oznacza, że zepsuty sterownik implikuje fakt, że ludzie nie mogą testować rzeczy, na których im zależy. Najwyraźniej nikomu nie zależy na sterowniku SCSI jako takim...

Ta łata próbuje podzielić arch/i386 na katalogi specyficzne dla różnych komputerów (podobnie, jak to jest w arch/arm). Pomysł polega na oddzieleniu tych komputerów, które nie wyglądają jak zwykłe PC-ty (zwłaszcza z punktu widzenia SMP). W tej chwili wszystko co jest zrobione, to przenieśienie rzeczy związanych z visws do oddzielnego katalogu (arch/i386/visws). Wziąłem także kilka plików, które nie będą używane przez komputery SMP nie-PC (głównie związane z mpbios i ioapic) i umieściłem je w arch/i386/generic.

Łata posuwa się zacznie dalej niż visws potrzebuje, głównie ponieważ pozwala mi teraz na dodanie moich rzeczy związanych z voyagerem do oddzielnego katalogu arch/i386/voyager, który nie zakłóca wirtualnie głównego kodu. Obawiam się, że zostały jeszcze cztery definicje związane z VISWS w arch/i386/kernel/smpboot.c, ponieważ nie było dla mnie oczywiste jak w prosty sposób się ich pozbyć.

269k diff (tak duży ze względu na wiele przesunięć plików) jest pod

http://www.hansenpartnership.com/voyager/files/arch-split-2.5.8.diff

Udostępniłem także repozytorium bitkeepera z tą łatą:

http://linux-voyager.bkbits.net/arch-split-2.5

Nie zrobiłem nic związanego z drugą częścią reformowania i386/arch, która miałaby dzielić katalog PC wedle typów szyn, ale sądzę. że Patrick Mochel myśli nad tym.

Kilka komentarzy.

• Nie ma możliwości zbudowania ogólnego jądra, które potrzebuje linii komend do wyboru architektury. Czegoś, co jest ważne dla instalatora. Lepsze byłoby automatyczne wykrywanie platformy na podstawie informacji z firmware, ale nie zawsze możesz to zrobić.
• Pozwalając na przekierowanie setup_memory_region nie dajesz szans architekturom, które nie mają 384K dziury w pamięci.
• Funkcje, które udostępniasz nie są nigdzie użyte, a są tak ogólne, że nie jest oczywiste, patrząc po ich nazwach, co mają robić.
• setup_arch.h jest paskudne. To, jaki kod to ma, zależy od tego, co jest zdefiniowane w chwili jego włączania. Nie możesz zamiast tego użyć 2 nagłówków? Albo nawet lepiej - użyć funkcji systemowych?

I oczywiście nie patrzysz na umożliwienie różnych implementacji firmware, ale ja to robię, więc jest w porządku. :)

Niekoniecznie typy szyn, ale blisko.

Mam trzy zbiory porządkowania katalogu arch/i386/kernel/:

• x86 CPU
• mtrr
• PCI

Każdy z nich robi to samo w tych sterownikach: przenosi obsługę do podkatalogów i dzieli monolityczne pliki na moduły zależne od platformy.

Takie rozwiązanie ma kilka zalet:

• Jedynie kod dla Twojej platformy będzie kompilowany
• Kod wynikowy ma mniej konstrukcji warunkowej kompilacji
• Kod wynikowy jest bardziej elastyczny i modularny
• Mniej konfliktujących ze sobą zmian zgłaszanych przez różne osoby
• Łatwiej stwierdzić, o co do licha tam chodzi

Główną motywacją do tego był sterownik PCI, zwłaszcza z wieloma konfliktującymi zmianami, które sam widziałem i różnymi zmianami ACPI i NUMA. Chciałem coś takiego zrobić już od jakiegoś roku. Mniej więcej miesiąc temu, w końcu siadłem i zrobiłem.

Łaty są dostępne pod

http://kernel.org/pub/linux/kernel/people/mochel/patches/

Niestety, opieka nad tak znacznymi zmianami bardzo pożera czas i stoi w sprzeczności z innymi celami i ograniczeniami czasowymi. Tym, na czym mi naprawdę zależy do sterownik PCI. Miałem szansę przenieść go do 2.5.8 i to powinno działać w większości przypadków (chociaż testowałem to jedynie na jedno i dwuprocesorowych komputerach x86 bez obsługi ACPI).

Całe to porządkowanie procesorów jest do ~2.5.6 i najprawdopodobniej nie zaaplikuje się do obecnego drzewa. Jeśli ktoś chciałby przenieść te łaty, to konflikty są raczej oczywiste i łatwo naprawialne.

To samo tyczy się sterownika mtrr, chociaż jest dość zapuszczony (~1 miesiąc) i zapewne będzie generował więcej konfliktów.

Jeśli ktoś będzie poważnie zainteresowany, przeniosę to do ostatniego jądra i wyeksportuję drzewa BK.

W 2.5 jest funkcja systemowa sched_setaffinity. Jest dość nowa, więc Twoje biblioteki jeszcze jej nie obsługują - popatrz na przykładowy kod i pliki nagłówkowe pod:

ftp://ftp.kernel.org/pub/linux/kernel/people/rml/cpu-affinity

W 2.4 nie ma jeszcze takiego interfejsu. Pod powyższym adresem możesz znaleźć interfejs do ustawiania i pobierania afiniczności oparty zarówno o proc, jak i o funkcję systemową.