Kernel Traffic #153 For 11 Feb 2002

W naszym serwisie trzymamy dane wszystkich użytkowników (~4000 użytkowników) centralnie na kilku serwerach NFS (na których na razie działają solarisy). Aby łatwiej tym administrować, zdecydowaliśmy się montować bezpośrednio każdy katalog użytkownika (przez automount skonfigurowany przez NIS) na kliencie NFS, gdzie użytkownik chce mieć dostęp do swoich danych. W tym wszystkim najważniejsze jest to, że każdy katalog użytkownika jest zawsze dostępny pod ścieżką /home/<user>. To podejście już udowodniło, że jest bardzo użyteczne (z punktu widzenia administratora), na przykład przy przenoszeniu użytkowników z jednego serwera na inny, przy instalowaniu dodatkowych serwerów NFS itp., ponieważ jedyną ścieżką, którą zna i widzi użytkownik, gdy wykonuje np. pwd, jest /home/<user>. Drugą zaletą jest to, że nie ma potrzeby modyfikacji konfiguracji klienta: aby zamontować katalog eksportowany przez serwer, nie trzeba nic zapisywać do /etc/fstab, więc nie ma niepotrzebnych zależności klientów od serwerów NFS.

Pomyśl teraz o konfiguracji, gdzie nie są zdefiniowane montowania katalogów użytkowników, ale całego katalogu NFS, gdzie jest wielu użytkowników. To oczywiście upraszcza sprawę dla systemu NFS, pownieważ wymagane jest jedynie jedno montowanie, ale ze strony klienta musisz stworzyć całe drzewa odnośników czy czegoś takiego, aby użytkownik mógł cały czas używać /home/<user>, a nie jakiegoś /home/server1/<user>. Co więcej, nawet jeśli stworzysz te drzewa odnośników, to po wydaniu poleceñ takich jak pwd, zobaczysz prawdziwą ścieżkę (np. /server1/<user>) zamiast ścieżki logicznej (/home/<user>). Takie ścieżki, prędzej czy później, są używane w skryptach itp., więc jeśli później przeniesie się użytkownika gdzie indziej, wszystko się psuje. Jeśli nie montujesz katalogów użytkowników bezpośrednio, tracisz warstwę abstrakcji. Jedynym innym rozwiązaniem, jakie znam, jest amd. Amd automatycznie umieszcza odnośnik. Ale ponieważ pochodzimy ze świata suna, używamy sunowskiego automountera i nie mieliśmy dotąd żadnych z nim problemów.

Jako inny przykład możesz wziąć pamięć masową NAS w dużej firmie. Tutaj także musisz wybrać pomiędzy montowaniem per użytkownik a montowaniem nadrzędnego katalogu z wieloma użytkownikami. W tym drugim przypadku znów tracisz tę dodatkową warstwę abstrakcji.

Myślę zatem, że byłoby dobrze mieć przynajmniej opcję do zamontowania więcej niż 256 NFS-ów, nawet jeśli trzeba wówczas użyć portów > 1024.

dostępna jest wersja schedulera -J4:

http://redhat.com/~mingo/O(1)-scheduler/sched-O1-2.5.3-pre2-J4.patch
http://redhat.com/~mingo/O(1)-scheduler/sched-O1-2.4.17-J4.patch

nie ma żadnych otwartych/zgłoszonych błędów, ani też żadne błędy nie zostały zgłoszone od czasu -J2. Wygląda na to, że nowy scheduler zaczyna się stabilizować.

-J4 zawiera dwie zmiany, które powinny poprawić interaktywność:

1. wprowadzenie ,,super-długich'' kwantów czasu, najdłuższy kwant trwa 500 msek -- wcześniej było to 180 msek. Nową domyślną wartością kwantu jest 250 msek, a było wcześniej -- 90 msek.

   przyczyną super-długich kwantów czasu jest to, że IMO możemy sobie na nie pozwolić. W tej chwili scheduler dobrze sobie radzi z rozpoznawaniem zadañ interaktywnych. Możemy zatem zwiększyć długość kwantu czasu bez ryzyka utraty dobrych interaktywnych opóźnieñ. Długie kwanty czasu mają trochę zalet:

   • nice +19 pożera mniej procesora niż to miało miejsce wcześniej.
   • zadania interaktywne mogą otrzymać większy ,,rezerwowy'' czas, który mogą całkowicie zużyć na swoje przetwarzanie.
   • pożeracze CPU, dzięki dłuższym kwantom czasu i rzadszym przełączeniom kontekstu, uzyskają lepszą afiniczność pamięci podręcznej.

   Długie kwanty czasu mają także wady:

   • przy dużym obciążeniu, jeśli interaktywne zadanie wpadnie w pułapkę przywiązania do procesora, będzie dłużej czekało na przydział kolejnego kwantu czasu.

   sprawdziłem, że, przy pewnych obciążeniach, argumenty za biją na głowę te przeciw, ale YMMV - potrzeba więcej testowania przez większą liczbę ludzi oceniających odczucia interaktywne (oraz zachowanie, oraz wyniki kompilacji jądra) przy pracy z J4 z interaktywnym zachowaniem i wydajnością J2.

2. lekkie skurczenie zakresu zysk/kara (bonus/penalty) jakie może dostać zadanie.

   zmniejszyłem zakres zysk/kara z +-19 stopni priorytetów do +-14 stopni. (z 90% pełnego zakresu do 70% pełnego zakresu.) Powodem, dla którego można to zrobić nie psując interaktywności, jest to, że nie ma już dłużej potrzeby używania maksymalnego zakresu priorytetów - informacja o interaktywności jest przechwowana w p->sleep_avg, która nie jest wrażliwe na zakres priorytetów.

   To skurczenie ma dwie korzyści:

   • troszeczkę gęstsze tablice priorytetów, troszeczkę lepsze użycie pamięci podręcznej.
   • większe odstępy pomiędzy poszczególnymi poziomami nice. Na przykład zadania o nice -20 mają teraz sześciostopnową ,,strefę buforową'', która nie może być zajęta przez normalne interaktywne zadania. Demony audio o nice -20 powinny na tym zyskać. Także normalni pożeracze CPU są lepiej izolowani od pożeraczy CPU o nice +19 z tymi samymi 6 poziomami ,,strefy buforowej''.

   (przez skurczenie zakresu zysk/kara, -3 w definicji TASK_INTERACTIVE zmniejszyło się do -2.)

