Źródła udostępnione w Githubie - dyskusja

[pavbaranov]

Poniższy tekst i dalsza dyskusja są związane z informacją Lucka, która zawarta jest tu: http://www.archlike.darmowefora.pl/index.php/topic,303.msg1499.html#msg1499

Kod: [Zaznacz]

zgrep -i PILEDRIVER /proc/config.gz && zgrep -i SMT /proc/config.gz && dmesg | grep scheduler && dmesg | grep UKSM && uname -a
CONFIG_MPILEDRIVER=y
CONFIG_SCHED_SMT=y
CONFIG_SMT_NICE=y
# CONFIG_I2C_ISMT is not set
[    1.638146] io scheduler noop registered
[    1.638184] io scheduler cfq registered
[    1.638221] io scheduler bfq registered (default)
[    1.638221] BFQ I/O-scheduler version: v7r7
[    1.978671] BFS CPU scheduler v0.462 by Con Kolivas.
[    1.902378] UKSM: relative memcmp_cost = 256 hash=3916718731 cmp_ret=0.
Linux evo 4.0.2-0.2-uksm-ck #1 SMP PREEMPT Wed May 6 22:40:13 CEST 2015 x86_64 GNU/Linux
Na AMD buduje. Zdaje się, że problem leży gdzieś na linii BFS - linux 4.x - Intel.

EDIT:
Zdaje się, że Lucjan znalazł winnego - to niepoprawne działanie wirtualizacji i BFS.

[sir_lucjan]

Problem z Intelem prawdopodobnie istnieje, jednak nie dotyczy on błędów budowania, o których wspominałem. Tak jak napisał Paweł, znalazł się winowajca - jeśli chcemy używać BFS z kernelem 4.0.2, to mamy dwie możliwości:

- wyłączyć całkowicie wirtualizację

- poczekać, aż Con wyda poprawkę - bo to jego patch powoduje problemy

Powiadomiłem Cona o zaistniałej sytuacji - zobaczymy, jak (i czy w ogóle) zareaguje

[pavbaranov]

Gwoli ścisłości:
- lektura wątku dotyczącego BFS/CK na BBS Archa wykazuje, że "problem z Intelem" wraz z 4.0.2 prawdopodobnie został, przynajmniej częściowo, zażegnany; osoby, które wcześniej zgłaszały problemy - obecnie ich nie mają,
- problem dotyczy(-ł) jedynie niektórych modeli procesorów Intela,
- wydaje się, że problem powstawał wyłącznie przy łącznym zaistnieniu następujących warunków:
-- określony procesor Intela,
-- patch BFS 462 bez łatek z wersji test,
-- ograniczenie NUMA jest ustanowione,
-- kernel został zoptymalizowany tzw. patchem graysky'ego na GCC optymalizującym go pod określony procesor.

Problem z budową przy wirtualizacji i BFS 462 być może jest do opanowania sedem (w zasadzie chodzi o niewłaściwe linkowanie). Pytanie wyłącznie, czy Luckowi bądź mi chce się bawić w naprawianie tego błędu, skoro prawdopodobnie Con, Alfred, czy Oleksandr naprawią to wkrótce.

[sir_lucjan]

Prawdopodobnie tak samo jak graysky zrezygnuję z ustawienia: "_NUMAdisable=y" - czekam na jego decyzję i zamierzam się do niej dostosować. Zastanawiam się tylko na tym, czy zrobić to we wszystkich PKGBUILD-ach czy tylko w tych, które zawierają patch BFS.

Raczej nie będę próbował naprawić błędu, skoro jest to zadanie twórcy patcha BFS.

[pavbaranov]

Prawdopodobnie tak samo jak graysky zrezygnuję z ustawienia: "_NUMAdisable=y" - czekam na jego decyzję i zamierzam się do niej dostosować. Zastanawiam się tylko na tym, czy zrobić to we wszystkich PKGBUILD-ach czy tylko w tych, które zawierają patch BFS.

Wydaje się, że włączenie NUMA (NUMAdisable=y) niekoniecznie musi być w ogóle dobrym pomysłem, zwłaszcza, że dotyczy to obecnie wyłącznie części procesorów Intela (dokładnie nawet nie wiadomo których), przy czym - z wydania na wydanie 4 wersji kernela - lista ta ulega zmianie. Bardziej właściwym chyba jest "lepsze" opisanie tego parametru w PKGBUILDzie, jak również zwrócenie na to uwagi w odpowiednich wpisach np. na AUR, czy w githubie.
Zwróć też uwagę, że problem wydaje się być przemijalny (i przemijający).
Jak się wydaje, należałoby również wyeliminować wpływ patcha graysky'ego na zaistniałą sytuację. Wszystkie znane mi zgłoszenia o błędach (całkiem poważnych: kernel panic) zaistniały bowiem na "zoptymalizowanych" kernelach. Te same osoby nie przeprowadzały testów na generycznych kernelach.

