Na luzie > Rozmowy w toku
Ź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: ---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
--- Koniec kodu ---
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:
--- Cytat: sir_lucjan w Maj 07, 2015, 12:30:34 ---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.
--- Koniec cytatu ---
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.
--- Cytat: sir_lucjan w Maj 07, 2015, 12:30:34 ---Raczej nie będę próbował naprawić błędu, skoro jest to zadanie twórcy patcha BFS.
--- Koniec cytatu ---
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).
Nawigacja
[#] Następna strona
Idź do wersji pełnej