Changelog:

• Erich Focht: optymalizacja max_load, usunięcie prev_max_load.
• Robert Love: uproszczenie unlock_task_rq().
• Robert Love: poprawka wartości przesunięcia ->cpu entry.S dla x86, wykorzystywanej przez łatę z wywłaszczaniem.
• ja: poprawki interaktywności.
• ja: sched_rr_get_interval() powinna zwracać wartość kwantu czasu w oparciu o ->__nice, a nie -- o ->prio.

Pomiar wydajności zrównoleglonej kompilacji jądra z ciepłą pamięcią podręczną na 8-procesorowej maszynie NUMA-Q. Obsługa highmem jest wyłączona, więc używam jedynie pierwszego 1GB czy jakoś tak RAM (bez HIGHMEM jest o wiele szybciej).

przygotowanie
make -j16 dep; make -j16 bzImage; make mrproper; make -j16 dep;

pomiar:
time make -j16 bzImage

2.4.18-pre7

330.06user 99.92system 1:00.35elapsed 712%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (411135major+486026minor)pagefaults 0swaps

2.4.18-pre7 ze schedulerem J6

307.19user 88.54system 0:57.63elapsed 686%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (399255major+484472minor)pagefaults 0swaps

Wygląda na poważną poprawę, nie tylko ze względu na krótszy czas wykonania, ale także ze względu na mniejsze obciążenie procesora.

To jest pierwsza wersja kodu, który przesuwa tablicę stron do highmem. W tej chwili kompiluje się jedynie na x86 i jest jeszcze w stadium eksperymentalnym. Jednakowoż nie jestem w stanie wygenerować żadnych problemów. Nowa łatka pte-highmem znajduje się pod adresem:

ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.18pre4aa1/20_pte-highmem-6

W dalszej kolejności muszę zapewnić kompilację na architekturach nie-x86 i chciałbym wyodrębnić łaty vary-IO dla rawio i hardblicksize-O_DIRECT.

ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.18pre4aa1.bz2
ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.18pre4aa1/

Nie masz racji. Niepisanie dokumentacji marnuje czas innych deweloperów. Niesie ze sobą komunikat: ,,mój czas jest cenniejszy niż Wasz''. W przypadku Linusa to może być prawdą, ale z pewnością nie jest w przypadku każdego innego z głównych deweloperów.

Do obowiązków każdego z deweloperów należy przygotowanie, przynajmniej minimalnej, ale wystarczającej, dokumentacji pracy, którą wykonali. Inne osoby, które specjalizują się w przygotowywaniu dokumentacji, mogą wówczas wykorzystać te materiały, jako punkt startowy w przygotowywaniu jaśniejszej i rozszerzonej dokumentacji. Ale jeśli główni deweloperzy olewają swoje obowiązki w tym zakresie, będziemy cały czas cierpieć na chroniczny brak dobrej i bieżącej dokumentacji jądra.

Sugerowałbym nazwanie wartości z /proc/sys/sched w ten sam sposób, w jaki są nazywane stałe w kodzie. Np. /proc/sys/sched/CHILD_FORK_PENALTY. To znacznie ułatwi sugerowanie zmian parametrów.

Mam taki skrypt, który czyta bieżący stan parametrów schedulera:

[root@mars root]# ./getsched
echo 95 > /proc/sys/kernel/CHILD_FORK_PENALTY
echo 3 > /proc/sys/kernel/EXIT_WEIGHT
echo 3 > /proc/sys/kernel/INTERACTIVE_DELTA
echo 200 > /proc/sys/kernel/MAX_SLEEP_AVG
echo 30 > /proc/sys/kernel/MAX_TIMESLICE
echo 100 > /proc/sys/kernel/PARENT_FORK_PENALTY
echo 70 > /proc/sys/kernel/PRIO_BONUS_RATIO
echo 60 > /proc/sys/kernel/PRIO_CPU_HOG_RATIO
echo 20 > /proc/sys/kernel/PRIO_INTERACTIVE_RATIO
echo 200 > /proc/sys/kernel/STARVATION_LIMIT

Skrypt jest bardzo prosty:

cd /proc/sys/kernel

for N in *[A-Z]*; do echo "echo "`cat $N`" > /proc/sys/kernel/$N"; done

Poza tym nasze podejście jest identyczne. Niech ta łata pozostanie oddzielną, ale niech będzie łatwo aplikowalna dla ludzi, którzy chcą mieć większą kontrolę nad schedulerem, czy to do jego rozwijania, czy to do jakiegoś innego celu.

Patrzyłem na ten plik nagłówkowy i nie rozumiem składni asemblerowej.

W szczególności jedyna instrukcja div asemblera x86, którą znam, zwraca 32-bitowy wynik. Ponieważ nie rozumiem zawartości nagłówka div64, nie mogę zrozumieć, jak obliczany jest wynik 64-bitowy.

Bałem się, że ktoś tak powie.

Dokumentacji do Pentium nie muszę szukać dalej niż na półce po mojej prawej stronie. Nie sądzę jednak, aby to był dobry odpowiednik dokumentu wyrażającego składnię wszystkich instrukcji maszyny z konkretną architekturą w składni GNU.

Jedynym usprawiedliwieniem braku takiego dokumentu jest to, że ,,jesteśmy wszyscy tak zajęci, że nie mogliśmy go napisać. Zajrzyjcie do dokumentacji Intela''. Proszę, nie mówcie, że nie ma potrzeby posiadania własnej, napisanej w zjadliwszej dla nas formie, dokumentacji.

Jeden ,,pingwin łatacz'' skaluje się nie lepiej niż ja. Właściwie, to twierdzę, że większość z nich skaluje się znacznie gorzej.

Faktem jest, że mieliśmy ,,pingwiny łataczy'' prawie od zawsze, nazywamy ich opiekunami podsystemów. Opiekują się oni swoimi podsystemami, mam na myśli ludzi takich, jak David Miller (networking), Kai Germaschewski (ISDN), Greg KH (USB), Ben Collins (firewire), Al Viro (VFS), Andrew Morton (ext3), Ingo Molnar (scheduler), Jeff Garzik (sterowniki sieciowe) itd. itd.