Raczej nie będę próbował naprawić błędu, skoro jest to zadanie twórcy patcha BFS.

Cóż, a to - z całym szacunkiem Lucek - jest iście "archowe" podejście. Można coś zmienić, wiemy jak (albo nie, bo nad tym się również należy zastanowić), ale nie zrobimy tego, bo mityczny "upstream" tego nie uczynił.
Zgoda - to jest powinność twórcy patcha, by zrobić go prawidłowo.
Brak zgody jednak, na to, by wiedząc jakie jest rozwiązanie nie stosować go, bo "upstream" za przeproszeniem spieprzył sprawę.
I znów dochodzę do wniosku, że Arch to nie dystrybucja, a jedynie sposób tworzenia paczek (PKGBUILDy) pochodzących najczęściej z obcych źródeł wraz z menedżerem umożliwiających ich instalowanie. Jeśli "upstream" nawalił, nie zrobi się nic, by w ramach dystrybucji zostało to naprawione (w przeciwieństwie do np. Fedory, Debiana, czy nawet *buntu).

[sir_lucjan]

Owszem, można coś zmienić, można coś naprawić - tego nie neguję. Problemem jest kwestia czasu (lub dokładniej jego braku). Jeśli ktoś zechce pomóc mi w tej
kwestii, to być może problem uda się rozwiązać. Jest to nawet wielce prawdopodobne. Czasowe rozwiązanie problemu jest bardzo słuszne - nie zaprzeczę, jednak zrobienie tego w pojedynkę na chwilę obecną jest nieco nierealne. Zatem jak znajdziesz czas, możesz pomóc w rozwiązaniu problemu - z pewnością wiele to ułatwi. Dotyczy to także innych użytkowników - im nas więcej, tym lepiej! Samodzielnie rozwiązanie problemu w tym momencie przekracza nieco moje możliwości "czasowe" - nie mam aż tyle wolnego czasu, by nad tym przysiedzieć. Nie jest to spowodowane moim lenistwem czy złośliwością.

Uściślijmy - chodziło Ci o to, że NUMAdisable to zły pomysł czy usunięcie tego wpisu jest niezbyt dobrym wyjściem?

[pavbaranov]

Owszem, można coś zmienić, można coś naprawić - tego nie neguję. Problemem jest kwestia czasu (lub dokładniej jego braku). (...) Nie jest to spowodowane moim lenistwem czy złośliwością.

Lucek - odległy jestem zarzucania Ci lenistwa, czy złośliwości. Ot, po prostu Twoje słowa nasunęły mi ogólną refleksję na temat paczek w Archu.

Uściślijmy - chodziło Ci o to, że NUMAdisable to zły pomysł czy usunięcie tego wpisu jest niezbyt dobrym wyjściem?

Pozostaw tak jak było dotychczas. Wszystko - jak na razie - wskazuje na to, że jest to lepsze "ogólnie" rozwiązanie, a wyłącznie obecnie są z tym jakieś problemy, które dotyczą niewiadomego rodzaju procesorów, w dodatku wyłącznie jednego producenta. Nadto ilość nieobsługiwanych procesorów zmienia się w czasie. Nie wiemy również, czy problem dotyczy wyłącznie optymalizowanych kerneli, czy też również generic. IMO lepiej jest dać PKGBUILD w dotychczasowej wersji (albowiem jest on OTB do zastosowania przez wszystkich posiadaczy platform AMD oraz części Intela i prawdopodobnie również wszystkich posiadaczy procesorów innych niż wymienione), a jedynie w PKGBUILDzie, bądź w jakiejś notce na AUR czy gicie opisać, że:
- użytkownicy niektórych procesorów Intela być może muszą wyłączyć NUMAdisable,
- -"- być może muszą zbudować kernel generyczny,
- wszyscy - w przypadku 4.0.2 - muszą wyłączyć wirtualizację (albo pozostać na dotychczasowym kernelu).
Wydaje się, że taka informacja jest jasna i czytelna i umożliwia odpowiednie zbudowanie kernela, który będzie pracować. Wraz z 4.0.2 - jak wynika z wątku w BBS coraz więcej procesorów Intela jest obsługiwanych. Nie wiadomo zatem nawet, czy nie jest to jakiś błąd upstreamowy, który po prostu wraz z BFSem się ujawnia. Zwróć uwagę, że pod 4.0.2 Con nie zrobił nowego BFS, a problem - przynajmniej w części - został zażegnany. Cóż, budując kernel z AUR każdy musi mieć świadomość tego co robi.
W AUR myślę, że dalej - tak jak robisz dotychczas - 3.19.x. Ta wersja ma być wspierana aż do czasu, kiedy problemy z 4.x (upstreamowe) zostaną wyeliminowane. Jednocześnie, kolejne wersje 3.19 są wzbogacane o wszelkie poprawki związane z bezpieczeństwem, są usuwane te same błędy tkwiące we wspólnym kodzie 3.x i 4.x itd.