Jeśli są problemy z pewnymi łatami, to zwykle dzieje się to z jednego lub z kilku następujących powodów:

• podsystem jest kiepsko zmodularyzowany (dość częste, przynajmniej pierwotnie. Nie sądzę żeby wiele osób zdawało sobie sprawę jak _daleko_ zaszedł Linux w ciągu ostatnich pięciu lat, biorąc pod uwagę rzeczy takie jak architektury, niezależność sterowników, infrastrukturę systemu plików itp). I to się cały czas dzieje.

• brak zainteresowania opiekunów. Wielu ,,opiekunów'' jest mniej zainteresowanych prawdziwym włączaniem, a bardziej wpychaniem jakiegokolwiek kodu, który mają i powiększaniem łat, zamiast próbą utrzymywania ich w kawałkach.

  To zwykle jest kwestia przyzwyczajenia się, najlepsi ludzie się przyzwyczaili naprawdę szybko (na przykład Andrea kiedyś zupełnie tego nie robił, ale zobaczcie, jak to robi teraz! Z punktu widzenia łączenia, jego łaty z ,,koszmarnych'' stały się ,,bardzo dobre'')

• osobowości/problemy z komunikacją. Tak, one się zdarzają. Próbowałem zorganizować sobie ludzi, którzy byliby ,,filtrami'' do tych, z którymi nie umiem pracować, ale muszę powiedzieć, że jeśli tylko nie mogę z kimś pracować, inni też mają z takimi ludźmi prawdziwe problemy.

  (Przykład bardzo udanej sytuacji: David Miller i Alexey Kuznetsov: Alexey zwykle miał bardzo niekontrolowane łaty, których działania nie umiałem osądzić, ale w oczywisty sposób miały spory potencjał. David, działający jako filtr, uczynił z nich dwóch świetny zespół.)

W skrócie, jeśli widzisz pewne obszary albo łaty, które wydają Ci się problematyczne, zapytaj sam siebie, _dlaczego_ są problemy z tymi kawałkami.

Słowo ostrzeżenia: trudno znaleźć dobrych opiekunów. Zdobywanie nowych pomaga, ale z drugiej strony bardziej użyteczna może okazać się pomoc tym _istniejącym_. Jest około dziesięciu-dwudziestu ludzi, którym naprawdę ufam i, całkiem szczerze, sposób, w jaki ludzie pracują, jest zapisany w DNA. Nikt tak naprawdę nie ufa setkom ludzi. Sposobem na to, by takie grono się zwiększyło jest stworzenie sieci zaufania, a nie wymuszanie tego zaufania na mnie, chodzi o to, by była to sieć, ale nie taka o topologii gwiazdy ze mną w środku.

W skrócie: nie próbuj wymyślać ,,pingwina łatacza''. Zamiast tego spróbuj pomóc pracującym opiekunom, albo pomóż wyhodować nowych. TO jest droga do skalowalności.

Jedna rzecz zaintrygowała mnie w tym wątku - nie sama dyskusja, ale fakt, że Rik używa bitkeepera.

Jak wiele innych osób naprawdę używa już bitkeepera do jądra? Wiem, że robią to ludzie od ppc, już od dłuższego czasu, ale kto jeszcze? bk, nie tak jak CVS, powinien _móc_ obsłużyć podejście typu ,,sieć ludzi''.

Ja, dla USB i rzeczy związanych z PCI hotplug:

http://linuxusb.bkbits.net/

To pozwala śledzić jakie łaty zostały zaaplikowane, a jakie nie i przenosiny tych niezaaplikowanych do następnych wersji; to, przy użyciu BK, pryszcz.

Moje drzewa są czytelne dla świata i zapraszam wszystkich do wysyłania mi łat na nie, albo nawet bitkeeperowych zbiorów zmian, ale najpierw muszę dostać przynajmniej jedno takie coś :)

Oczywiście, że jest to możliwe, możliwe są też zmiany, które uczynią BK bardziej użytecznym. Teraz nie ma żadnego zapisywania zmian, które są wprowadzane, a potem są jednak odrzucone; odbywa się to tak jakbyś coś załatał, a potem nałożył łatkę w drugą stronę.

Dobra wiadomość to taka, że każda zmiana (łata) ma swój identyfikator, który wygląda jakoś tak

awc@bitmover.bitmover.com|ChangeSet|20011230212716|39200

i jeśli będziemy rejestrować odrzucane łaty, to śledzenie przez dewelopera tego, czy jego zmiana była zatwierdzona/niezauważona/odrzucona będzie trywialne.

Wydaje się, że Bitkeeper ma pewne problemy przy aplikowaniu zbiorów zmian w złej kolejności lub aplikowaniu ich częściowo.

Także zmiany przesłane przez 'bk send' znacznie trudniej przeczytać niż unidiffy ;)

Sądzę, że by bitkeeper był naprawdę użyteczny w rozwoju jądra naprawdę potrzebujemy:

1. format 'bk send' taki, żeby Linusowi było łatwo go czytać
2. możliwość przesyłania pojedynczych poprawek (na przykład poprawek foo_net.c od 1.324 do 1.350) w jednym zgrabnym unidiffie
3. możliwość aplikowania łatek przez Linusa, które są troszeczkę ,,zepsute'' - bezpośrednia konsekwencja (2)

Są dwie kwestie, jedna że coś jest nie po kolei, a druga to to, co nazywamy ,,nieistniejącymi zależnościami''. Sądzę, że to drugie tak Ci przeszkadza. Powód dla którego chcesz mieć coś aplikowanego w złej kolejności to nieprawdziwe zależności, przynajmniej tak mi się wydaje, ja Ci powiem o co mi chodzi, a Ty odpowiesz.

Przypuśćmy, że dokonujesz 3. zmian: zmiany sterownika, zmiany w podsystemie pamięci wirtualnej i zmiany w kodzie dotyczącym sieci. Przypuśćmy też, że chcesz wysłać Linusowi zmianę w sieci. Gdy używasz patch robisz po prostu diff, wysyłasz i masz nadzieję, że patch da sobie z tym radę u drugiej osoby. W BK, przynajmniej na dziś, jest liniowa zależność między wszystkimi trzema zmianami i jeśli chcesz posłać zmianę w części dotyczącej sieci, musisz także posłać pozostałe 2. zmiany.