[sir_lucjan]

Postanowiłem przyjąć takie rozwiązania.

Kernele w AUR:

- linux-bfq - wersja 4.0. BFQ nie sprawia większych problemów. Jeśli pojawią się zgłoszenia o problemach podobnych do tych w linux-ck obniżę numer wersji do 3.19.

- linux-bfs, linux-bridge-pl, linux-uksm-ck - wersja 3.19.X. Dopóki problemy z patchem BFS nie zostaną zażegnane, nie podbiję numeru wersji. Zwłaszcza, że wersja 4.0.2 nie buduje się poprawnie na dostarczanym configu (musiałbym wyłączyć xen a to kiepski pomysł).

- linux-uksm - wersja 3.19.X. Wersja 4.0 (4.0, 4.0.1, 4.0.2) budują poprawnie, jednak sam patch jest w wersji beta i dopiero kiedy twórca wyda oficjalną wersję, podbiję w AUR. Chyba, że wersja oficjalna nie ukaże się do czasu uzyskania przez 3.19 statusu EOL - wtedy będę zmuszony podbić numer wersji.

Kernele w Githubie:

Sekcja "aur"

- linux-bfq, linux-uksm - wersja 4.0.2. Buduje  prawidłowo.

- linux-bfs, linux-bridge-pl, linux-uksm-ck - wersja 4.0.1 - z racji tego, że 4.0.2 nie buduje się na dostarczanym configu - jak wspominałem, wycięcie Xen w domyślnym configu to kiepski pomysł.

Sekcja "kernelrc"

Póki co (na dzień 7 maja 2015) status podobny jak w sekcji "aur".

[pavbaranov]

Postanowiłem przyjąć takie rozwiązania.

To na Twoim miejscu, napisałbym jeszcze 1-2 zdania w odpowiednich miejscach, dlaczego przyjąłeś takie rozwiązania

Kernele w Githubie:
- linux-bfs, linux-bridge-pl, linux-uksm-ck - wersja 4.0.1 - z racji tego, że 4.0.2 nie buduje się na dostarczanym configu - jak wspominałem, wycięcie Xen w domyślnym configu to kiepski pomysł.

Dopisałbym, że wersja 4.0.2 jest możliwa do zbudowania, ale z wyłączoną wirtualizacją (jej wyłączenie, dla osób, które nie korzystają z wirtualizacji wcale nie jest kiepskim pomysłem, ale wyłącznie przy budowie własnego kernela).
I niech ludzie robią co chcą.

[sir_lucjan]

I tu jest problem - dasz starszy kernel, będzie  gadanina, że nie ma nowego. Dasz nowy, będzie marudzenie, że nie buduje a wirtualizacja jest akurat potrzebna. Nie dogodzisz każdemu

[pavbaranov]

Dlatego napisałem tylko i wyłącznie pod Twoje założenia, abyś dopisał o tym błędzie z wirtualizacją. Wg Twoich założeń dajesz 4.0.1. Macherów od zmiany PKGBUILDa na 4.0.2 znajdziesz bez liku bo to prosta operacja. Dlatego napisz, że w przypadku 4.0.2 kernel nie buduje się, gdy ma wkompilowaną wirtualizację. Każdy sobie wybierze, czy potrzebuje wirtualizacji i zostaje na 4.0.1, czy woli 4.0.2 i nie jest mu ona potrzebna.

[sir_lucjan]

W wolnej chwili postaram się zamieścić.

[sir_lucjan]

Con poinformował mnie, że udostępnił patch, który rozwiązuje problem. Wstępne próby to potwierdzają, przeprowadzę jeszcze kilka i udostępnię PKGBUILD-y z poprawkami.

[sir_lucjan]

Gotowe.