Jak wiele rzeczy umyka jeśli możesz przysyłać zmiany w złej kolejności tak długo jak długo na siebie nie zachodzą (nie dotykają tych samych plików)?

o to chodzi w tej kwestii. Zmiany w różnej kolejności są znacznie ważniejsze dla dużego open source'owego projektu niż dla klientów komercyjnych. Trudno to także zrobić poprawnie, zajęłoby to co najmniej miesiąc. Linus flirtował z BitKeeperem wiele razy, a potem przestawał się nim interesować. Jeśli zarzucilibyśmy wszystko i naprawili rzeczy, których on potrzebuje zamiast rzeczy, których chcą nasi klienci, interes przestałby nam się opłacać i waszym uroczym zadniem byłoby sprawienie żeby to działało przez grzebanie w źródłach BitKeepera. Możecie mi wierzyć albo nie, ale macie niewielkie szanse zmusić to do działania, podstawowy kod BK jest znacznie większy i bardziej skomplikowany niż główna część jądra Linuksa.

Jeśli wystarczająco wielu ludzi związanych z jądrem zacznie używać BitKeepera i będzie domagać się rzeczy związanych z kolejnością aplikowania zmian, zrobimy to. Czas potrzebny na wprowadzenie tego to około miesiąca, więc musicie sobie jakoś z tym radzić. Z drugiej strony, jeśli cała ta sprawa z BK zmieni się w kolejne ,,kocha, nie kocha, kocha, nie kocha'' jądra, to nie zamierzamy poprawić tej rzeczy, zanim nasi klienci nie stwierdzą, że jest to najpoważniejszy problem.

Mam nadzieję, że przyjmiecie to w takim duchu, w jakim było to zamierzone. Chcemy pomóc zespołowi pracującemu nad jądrem, to był powód napisania BitKeepera. Musimy jednak jakoś przetrwać, a to oznacza zwracanie uwagi także na potrzeby ludzi, którym sprzedajemy produkt. Jeśli/gdy uznamy, że Linus i s-ka na serio myślą o używaniu BK, to oddeleguję ludzi do tej sprawy z niedziałającymi rzeczami i podam datę wykonania tego. Jest jasne, że to największa wpadka z BK i pracą nad jądrem.

5 dni temu wysłałem 8 różnych łat uaktualniającyh scheduler:

[patch] [sched] fork-fix 2.5.3-pre5
[patch] [sched] yield-fixes 2.5.3-pre5
[patch] [sched] SCHED_RR fix, 2.5.3-pre5
[patch] [sched] set_cpus_allowed() fix, 2.5.3-pre5
[patch] [sched] entry.S offset fix, 2.5.3-pre5.
[patch] [sched] cpu_logical_map fixes, balancing, 2.5.3-pre5
[patch] [sched] compiler warning fix, 2.5.3-pre3
[patch] [sched] unlock_task_rq() cleanup, 2.5.3-pre3

te łaty, jakkolwiek wiele z nich dotyka tego samego pliku (sched.c), są ortogonalne jeśli chodzi o funkcjonalność i mogą być nakładane w dowolnej kolejności. Linus zaaplikował je wszystkie, ale mógł ominąć każdą wątpliwą i ciągle nałożyć resztę.

jak takie zmiany mogłyby być ujęte przy użyciu BK i czy mogłoby być możliwe odrzucenie/zaakceptowanie przez Linusa dowolnego zbioru tych łat?

Jest sposób na zrobienie tego w BK tak, że działałoby nieźle. To przenosi część pracy na dewelopera, ale jeśli masz chęć to zrobić, nie problemu ze zrobieniem tego co chcesz z BK w jego obecnej formie i podejrzewam, że praca, którą trzeba wykonać jest podobna do tego, co i tak robisz.

Na Twojej liście podanej powyżej, wszystkie łaty są łatami na 2.5.3-pre5. Jeśli zrobiłeś każdą łatę na podstawowe 2.5.3-pre5, sprawdzając, wykonując ,,check in'', zapamiętując jako łatę BK, usuwając zbiór zmian z drzewa i przechodząc do następnej zmiany, to to, co masz, to dokładnie ten zbiór łat, który miałbyś jakbyś nie miał żadnej. Dosłownie. Możesz teraz napisać odpowiednią komendę BK i powinieneś móc wygenerować to, co chcesz.

W ,,rozumie'' BK, wykonałeś bardzo ,,gęsty'' zbiór zmian, jedna ,,koło'' drugiej. Jeśli pomyślisz o grafie zmian to wychodzisz z:

[starsze zmiany]
v
[2.5.3-pre4]
v
[2.5.3-pre5]

a potem dodajesz jedną zmianę pod tym, wiele razy. Jeśli miałbyś połączyć wszystkie zmiany w jedno drzewo BK, to wyglądałoby to tak:

[starsze zmiany]
v
[2.5.3-pre4]
v
[2.5.3-pre5]
[sched1] [sched2] [sched3] [sched4] [sched5] [sched6] [sched7]

a BK spokojnie pozwoliłby Ci wysłać Linusowi każdy podzbiór zmian sched i działałoby to *właśnie* tak, jak chciałbyś. Jeśli udałoby się namówić ludzi, żeby tak pracowali, to nie ma problemu. Żeby to już zupełnie wyjaśnić powinieneś zrobić to:

for p in patch_list
do bk vi sched.c # that will lock it if isn't

hack, debug, test
bk citool # check it in and make a changeset
bk makepatch -r+ > ~/bk-patches/patch.$p
bk undo -fr+ # get back to the same baseline

done

Oto, co ludzie robią w rzeczywistości. Najpierw robią zmianę, potem robią drugą zmianę w tym samym kodzie, który zawiera już pierwszą zmianę i tak dalej. BitKeeper dokładnie zapisuje liniową sekwencję zmian i wymusza liniową propagację zmian. Możesz ominąć niektóre z koñca, ale nie możesz ominąć żadnej w środku.

W Twoim szczególnym przypadku potrzebujemy zbiorów zmian, które mogą być nakładane nie po kolei, by pozwolić na przepływ pracy drugiego rodzaju i wybieranie przysmaków. Jednakże najczęstszy przypadek to taki, w którym zmiany są w niepowiązanych ze sobą plikach, a *nawet wtedy* BitKeeper wymusza liniowość. To jest problem, który musimy rozwiązać jako pierwszy, to nie jest pełne rozwiązanie, ale to 80-90% rozwiązania. Dopóki nie dostarczymy wam 100-procentowego rozwiązania, musicie uświadamiać sobie, że wykonujecie zmiany leżące jedna koło drugiej i wykonywać je w opisany sposób.

Jeśli to nie jest dla kogoś jasne, to proszę, niech się odezwie, a ja spróbuję narysować trochę obrazków i dołożyć wyjaśnienia.

Chodzi o to, że bk ma szansę robić to sam.

Zasada check-in powinna być taka: jeśli wynikowy zbiór zmian może być automatycznie połączony z wcześniejszym zbiorem zmian, to powinien być on _równoległy_ do tego zbioru zmian, nie liniowy.

Zauważcie uwagę ,,automatycznie połączony''. To ciągle gwarantuje spójność bazy danych na wszystkich poziomach.

Załóżmy, że masz drzewo, które wygląda tak:

        a -> b -> c

razem z modyfikacjami ,,d''. Teraz, ,,bk ci'' (albo, bo jest to bardziej kosztowne niż czyste ,,ci'', możecie to nazwać ,,bk backmerge'', albo jakos tak, a wszyscy zdrowi na umyśle ludzie po prostu przestaną używać ,,ci''), zamiast wykonywać gołe:

        a -> b -> c -> d

powinno sprawdzić jak daleko w tył może dojść z automatycznym połączeniem i dodać ,,d'' w _najodleglejszym_ możliwym miejscu. Załóżmy więc, że ,,d'' nie może być połączone z ,,b'', ale nie kłóci się z ,,c'', więc to, co moglibyście wyprodukować z ,,bk backmerge'' byłoby ,,maksymalnie równoległą wersją:

        a -> b -> c
                \
                 > d

Teraz powiecie, że to ma koszt wykładniczy, a ja się zgodzę. Ale czas procesora jest tani i zauważcie, że taki ,,backmerge'' nie będzie robiony w jednym centralnym miejscu, ale równolegle przez różnych deweloperów.

(Tia, mój przykład może wyglądać na ,,tani'', ale jeśli robisz wyłącznie takie połączenia, to bardzo szybko Twoje drzewa będą się szeroko rozwijały, a najciekawsze łączenie w tył będzie, jeśli będziecie już mieli:

        a -> b -> c -> f

                -> d

                -> e

i będziecie dodawali ,,g'', które nie łączy się z ,,c'', nie łączy się z ,,d'' ani z ,,e'', więc musisz testować każdą ścieżkę w tył, żeby zobaczyć gdzie możesz to wepchnąć. W tym przypadku skoñczylibyście z takim

        a -> b  -> c -> f

                     -> g

                -> d

                -> e

typem drzewa.

Jak drogie by to było? Z chęcią pozwoliłbym się spocić mojej maszynie, jeśli wygenerowałaby ona automatycznie możliwie najwięcej równoległych zbiorów zmian... I założę się, że możecie _to_ zrobić całkiem łatwo jeśli nie zwracalibyście zbyt wielkiej uwagi na wydajność.

Mówicie, że wasze łączenia są doskonałe. UŻYJCIE tej wiedzy i pozwólcie robić ,,bk backmerge''.

(Jeśli zrobisz backmerge, to pozbędziesz się nieprawdziwych zależności i nagle ,,bk'' da ludziom informację, której nie mieli wcześniej: historia wersji naprawdę mówi o _prawdziwych_ zależnościach w drzewie, a nie głupio: ,,to jest porządek w jakim wykonywano check-iny'', co nie daje nic więcej niż można zobaczyć bezpośrednio w zbiorze zmian)

Larry, daj mi to, a ja obiecuję używać przez dwa miesiące tylko bk...

naprawdę etyketą, która implikowałaby pewien moment jak i zmiany, które nastąpiły przed nim. Mówiąc inaczej, to jest zbiór.

Używając twojego grafu:

        a -> b -> c -> f

                -> d

                -> e

sposób w jaki ludzie teraz myślą (a zarazem mówią) o tym, mówiąc, że używasz wersji jądra ,,e'' jest niejednoznaczny, bo to może mieć lub nie mieć ,,c'' lub ,,d''. Ta niejednoznaczność również komplikuje zadanie późniejszego odtworzenia drzewa w pewnym znanym stanie.

Ty, jako centrum znanego nam świata, nie musisz zajmować się takimi drobiazgami, ale z punktu widzenia jednego z tych bajkowych klientów komercyjnych, możliwość jednoznacznego określenia, co zostało zmienione (czytaj: naprawione) jest naprawdę ważna.

Podsumowując, podoba mi się Twój pomysł grafu wersji. Moje uwagi mogą łatwo być złagodzone przez dodanie możliwości umieszczania ,,wersji'' (po prostu znaczników, które implikują/włączają wszystkie poprzedzające zbiory zmian).

Nie zgadzam się.

"g" jest naprawdę jedną rzeczą: oznacza ,,zmiany''.

Masz jednak oczywiście rację, że wszystkie zmiany są nieodłącznie zależne od kontekstu, w którym są dokonywane. A kontekstów jest wiele.

Jeden kontekst to po prostu ,,kiedy w czasie'', który jest interesujący, gdy serializuje się wszystkie zbiory zmian i można zobaczyć, jak wszystko rozwijało się w czasie. I jest to naprawdę _tylko_ jeden kontekst, na który BK (i większość innych narzędzi do kontroli kodu) zwraca uwagę.

A jednak, w innym znaczeniu, ,,kiedy w czasie'' jest kompletnie bez znaczenia. Czy powinniśmy troszczyć się o to, jak _w czasie_ są od siebie zależne zupełnie niezależne łaty? Ja twierdzę, że ,,Absolutnie nie!''. Zależność w czasie ukrywa tylko _realną_ informację o wersjach, która to informacja składa się z tego która łata zależy od której.

Zauważcie, że moja sugestia by mieć ,,bk backmerge'' nie usuwa zależności czasowej. Każdy zbiór zmian jest oznaczony pewnym czasem (jasne, że muszą tak być oznaczane, po prostu by można było zobaczyć co się zdarzyło i zadać pytanie ,,jak to drzewo wyglądało miesiąc temu?''). Zatem _mamy_ już informację o czasie, a zakodowanie tej informacji w informację o zależnościach jest dość drogie.

Powiedziałbym, że większość (a może wszystkie) skarg na to, że nie da się nakładać zbiorów zmian w dowolnym losowym porządku biorą się bezpośrednio z faktu, że deweloperzy _wiedzą_, że zależność z czasie często nie jest trafna. Z punktu widzenia dewelopera, relacje w czasie są istotne tylko wtedy, gdy zgadzają się z relacjami _przyczynowymi_, ale nawet wtedy często znajdują się łaty, które zostały _spowodowane_ przez inne, wcześniejsze, ale są poprawne same w sobie (i mogą być naprawdę ważniejsze, albo nawet wyelimować potrzebę posiadania oryginalnej łaty).

To, co chcę powiedzieć to to, że z punktu widzenia wersji łat, informacja na temat czasu jest bezużyteczna. Cały czas mamy wystarczająco wiele informacji, by odtworzyć drzewo ,,w chwili g'' wykonując odpowiednio ,,bk get -c<data-g>''.

nie tracisz tej możliwości. Ciągle masz taką informację jaką miałeś, masz tylko nawet _więcej_ informacji. Wiesz nie tylko kiedy zmiana była wprowadzona (w sensie czasu), masz też informację na temat plików lub zmian, od których naprawdę była _zależna_.

Teraz, po tych argumentach, po prostu definitywnie zakoñczę mówiąc, że właściwie zgadzam się z tobą do pewnego stopnia - tak jak już napisałem w prywatnym emailu do Larry'ego, niewątpliwie chciałbym też mieć sposób na zatrzymanie łączenia w tył w pewnym momencie. W szczególności, gdybym chciał oznaczyć wersję (to znaczy coś takiego jak Linux-2.5.3, chciałbym potencjalnie móc ustanowić znacznik backmerge, który mówiłby mechanizmowi backmerge, że nie warto próbować łączyć nowości z tym, co powstało przed ustanowieniem tego znacznika.

To zmniejszyłoby znacznie okazję do pomyłek i pozwoliłoby uniknąć problemu ze złożonością wykładniczą. Spójrzmy prawdzie w oczy - wykładnicze algorytmy mogą być użyteczne, ale chcesz mieć jednak sposób na to, żeby być pewnym, że w praktyce nigdy nie zaobserwujesz ich złego zachowania. Rozważenie sposobu na ograniczenie zbioru zmian, które mają być rozważane jako takie, które należy łączyć w tył jest konieczne nie tylko ze względu na ludzi, których nie należy mylić, ale także ze względu na to, że komputery nie będą musiały wykonywać bezsensownej pracy próbując dojść do Linuksa w wersji 0.01, jeśli okaże się, że jakaś mała łata akurat daje się zastosować we wszystkich pośrednich wersjach.

To nie takie znowu hipotetyczne, ale prawidziwe. To jest przyczyna, dla której zasugerowałem, że takie ,,głębokie łaczenie'' nie powinno przekraczać pewnych przeszłych znaczników.

Powiedzmy sobie jasno, narzędzie do kontroli źródeł nie ma szans wiedzieć, co działa, a co nie. Jedyne co możemy kiedykolwiek osiągnąć, to wiedza o tym, ,,co się daje nałożyć''. Można przyjąć takie podejście, że wszystko aplikujemy tylko do ostatniej gałęzi - to jest tradycyjne podejście, które jednak wprowadza zależności, których po prostu nie ma, i które _nie mogą_ być usunięte. Tak teraz działa bk.

Inne podejście to tej sprawy to takie, w którym mówimy: ,,wszystko co da się zastosować, stosujemy, i tak długo jak nie tracimy informacji o wersjach, przesuwamy zmiany w tył''. Z nim związane są inne problemy (jak to zauważyłeś), ale możemy teraz zarządzać tymi problemami i mamy rozwiązanie.

Wolę mieć problem, który może być rozwiązany od problemu, który nie ma rozwiązania.

Faktem jest, że praca nad projektem _często_ znajduje się w sytuacji, w której ktoś wykonuje szybką-i-brzydką poprawkę, a dopiero potem robi coś dalej, zagłębia się w problem i dokonuje właściwej poprawki, która czyni tę oryginalną zupełnie niepotrzebną.

Przy sposobie, w jaki działa BK teraz, jeśli tę szybką-i-brzydką poprawkę nazwiemy ,,A'', a tę prawdziwą ,,B'', to deweloper nie ma fajnie gdy chce mi wysłać ,,B''. Musi stworzyć klona wcześniejszego drzewa z BK, zrobić B na tym drzewie, a potem wysłać mi drugą wersję.

Sugeruję, żeby wysyłał mi po prostu B i pozbywał się własnego drzewa. Nie ma żadnych zależności od A i nie chcę _gówna_ w moim drzewie, tylko dlatego, że A było w pewnym stanie przejściowym.

Nie chcę mówić za Linusa, ale mój główny problem z BK jest podobny do tego, co opisałeś. Poniżej opiszę to, co zwykle robię i co bym chciał, żeby było możliwe do uzyskania z BK:

Załóżmy, że mamy pięć ,,delt'' - A, B, C, D, E. Chcę zlikwidować A.

dodaję gałąź, składającą się z B' (B przeniesione tak, że aplikuje się do oryginału) i ABB'^{-1}. Dołącza się ona do oryginalnej w AB.

Przenoszę C na B'. Teraz mam B', C', ABC(B'C')^{-1}. Znowu dołączam do oryginalnej gałęzi.

Powtarzam to dla D i E. Mam z tego następujący obrazek (przepraszam za paskudny ASCII-art):

* -B'-> * -C'-> * -D'-> * -E'-> *
|                              /
A                            dziadostwo
V                            V
* -B-> * -C-> * -D-> * -E-> *

_Teraz_ zmieniam kierunek ostatniej strzałki. Tak to mniej więcej odwrócenie A. W ten sposób chciałbym przyjąć górną gałąź za główną historię rozwoju drzewa.

To co chcę, to możliwość zabawy w rewizjonistę. To nie ogranicza się tylko do usuwania łat - jeśli znalazłbym błąd w A, chciałbym móc dodać poprawkę A i przenieść ją na wszystkie wersje, które pojawiły się po A. I odpowiednio połączyć. B, C, D i E mogłyby się zmienić od tego, ale tego naprawdę chcę. Co więcej, mógłbym zostawić trochę śmiecia na koniec (to znaczy mieć ABCDEA-poprawkę == (AA-fix)B'C'D'E'szum) i chciałbym móc powiedzieć, że (AA-fix)B'C'D'E' jest teraz główną gałęzią, a inna ścieżka (ABCDE A-poprawka szum^{-1}) została pogrzebana.

Jeśli dacie mi sposób w który mógłbym to robić - będę szczęśliwy.

Nie chcę żeby A (czy w ogóle cała ścieżka) zniknęło. To, co chcę, to możliwość posiadania dwóch ścieżek prowadzących do tego samego punktu + możliwość zaznaczenia jednej z nich, jako ,,bardziej interesującej''.

Oznacza to, że w wyniku chciałbym mieć _dwa_ zbiory zbiorów zmian z tymi samymi składaniami.

A _to_ jest zgodnie z replikacją - po prostu chcę mieć nową ścieżkę propagacji w grafie wersji razem z napisem ,,ta ścieżka jest bardziej interesująca'' uczynionym na nowej ścieżce.

Czy to może być zrobione? Chciałbym mieć sposób na ponowne połączenie zbioru delt. Jestem bardzo zadowolony z tego, że stara wersja zostaje, tak długo, jak długo pamiętamy, że wynikiem starej i nowej ścieżki zmian jest to samo, ale to nowa jest preferowanym sposobem patrzenia na to wszystko.

Podejrzewam, że takie coś może być zrobione przy użyciu czegoś tak prostego, jak ,,jeśli prosisz o połączenie dwóch identycznych rzeczy, po prosu zaznacz, że są one takie same i zapytaj która jest bardziej interesująca''. IIRC, BK nie wymaga, żeby grafy rozwoju były drzewami, mogą mieć zbiegające się gałęzie.

_Jeśli_ to jest wykonalne - resztę można załatwić pomocniczymi skryptami.

Ach, chciałbyś mieć LODy. One zgrabnie rozwiązują problem, który opisałeś. I cały zestaw innych. Pomyśl o LODach jako o grafach historii wersji. Wyobraź sobie, że możesz tworzyć nowe, puste (albo częściowo zamieszkałe) ,,pojemniki''. Taki pojemnik to LOD. Możesz wykonywać operacje na zbiorach z jednego LOD do drugiego. Są one bardzo podobne do gałęzi, ale one mogą same się rozgałęziać i łączyć.

Sposób w jaki zrobilibyśmy to co chcesz, to stworzenie nowego LOD, wsadzenie w niego B, C, D, E i uczynienie go domyślnym LOD w twoim repozytorium.

LODy mają parę fajnych atrybutów - każda zmiana jest elementem zbioru, LOD jest niczym więcej niż zapisaną historią tego, jakie zbiory elementów są w tym LODzie, możesz sobie też wybierać kawałeczki z jednego LODu do drugiego. Nie po kolei, bardzo rzadko, jakkolwiek.

Jedyne ograniczenie polega na tym, że musisz mieć wszystkie zmiany w swoim grafie. Nie ma pomysłu na niespójny graf. Możesz wyciąć rzeczy, które zdarzyły się później niź coś, ale nie możesz usunąć punktów ze środka, nawet jeśli są w innym LODzie. Czy to jest OK?

Na początku wydawało się, że Linus zaakceptował to jako odpowiedź, ale później przestało mu się to podobać, bo zauważył, że może schować zły zbiór zmian w innym LOD, ale to co by chciał to usunięcie go w ogóle z grafu. Nie wiem jak to zrobić.

Inna pułapka polega na tym, że LODy zostały tylko częściowo zaimplementowane i to się raczej nie będzie inaczej zanim nie osiągniemy zgody na temat jak naprawdę BK ma działać dla was.

Postaram się teraz zobaczyć, czy zrobi jakąś różnicę, jeśli spróbuję używać BK przez miesiąc albo dwa. Poważnie wątpię, że to naprawdę ,,naprawi'' całą sytuację, ale też nie wydaje mi się, żeby miała pomóc wielka reorganizacja i patch-listy. Ale byłbym głupi, gdybym nie miał ochoty czegoś spróbować.

(Do tej pory wypróbowywanie BK znaczyło tylko, że nie spędzałem mojego czasu na włączaniu nowych łat i czytaniu maili, ale większość tego czasu zajęło mi pisanie pomocniczych skryptów i maili do Larry'ego, tak by uczynić możliwym używanie BK na zdrowy, pasujący mi sposób. I bardzo wątpię, żeby udało się Wam zauważyć jakikolwiek wzrost mojej produktywności przez jakiś czas ;)

Pracowałem nad tym po cichu i teraz moje kawałki w sumie działają, zostało tylko dostawić kropki nad i i kreseczki nad t. Zanim zacznę domagać się włączenia, chciałbym poznać jakieś reakcje (gdybym coś ominął), i chciałbym też odpowiedzieć, żeby ludzie zrozumieli, co robię.

Zacznijmy od powiązañ.

• Mam łatę, którą się opiekuję (kexec), pozwalającą uruchamiać linuksa i inne systemy operacyjne z linuksa. Ta łatka nie jest specyficzna dla x86 (aczkolwiek używa kodu specyficznego dla architektury). Na wejściu bierze plik ELF.
• Pracuję nad LinuxBIOS, a LinuxBIOS na wejściu bierze jądro sformatowane jako ELF.
• Potrzebuję regularnie butować się z sieci przez etherboot, a jądro w postaci ELF może być używane oryginalnie. bzImage wymaga pewnej pomocy.
• Niefajnie jest gdy, zmieniając platformy alpha/ia32/xxx, trzeba całkowicie zmieniać narzędzia potrzebne do uruchomienia jądra linuksa.
• Mam łatę, dzięki której jądro linuksa dla x86 jest ELF i butowalne.

Co to jest butowalne jądro w formacie ELF.

• Lista segmentów, która mówi żeby załadować ten kawałek pliku pod ten fizyczny adres.
• 32-bitowy punkt wejścia. (64-bitowy na 64-bitowych platformach).
• Kod w tym punkcie pozwalający odpytywać firmware/BIOS, w celu uzyskania informacji, których potrzebuje jądro.

Następnym krokiem jest integracja wszystkich moich kawałków i zrobienie porządków, mam jednak funkcjonujący kod dla tego wszystkiego.

Butowalne jądro x86 ELF: ftp://download.lnxi.com/pub/src/linux-kernel-patches/linux-2.4.17.elf_bootable.diff

Łatka pozwalająca butować dowolne statyczne wykonywalne pliki ELF: ftp://download.lnxi.com/pub/src/linux-kernel-patches/linux-2.4.17.eb-kexec-apic-lb-mtd2.diff

Poprawka jądra, która wykonuje poprawne wyłączenie SMP, pozwalająca robić kexec na jądrach SMP ftp://download.lnxi.com/pub/src/linux-kernel-patches/linux-2.4.17.eb-apic-lb-mtd2.diff

Łata na jądro implementująca minimalną obsługę LinuxBIOS. ftp://download.lnxi.com/pub/src/linux-kernel-patches/linux-2.4.18-pre7.linuxbios.diff

Oddzielny program wykonywalny adaptujący istniejące bzImage dla x86 tak, by było butowalnym jądrem ELF. ftp://download.lnxi.com/pub/src/mkelfImage/mkelfImage-1.12.tar.gz

Pierwsza wstępna wersja specyfikacji opisująca szczegółowo to, jak jest interpretowany obraz ELF oraz rozszerzenia, które mogą być dodane, by nazwa bootloadera, jego wersja i podobne interesujące rzeczy, ale z punktu widzenia funkcjonalności zupełnie niepotrzebne informacje, były przekazywane ładowanemu obrazowi i by bootloader mógł poznać informacje podobnego rodzaju o ładowanym wykonywalnym ELF. ftp://download.lnxi.com/pub/src/linuxbios/specifications/draft1_elf_boot_proposal.txt

To chyba jest coś warte, bo, jak do tej pory, uzyskałem pozytywny odzew od społeczności Etherboot i LinuxBIOS. Etherboot i memtest86 zostały już zmodyfikowane tak, by były butowalne z ELF. Trwa właśnie praca nad Plan9.

Moja praca nad kexec jest bezpośrednią konkurencją dla two kernel monte, bootimage, lobos. Używałem go produkcyjnie przez około rok i nie miałem prawdziwych problemów. Największy kłopot jaki miałem, to kłopot z jądrem, które nie zamykało poprawnie urządzeñ.

Na szybko, wyłączanie urządzeñ jest obsługiwane trywialnie przez odmontowanie systemów plików, kładzenie urządzeñ ethernet i wołanie reboot. Tak naprawdę powinienem wołać procedury module_exit, ale one potrzebują trochę zmian zanim będę mógł ich używać w trakcie ponownego startu. W szczególności wołanie module_exit, które czyści pm_power_off to zupełnie nie to.

Co więcej, powinno to działać w większości przypadków z załadowanym obrazem ELF, który startuje używając usług BIOS/firmware. Przywracanie stanu urządzeñ do stanu zapamiętanego w firmware jest kiepsko zdefiniowanym problemem. Jednak normalne wołania firmware, które pytają o rozmiar pamięci, czy obsługę przerwañ powinny działać dobrze.

Więcej o etherboot można znaleźć pod adresem: http://www.etherboot.org

Więcej LinuxBIOS można znaleźć pod adresem: http://www.linuxbios.org

oprogramowanie LVM2 jest gotowe do testowania beta.

To jest całkowita zmiana implementacji istniejącego systemu LVM, dotyczy zarówno sterownika jak i narzędzi z przestrzeni użytkownika.

Zachęcamy do wypróbowania i przysyłania wyników testów, poprawek, próśb związanych z rozwojem na listy linux-lvm@sistina.com i lvm-devel@sistina.com.

Nowy sterownik w jądrze (znany jako ,,device-mapper'') obsługuje zarządzanie woluminami w ogóle, nie jest już specyficzny dla LVM Linuksa. Z tego powodu jest oddzielnym od LVM2 pakietem, który należy ściągnąć i zainstalować przed zbudowaniem LVM2.

ftp://ftp.sistina.com/pub/LVM2/device-mapper/device-mapper-beta1.tgz

Narzędzia użytkownika są dostępne tu:

ftp://ftp.sistina.com/pub/LVM2/tools/LVM2.0-beta1.tgz

Ta wersja nie wspiera snapshotów ani pvmove. Te elementy trafią do kolejnej wersji beta, mamy nadzieję, że w ciągu dwóch tygodni.

To jest oprogramowanie w wersji Beta, co oznacza, że *nie* jest przeznaczone na systemy produkcyjne. Jeśli to konieczne, to zachowaj kopie zapasowe swoich danych i metadanych LVM (/etc/lvmconf/*).

Oprogramowanie LVM2 nie używa już szczególnego sterownika, który był użyteczny tylko w jednym celu. Używa raczej innego, sterwonika zwanego 'device-mapper', który implementuje ogólnie usługę zarządzania woluminami dla jądra Linux, przez obsługę dowolnego mapowania zakresu adresów na odpowiednie urządzenia blokowe. Ponieważ jest to bardziej ogólny serwis niż aplikacja jądra, jest otwarty, by można go było używać z wieloma implementacjami LVM (na przykład możnaby przeportować EVMS tak, by tego używało :-)

Sterownik device-mapper jest na GPL, a nasza wersja Beta1 ze środy, która uwzględnia także narzędzia LVM2, obsługuje jądra 2.4. Naszym celem jest zintegrowanie go z aktualnym jądrem, implementujemy więc teraz zmiany (interfejs bio) konieczne, by pracował z 2.5. Wypuściliśmy bibliotekę device-mappera (implementację podstawowego API device-mappera), która jest na LGPL.

Narzędzia LVM2 mają bibliotekę z procedurami do, na przykład, dostępu do biblioteki device-mappera, obslugi metadanych LVM (VGDA), obsługi różnych formatów metadanych; oferuje też obsługę plików konfiguracyjnych i też jest na LGPL. Same narzędzia (vgcreate, lvcreate, ...) są na GPL.