# Kernel wczoraj i dzis a takze jutro w kontekscie desktopu

## fallow

Hej.

Po kilkuletniej przerwie spowodowanej brakiem czasu (praca, praca, praca) postanowilem na dobre powrocic do uzytkowania Linuxa.

Kiedy odchodzilem  - w zasadzie jadro 2.6 bylo juz na dobre "zadomowione" i wszystko wskazywalo na to, ze nacisk na support uzytkownika domowego/destkopowego jest coraz wiekszy. Con Kolivas poprzez Staircase CPU Scheduler oraz wiele roznego rodzaju testow udowodnilo istnienie lekcewazonego przez developerow kernela problem interaktywnosci/responsywnosci CPU Schedulera O(1) napisanego przez Ingo Molnara.

Od dawna wiec uzytkownicy Linuxa posilkowali sie roznego rodzaju latkami zaczynajac od love-sources konczac idac przez nitro a konczac na zen-sources. Mamy tez epizod obecnych na polskim dziale vivid-sources. Oczywiscie najczesciej wszystkie te patchsety wykorzystywaly latke Cona Kolivas'a - Staircase.

Con od dawna poprawial kod CPU Schedulera w jadrze by zwiekszac jego interaktywnosc pod katem systemu destkopowego a czesc z jego rozwiazan zostala zmergowana do schedulera O(1). Con widzial jednak problem dalej - tak jak i wielu uzytkownikow. Problem mianowicie w tym, ze CPU Scheduler Linuxa jest zbyt kompleksowy a jak wiadomo nie od dzisiaj najbardziej niezawodne sa rozwiazania proste. W przypadku CPU Schedulera za prostota kodu przemawiaja oczywiscie latencje. Im prostrzy kod - tym mniejsze latencje a co za tym idzie wieksza responsowynosc. Oczywiscie nie mozna tez popadac w skrajnosc, algorymt nie moze byc zbyt prosty. Musi byc sensowny. 

W tamtych czasach CPU Scheduler Windowsa skonfigurowany pod desktop byl srednio ~11ms sybszy. Slabosc O(1) byla widoczna glownie przy wiekszym obciazeniu kiedy np. puszczalismy w tle kompilacje, kopiowalismy cos, i zwalnialo np. przelaczaniem tabow w przegladarce www.

Staircase generalnie likwidowal te problemy w znaczacym stopniu dlatego zyskiwal coraz wieksza popularnosc. (Nie liczac uzytkownikow ktorzy przesiadali sie na niego by uciec od mainstreamu jakim jest "vanilla"). Staircase mial jedna wade - nie byl tak skuteczny dla maszym wieloprocesorowych jak O(1). Oczywiscie nie mowa tutaj o dual czy quad-core'ach tylko np. maszynach ze 128 czy 256 procesorami.

W Windowsie od dawna sa dostepny presety "Desktop" i "Server" - nie wiem czy to tylko tuning czy tez zmieniane sa czesci CPU Schedulera w run-timie, tak czy siak jak byk jest takie rozwiazanie.

Na LKML pojawil sie swego czasu patch PlugSched umozliwiajacy implementacje wielu CPU Schedulerow jednoczesnie podobnie jak to dzisiaj ma miejsce z IO Schedulerami ktore mozemy sobie dowolnie zmieniac.

Logicznym krokiem wydawalo sie wlaczenie do vanilli CPU Schedulera Con'a jako rozwiazanie dla Desktopu. Con robil wszystko "co przykazano" przez maintainerow kernela aby tak sie wlasnie stalo. Niestety problem sukcesywnie byl lekcewazony i pomijany (mimo wielu testow oraz opracowan przez niezalezne firmy i instytucje, trzeba zaznaczyc ze nie byly to testy na forum lecz powazne juz opracowania).

W koncu ktos zaproponowal, ze Ingo Molnar lepiej bedzie utrzymywal swoj wlasny CPU Scheduler niz kod kogos innego, wiec lepiej by usprawnil obecny pod tym katem. Ktos moze powiedziec, ze to logiczna decyzja inny, ze nie - tak czy siak stalo sie i taka wlasnie decyzja zapadla.

Con zdecydowal sie wiec odejsc i nie rozwijac juz Staircase'a a Ingo napisal swoj nowy CFS CPU Scheduler zastepujacy stary O(1).

Niestety...obecnie mamy w jadrze CFS ktory rozrosl sie do niebotycznie wielkich rozmiarow - kto chce niech porowna z wersja O(1). To po prostu jest wielka mega kompleksowa krowa. Dodatkowo jest to projekt znacznie mniej dojrzaly niz Staircase. Dziala troche lepiej niz O(1). Jednak to tylko "troche". 

Jak dla mnie jest to swietne rozwiazanie dla wielkich wieloprocesorowych systemow i serverow jednak nie sprawdza sie po prostu na desktopie.

Con widzac co sie dzieje, postanowil ze wywali cala kompleksowosc i zlozonosc CFS - upraszczajac w drastyczny sposob kod CPU Schedulera. W ten sposob powstal BFS - Brain Fuck Scheduler, nastepca Staircase'a. Nazwa oczywiscie nie jest przypadkowo gdyz wlasnie to pewnie robi z mozgami aktualnych maintainerow. W glowie nie miesci sie jak mozna zrezygnowac z tak "pieknie kompleksowego" rozwiazania na rzecz prostego.

Efekty sa oczywiste, kto chce sprobowac niech zainstaluje sobie jadro patchowane latkami -CK. Bedzie mial wtedy gwarancje, ze wszystko bedzie w porzadku. Jak wiadomo wszystkie wieksze patchsety zawsze maja jakies wady, czesto maintainerzy ida na ilosc a nie jakosc a czasem po prostu nie wiedza w jaki sposob po prostu poprawiac rejecty wiec poprawiaja je "aby sie kompilowalo" a jak dziala to juz inna sprawa  :Smile: ) 

Prawdopodobnie BFS nigdy nie trafi do jadra gdyz Linus i spolka maja wizje "jednego" CPU Schedulera na kazda sytuacje. Podobnie chca nam zrobic z IO Schedulerami. Ma powstac "jeden do wszystkiego". Kto uzywal "Deadline'a" oraz "CFQ" dobrze wie, ze zrobienie z nich jednego - zrobi nam po prostu jeden sredni IO Scheduler ktory nie bedzie mial zalet ani jednego ani drugiego, ani tez ich wad. Moim zdaniem zdecydowanie lepiej moc sobie wybrac na server "Deadline" a na desktop "CFQ" uzyskujac optymalna wydajnosc w kazdej z tych sytuacji.

Mamy wiec wizje rozwijania CFS'a ktory nawet z dosc duzym potencjalem nigdy nie osiagnie takiej sprawnosci na desktopie jak rozwiazanie mniejsze i prostrze. 

Kiedy zainstalowalem sobie vaniliowy kernel 2.6.32 oraz 2.6.33-rc7 musze przyznac, ze CFS sprawuje sie delece od tego czego oczekuje po desktopie w kontekscie interaktywnosci systemu. Sam jestem programista, programuje gry w branzy Game Industry i lubie ladne, efekciarskie desktopy, korzystam z composite i coz, CFS po prostu sprawuje sie ponizej oczekiwan. BFS daje mi responsywnosc chyba nawet lepsza niz obecna na Windowsie 7.

W Sieci jest kilka testow CFS vs BFS - zachecam do pogooglowania.

Zachecam do dyskusji w watku kazdego kto w jakikolwiek sposob pragnie sie zainteresowac, badz juz interesuje sie tematem badz ma jakiekolwiek odczucia  :Smile: )

---

Druga sprawa jaka chcialbym poruszyc jest Reiser4. Wiadomo co stalo sie z Hansem Reiserem, zostal aresztowany i skazany za zabojstwo swojej zony. Reiser4 nie byl rozwijany przez okolo rok, az w koncu programisci z Namesys rozwijaja go dalej a Linus powiedzial, ze jezeli prace beda trwaly dalej ma on szane pojawi sie w jadrze w 2010 roku. Do jadra wszedl jednak znacznie mniej dojrzaly twor - BTRFS. System plikow oparty takze jak Reiser4 na "B-Tree". Po ostatnich ulepszeniach juz bardzo zblizony wydajnosciowo do Reisera4. Oferujacy takze wiele nowych mozliwosci. 

Hans Reiser byl w srodowisku uwazany za swego rodzaju "bufona" ktory zawsze chwalil sie tym, o ile "madrzejsi" sa jego programisci niz developerzy kernela. Nigdy nie byl w srodowisku lubiany i wiadomo - Reiser4 glownie z tego powodu nie trafil do Linuxa. Reiser4 jest tez w duzym stopniu przeciw obecnej koncepcji VFS Linuxa, nadpisujac wiele rzeczy samemu. Aktualnie Namesys ma to zmienic.

Wlaczenie BTRFS do jadra w tak wczesnym etapie rozwoju pozwili oczywiscie na jego wieksze destowanie i szybszy rozwoj, wiadomo tez ze srodowisku oczekuje juz systemu plikow nastepnej generacji, kiedys uwazano ze bedzie nim wlasnie Reiser4 jednak dzisiaj wszystko wskazuje na to, ze przy obecnym tempie rozwoju oraz za sprawa dobrego dogadywania sie tworcow BTRFS z developerami kernela - zostanie nim wlasnie BTRFS.

Co o tym myslicie ?  :Smile: 

Sam postawil sobie system na BTRFS (oczywiscie posiadajac kopie bezpieczenstwa) i od kilku dni wszystko dziala bez zarzutu. Dla przykladu skopiowanie zrodel 2.6.32 do innego katalogu na mojej maszynie trwa odpowiednio - 41s na Reiser4, 47s na BTRFS, 1m46s na ReiserFS 3.6 oraz 2m48s na EXT4. Dla mnie to wazne bo ta operacje wykonuje chyba najczesciej  :Smile: 

PS. Swego czasu eksperymentowano tez z implementacja algorytmow genetycznych w CPU Schedulera (Zaphod), ja tez zrobilem kiedys proste rozszerzenie dla O(1) na potrzeby Love-Sources jednak chyba wszyscy sa zgodni ze CPU Scheduler powinien na desktopie zachowywac sie calkowicie przewidywalnie - wtedy osiagnie najwieksza interatkwynosc. Taka droga jak implementacje algorytmow genetycznych bylaby ciekawa raczej dla serwerow.

---

przepraszam za brak gramatyki, jak zawsze przelewalem po prostu strumien z glowy

---

----------

## SlashBeast

BFS od 3xx jest bardzo zacny, mam go na praktycznie juz na kazdej maszynie desktopowej/laptopowej i na 2 serwerach - efekt pod wielkim obciazeniem jest wyrazny - naprawde daje kopa.

O reiser4 rozmawiac nie bede, moge na niego nawrzucac tyle, co na paludisa, po prostu ... nie.

----------

## Poe

Toś się rozpisał  :Wink: 

jednak trudno odmówić Ci racji. Pamiętam, jak chcialo mi się jeszcze bawić w łatanie kernela różnymi patchami, czy pomoc przy vivid-sources. I nie mogę do tej pory przeboleć, że Con zaprzestał rozwijania Staircase. o Brain Fuckerze nie słyszałem, ale z pewnością z czasem przetestuję, jeżeli to coś w rodzaju kontynuacji staircase. Choć z tym schedulerem na desktopie miałem problemy. Być może wynikało to z jakiś moich błędów w konfiguracji systemu, jednak, pamiętam, że chyba dwóch czy nawet trzech wersji Staircase nie byłem w stanie używać, gdyż system ciął niemiłosiernie przy bardzo małym obciążeniu (X'y + przeglądarka + muzyczka) i na pewno nie było to sugestywne odczucie. Jednak ostatnie wersje działały absolutnie bez zarzutu. 

W przypadku genetycznego, różnicy w codziennym zastosowaniu nie widziałem.

Co do pomysłów głównych devów kernelowych, szlag człowieka trafia. Trochę to wygląda tak, jakby chcieli stworzyć miejski samochód o wymiarach 2x2, palący 2l/100km, o 300 KM z silnikiem V8, mieszczący 6 - osobową rodzinę z psem, dużą przestrzenią bagażową, napędem 4x4 i może jeszcze potrafiący pływać jak amfibia. 

Generalnie, jest to bardzo sprzeczne z ogólną wizją linuksa czy uniksów - czyli jedno narzędzie do konkretnego rozwiązania. ma to swoje wady, jak zbytnie rozdrobnienie pewnych części systemu, jednak optymalnie dobierając "dawki" można uzyskać pożądany efekt. Nie wiem w czym problem. Con dostałby swoją gałąź, dopasowywałby swojego scheda do vanillii, kto by chciał, ot by sobie włączył, a kto nie to by wyłączył i tyle. dodatkowe kilkadziesiąt kilobajtów na patch w kernelu ważącym niemal 50mb nic by nie zmieniło, a użytkownik, dla którego jest tworzony system tylko by zyskał...

co do FS'ów... od zawsze używam reiserfs, bez ani jednej wpadki, utraty danych czy czegoś podobnego, nawet przy resetach, utracie prądu czy tego typu zdarzeniach. r4 mam na /usr/portage i działa również dobrze. niestety, nie mam zbytnio miejsca na dysku, żeby testować z innymi fs'ami, aczkolwiek, zaintrygował mnie projekt BTRFS, ale chyba nie będzie mi dane go sprawdzić.

----------

## BeteNoire

Czy "skopiowanie zrodel 2.6.32 do innego katalogu na mojej maszynie" może być miarodajnym testem? To operacja, której nigdy jeszcze nie wykonywałem  :Razz:  I nie sądzę, by przerzucanie kupy plików z miejsca w miejsce obok było funkcją desktopu.

Pamiętam gdy parę lat temu wybierałem ostateczne fs dla swoich partycji to patrzyłem na benchmarki i zestawienia wielu różnych operacji na plikach i katalogach. Przykładowo pamiętam, że dla dużych partycji z dużymi plikami sprawował sę najlepiej i najstabilniej xfs. Z kolei dla partycji systemowych z wieloma malutkimi pliczkami był to rfs. Skonfrontowałem to z własnymi, drobnymi testami i wyszło podobnie.

W r4 aka murderfs nigdy nie uwierzyłem, bo co to za fs, którego twórca zabił swoją żonę  :Razz:  Nie no, żart, ale tego nie ma nawet w kernelu, a co mnie obchodzą zewnętrzne patche, z którymi mogą być problemy przy updatach? Ja nie jestem testerem a użytkownikiem, jakieś wątpliwe zyski wydajności mało mnie obchodzą, bo większość pojedynczych testów lubi się uśrednić, gdy je powtórzyć wielokrotnie w różnych warunkach. Samo babranie się w naprawianie błędów przynosi więcej strat czasu i emocji niż wydajności.

----------

## galimedes

Jeśli chodzi o schedulery windowsowe to kiedyś w pracy badaliśmy działanie IIS na różnych wersjach Win2k8 i różnych serwerach od starych maszyn jedno procesorowych do najlepszych maszyn dostępnych w naszym departamencie i z wykorzystaniem vs do wygenerowania symulowanego ruchu wysoce przekraczającego możliwość maszyny około 1mln odwiedzin na minutę na każdy cpu. Wnioski okazały się dosyć zaskakujące ponieważ na maszynach posiadających 1-16 cpu przy obciążeniu iis okazało się że wersje datacenter i podobne czyli przeznaczone dla serwerów powyżej 32 procesorów wypadały znacznie gorzej niż można było oczekiwać po optymalizacji obsługi połączeń jaki IO i zarządzania wątkami z racji tego doszliśmy do wniosku iż każda wersja ma osobny scheduler i ściśle przeznaczony do mocy sprzętu. 

A więc wracając do tego co napisałeś kiedyś łatka CK faktycznie robiła ogromną furorę natomiast na sprawę nowego schedulera trzeba spojrzeć szerzej mianowicie na panujące trendy w technologiach i algorytmach gdzie duży nacisk kładziony jest na generyczny i uniwersalny kod który jak wiemy zawsze posiada pewne wady mimo to wzorce opisujące je są bardzo chętnie absorbowane do wszelakich projektów i niestety odbija się to czkawką tam gdzie potrzebna jest wydajność. Niestety Ingo i spółka zatracili się w swoich wizjach co powoduje powstanie kobyły która umie wszystko ale jest koszmarnie wolna, z racji tego przychodzą mi na myśl słowa kolesia z M$ że jest to "opportunity for business" gdzie można zrobić coś na swoją miarę i raczej się to nie zmieni z tego co pamiętam Ingo jest strasznie upartym człowiekiem jeśli chodzi o ten temat. Fallow sam powinieneś zauważyć iż wcześniej większość gier aplikacji pisana była w MFC, a dziś fakt też się go wykorzystuje jednak cześć pisze się w językach znacznie wyższego poziomu np c# co daję dobry przykład że "my" developerzy i architekci ulegamy presji aby wytwarzać szybciej stąd mamy tą nieszczęsną modę na generyki  :Sad:  tutaj nie tylko należy patrzeć na jądro następnym przykładem jest xorg. Jeden z moich wykładowców kiedyś powiedział fajną definicję systemu że jest to byt który ma zajmować jak najmniej zasobów i działać jak najszybciej dziś niestety systemy stają się kobyłami które nie są dedykowane ale starają się dostosować do maszyny.

[OT]

Widzę że nie tylko ja postanowiłem w ostatnim okresie wrócić na stare śmieci  :Smile: 

[/OT]

----------

## fallow

 *SlashBeast wrote:*   

> BFS od 3xx jest bardzo zacny, mam go na praktycznie juz na kazdej maszynie desktopowej/laptopowej i na 2 serwerach - efekt pod wielkim obciazeniem jest wyrazny - naprawde daje kopa.
> 
> O reiser4 rozmawiac nie bede, moge na niego nawrzucac tyle, co na paludisa, po prostu ... nie.

 

No...ale wlasnie po to jest ten watek by dzieli sie opiniami, i tymi pro i tymi anty. Ja chetnie poczytam i takie i takie  :Smile: 

Przez kilka miesiecy kilka lat temu uzywalem Reisera4 na swoim desktopie i jedynym problemem na jaki sie natknalem bylo bardzo duze obciazenie CPU. Zwlaszcza w stosunku do ext3 i najmniej obciazajacego procek jfs'a. Obecnie po kilku latach desktopowe maszyny sa coraz szybsze a CFQ coraz lepszy wiec roznice w obciazeniu procesora przez rozne systemy plikow staje sie coraz mniejsze. Obecnie mysle, ze ten problem sie juz rozmywa.

@Poe: Faktycznie w pierwszych etapach rozwoju Staircase'a bylo tak jak opisujesz. Czasem pomagalo puszczenie Xow na mniejszym priorytecie jednak nie zawsze. Pozniej bylo juz lepiej a kiedy Con staral sie o wejscie Staircase'a do vanilli problemu juz nie bylo. Obecnie na BFSie tez jeszcze sie z tym nie spotkalem. 

 *BeteNoire wrote:*   

> Czy "skopiowanie zrodel 2.6.32 do innego katalogu na mojej maszynie" może być miarodajnym testem? To operacja, której nigdy jeszcze nie wykonywałem  I nie sądzę, by przerzucanie kupy plików z miejsca w miejsce obok było funkcją desktopu.

 

Wiesz  :Razz:  najlatwiej wyjac zdanie z kontekstu  :Smile: ) po miejscu w ktorym zakonczyles cudzyslow bylo jeszcze, "dla mnie to wazne, bo ta operacje wykonuje najczesciej" a przed otwarciem cudzyslowia napisalem "dla przykladu"  :Smile: 

Oczywiscie, ze nie jest to miarodajny test i nigdzie tego nie sugerowalem  :Smile: 

No tak...ogolnie wiadomo, ze dla partycji z wieloma malymi plikami czyli system czy tam gdzie trzymamy portage najlepiej sprawdza sie reiserfs czy fsy oparte na b-tree - czyli reiser4 i btrfs. Dla operacji na duzych plikach xfs. Jezeli chcemy najmniej obciazac procesor - jfs a ext3/4 coz...swego rodzaju sredniak do wszystkiego. Reiser4 jest jeszcze szybszy na tych malych plikach niz Reiser 3.5/3.6 i jeszcze troche dodatkowo obciaza procesor. Po ostatnich fixach btrfs osiagnal juz wydajnosc zblizona do reisera4 a co wazne - osiaga lepsza sprawnosc w operacjach na duzych plikach niz ext3/ext4. Faktycznie moze stac sie system plikow nastepnej generacji dla linuxa. O zaletach sprawdzania i defragmentacji w locie oraz snapshotow chyba nie trzeba nawet mowic.

 *galimedes wrote:*   

> Jeśli chodzi o schedulery windowsowe to kiedyś w pracy badaliśmy działanie IIS na różnych wersjach Win2k8 i różnych serwerach od starych maszyn jedno procesorowych do najlepszych maszyn dostępnych w naszym departamencie i z wykorzystaniem vs do wygenerowania symulowanego ruchu wysoce przekraczającego możliwość maszyny około 1mln odwiedzin na minutę na każdy cpu. Wnioski okazały się dosyć zaskakujące ponieważ na maszynach posiadających 1-16 cpu przy obciążeniu iis okazało się że wersje datacenter i podobne czyli przeznaczone dla serwerów powyżej 32 procesorów wypadały znacznie gorzej niż można było oczekiwać po optymalizacji obsługi połączeń jaki IO i zarządzania wątkami z racji tego doszliśmy do wniosku iż każda wersja ma osobny scheduler i ściśle przeznaczony do mocy sprzętu. 
> 
> A więc wracając do tego co napisałeś kiedyś łatka CK faktycznie robiła ogromną furorę natomiast na sprawę nowego schedulera trzeba spojrzeć szerzej mianowicie na panujące trendy w technologiach i algorytmach gdzie duży nacisk kładziony jest na generyczny i uniwersalny kod który jak wiemy zawsze posiada pewne wady mimo to wzorce opisujące je są bardzo chętnie absorbowane do wszelakich projektów i niestety odbija się to czkawką tam gdzie potrzebna jest wydajność. Niestety Ingo i spółka zatracili się w swoich wizjach co powoduje powstanie kobyły która umie wszystko ale jest koszmarnie wolna, z racji tego przychodzą mi na myśl słowa kolesia z M$ że jest to "opportunity for business" gdzie można zrobić coś na swoją miarę i raczej się to nie zmieni z tego co pamiętam Ingo jest strasznie upartym człowiekiem jeśli chodzi o ten temat. Fallow sam powinieneś zauważyć iż wcześniej większość gier aplikacji pisana była w MFC, a dziś fakt też się go wykorzystuje jednak cześć pisze się w językach znacznie wyższego poziomu np c# co daję dobry przykład że "my" developerzy i architekci ulegamy presji aby wytwarzać szybciej stąd mamy tą nieszczęsną modę na generyki  tutaj nie tylko należy patrzeć na jądro następnym przykładem jest xorg. Jeden z moich wykładowców kiedyś powiedział fajną definicję systemu że jest to byt który ma zajmować jak najmniej zasobów i działać jak najszybciej dziś niestety systemy stają się kobyłami które nie są dedykowane ale starają się dostosować do maszyny.
> 
> [OT]
> ...

 

Witaj Galimedes. W ramach wstepu OT - milo, ze nie tylko ja wracam!  :Smile: 

Bardzo ciekawe jest to co opisujesz, ja nie mialem nigdy mozliwosci zrobienia tak ciekawych testow. W takim razie mozna pochwalic M$, ze wlasnie tak podchodzi do sprawy. Jak dla mnie w sposob bardzo logiczny i uzasadniony.

Tak masz 100% racje co do obecnzch trendow. W mojej branzy jest oczywiscie tak samo. Piszac przykladowo gre na urzadzenia mobilne piszemy ja w jakims jezyki najwyzszego poziomu pozniej uzywajac cross-compilatora przenosimy na docelowe platformy. W duzym stopniu cross-compilowany jest nawet same pierwotny framework a dopiero male dodatki badz tuning robiony jest na docelowej platformie. Oczywiscie kompletnie nie pozwala to wykorzystywac potencjalu danej platformy no ale z businessowego punktu widzenia pozwala oszczedzic kupe czasu i pieniedzy. 

Zawsze jednak wydawalo mi sie, ze developerzy kernela nie beda ulegac takim trendom gdyz ... no gdzie tu jest ten business ?  :Smile:  No chyba,ze sie myle - moze po prostu nie mam pelnej perspektywy. Ingo to faktycznie bardzo uparty typ, widac to dobrze na LKML. Z reszta sam Linus takze.

Dodatkowo dochodzi (w kontekscie zauwazania oczywistego) sprawa troche przerosnietego ego mainstreamowych developerow jadra.

Jakis lekarz anestezjolog chce wywalic CPU Scheduler wielkiego Ingo Molnara, albo przynajmniej dodac swoj do wyboru. "No jak to"  :Smile: )

CFS faktycznie ma potencjal ale jest nieslychana krowa ktora pewnie nigdy nie osiagnie takiej interaktywnosci jak BFS. Zapytalem Con'a czy zamierza utrzymywac teraz BFSa - odparl ze zamierza robic to po wsze czasy i nie interesuje go wejscie do glownej galezi.

Pytanie tylko - jak szybko mu sie znudzi. 

Z perspektywy czasu wydaje mi sie to bardzo smieszne jak na Amidze powiedzmy 1200 z zegarem 14MHz i 68EC020 pakowalem sobie cos w tle, kopiowalem, leciala muzyka, real3d cos renderowal a responsywnosc Workbencha byla niezachwiana. Podczas gdy intaluje sobie vanillie z nowa krowa CFSem. Wykonuje podobne operacje albo nawet mniej - i widze wkurzajace opoznienia gdy przelaczam sobie taski albo klikam na zakladki w przegladarce. Jasna cholera mam 4 rdzenie po 2.33GHz a tam mialem jeden 14MHzowy  :Smile: )

Ciekawe jaka bedzie przyszlosc jadra linuxa i czy uogolniajac potencjali uzytkownicy takich dystrybucji jak Ubuntu w ogole zauwazaja cos "nieprawidlowego" czy tez w zasadzie dla nich nie ma to za bardzo znaczenia. Moze to "my" jestesmy "zbyt zryci" ?  :Smile: 

------ EDIT ------

PS. Ten dokument takze wydaje sie byc dosc ciekawy -> http://www.cs.unm.edu/~eschulte/data/bfs-v-cfs_groves-knockel-schulte.pdf

----------

## galimedes

 *fallow wrote:*   

> ...
> 
> Ciekawe jaka bedzie przyszlosc jadra linuxa i czy uogolniajac potencjali uzytkownicy takich dystrybucji jak Ubuntu w ogole zauwazaja cos "nieprawidlowego" czy tez w zasadzie dla nich nie ma to za bardzo znaczenia. Moze to "my" jestesmy "zbyt zryci" ? 
> 
> ...

 

W kwestii tego może rozwiązanie podsunie Ci ankieta w starym wąteku  :Wink:  klik

Większość użytkowników nigdy nawet nie zastanowi się nad kwestią schedulerów ponieważ o nich nie wiedzą  :Wink:  posłużę się tu przykładem niestety również powiązanym z MS  :Razz:  w momencie gdy wyszła vista użytkownicy narzekali na jej wydajność (nie da się ukryć że była do dupy ale to inna kwesja) natomiast nigdy nie wyłączyli usług które zjadały za dużo zasobów ponieważ o nich nie wiedzieli, a też i nie umieli sprawdzić,podobnie jest z ubuntu mój kolega zakupił ostatnio jakiegoś netbooka z ubuntu i o zgrozo jak zobaczyłem co tam staruje to nie mogłem dojść do siebie przez kilka ładnych minut ale użytkownik nie wiedział do czego są i je ignorował po kilku godzinach optymalizacji kernela i usług nagle się okazało że maszyna startuje 3x szybciej i jakoś lepiej reaguje na interakcje z użytkownikiem. Stąd moje podejrzenie że osoby które zaczną przygodę z Linuksem za 3-5 lat będą technologicznie upośledzone jak użytkownicy windowsa ponieważ dziś można zauważyć pewien podział User<=Application developer/Admin<=Framwork/IDE developer<=OS Developer i z czasem ten podział będzie się pogłębiać zauważam to nawet po rozmowach z niektórymi programistami u mnie w dziale którzy nie badają jak jakieś rozwiązanie działa w tle tylko że działa. Przecież pamiętam jak kilkanaście lat temu zaczynałem to tylko vim człowiek widział a dziś środowisko developerskie to kobyła która na starcie zjada 2Gb ram i służy do napisania aplikacji która ma zaledwie kilka Mb. 

[OT]

Ciekawe kogo jeszcze przywieje  :Smile: 

[/OT]

----------

## lmmsci

Może moja wypowiedź będzie nieco mniej techniczna, a bardziej ,,użytkowa''. Ostatnio przez dłuższy czas używałem głównej linii (gentoo-sources). Po przeczytaniu postów w tym wątku postanowiłem skorzystać z czegoś niestandardowego i wrzuciłem zen-sources (obecnie skompilowany kernel to 2.6.32-zen6, a więc niespecjalna nowość). Maszynka to lenovo sl 400. Jako scheduler ustawiony BFS, io sched - deadline. 

Moje zaskoczenie było conajmniej wielkie. Wszystko przyspieszyło dość znacząco (subiektywne odczucia). Nawet sławny mułowaty firefox zaczął się zachowywać jak, przepraszam za słownictwo, pod windowsem - normalne przewijanie stron (przedtem zdarzało się, że film osobno, reszta osobno i poklatkowo). KDE też zaczęło jeszcze bradziej nadawać się do używania. 

Dołączam się do opinii, że dobrze byłoby, gdyby ktoś pomyślał o normalnych userach (nawet nie power)... Do wielu rzeczy linuks (tu: gentoo) jest dla mnie zdecydowanie lepszym narzędziem niż win. Podejrzewam, że krąg podobnych userów (niekoniecznie gmerających w asm) dałoby się znacznie poszerzyć, gdyby ktoś po prostu pomyślał, także wśród tych odpowiedzialnych za kernel. No bo jak mam komuś wytłumaczyć, że to dobry system, tylko - co czasami niestety aż rzuca się w oczy - chodzi wolniej niż vista z ajero, jeśli się przy nim nie pokombinuje... I nie chodzi o włączanie czy wyłączanie tej czy innej usługi. 

A odnośnie Amigi: w którymś Bajtku (hehe, ktos pamięta?...) była taka opinia: gdyby z Amigi wyciśnięto tyle, co ze Spectrum, wyleciałaby w kosmos... Optimize, optimize, optimize.

----------

## canis_lupus

Panowie, takie głupie pytanie, bo chyba jakąs pomroczność mam, jak zaaplikować BFS w jajku? JEst gdzieś jakas instrukcja?

----------

## fallow

 *galimedes wrote:*   

>  *fallow wrote:*   ...
> 
> Ciekawe jaka bedzie przyszlosc jadra linuxa i czy uogolniajac potencjali uzytkownicy takich dystrybucji jak Ubuntu w ogole zauwazaja cos "nieprawidlowego" czy tez w zasadzie dla nich nie ma to za bardzo znaczenia. Moze to "my" jestesmy "zbyt zryci" ? 
> 
> ... 
> ...

 

W pelni sie zgadzam Galimedes. Za kilka lat gdy aby uzywac Linuxa bedzie wystarczac po prostu by go zainstalowac instalatorem o podobnym poziomie "komplikacji" co instalator Windows, wielu uzytkownikow bedzie odizolowanych od systemu. O jadrze juz nawet nie wspominajac. Dylematy typu wybor CPU Schedulera po prostu kompletnie nie bedzie ich dotyczyl gdyz byc moze nie beda nawet swiadomi tego, ze jest jakies jadra systemu operacyjnego.

Ciekawi mnie czy za te kilka lat - znajda sie rownie skuteczne sposoby by "obnizac" wydajnosc szybszych wtedy komputerow - co teraz. 

Trudno powiedziec czy jest to dobre czy zle (IMHO). Z jednej strony umozliwia uzytkowanie technologi przez uzytkownikow kompletnie z nia niezwiazanych. Przykladowo jezeli beda istnialy w przyszlosci jakies diagnostyczne domowe urzadzenia medyczne zastepujace w pewnym stopniu lekarza pierwszego kontaktu badz innego tez nie chcialbym zeby warunkiem korzystania bylo posiadanie szerokiej wiedzy z zakresu medycyny. Chcialbym otrzymywac esencje badz uproszczony "output".

lmmsci: Potwierdzam Twoje subiektywny odczucia. By tylko uscislic - co do wydajnosci - lepszy jest O(1) lub CFS. BFS i Staircase zapewniaja mniejsze opoznienia/wieksza interaktywnosc i gorsza wydajnosc. Na desktopie oczywsicie wieksze znaczenie ma interaktywnosc systemu niz ogolna wydajnosc.

Przy CPU Schedulerze takim jak BFS powinienes uzyskac jeszcze lepsze rezultaty interaktywnosci uzywajac jednak CFQ jako IO Scheduler. Deadline podnosi ogolna wydajnosc operacji I/O w stosunku do CFQ ale takze zwiekszenie uzycia procesora.

canis_lupus:

1) Nalezy pobrac odpowiedni do swojej wersji jadra patch ze strony Cona Kolivasa -> http://www.kernel.org/pub/linux/kernel/people/ck/patches/2.6/

2) Zaaplikowac latke np. tak: 

```
 bzip2 -dc nazwa_latki | patch -p1 
```

3) Skompilowac i zainstalowac jadro

Lub mozna tez uzywac gotowych patchsetow taki jak Zen-Kernel. Trzeba jednak pamietac o tym, ze ich maintainerzy nie sa autorami kodu poszczegolnych latek i czesto poprawiaja rejecty na slepo albo na wyczucie nie wiedzac co w rzeczywistosci robia (aby sie kompilowalo).

Zawsze jest ryzyko, ze jadro potraktowane takim patchsetem nie bedzie dzialac tak jak powinno.

(Inna sprawa, czy vanilla dziala jak powinna  :Wink:  )

----------

## soban_

 *fallow wrote:*   

> (Inna sprawa, czy vanilla dziala jak powinna ;) )

 

Wlasnie w sprawie vanilla, moze ktos z Was sie wypowiedziec? Nad Zen-Kernel'em zaczynam sie powaznie zastanawiam, jak do tej pory bylem zadowolony z gentoo-sources. Jednak czytajac Wasze wypowiedzi chetnie sprawdze jak to jajko zachowuje sie w praktyce. Swoja droga takie pytanie, na czym najlepiej testowac wydajnosc takiego jadra? Po prostu pozostaje praktyka tak jak napisal:

 *lmmsci wrote:*   

> Wszystko przyspieszyło dość znacząco (subiektywne odczucia). Nawet sławny mułowaty firefox zaczął się zachowywać jak, przepraszam za słownictwo, pod windowsem - normalne przewijanie stron (przedtem zdarzało się, że film osobno, reszta osobno i poklatkowo). KDE też zaczęło jeszcze bradziej nadawać się do używania. 

  Czy sa jakies inne metody (tak jak glxgears)? I moze to glupie pytanie ale jeszcze dodam, czy mozna "zywcem" skopiowac konfig z innego kernela np gentoo-sources (.config) do zen-kernel'a?

----------

## unK

 *soban_ wrote:*   

> Wlasnie w sprawie vanilla, moze ktos z Was sie wypowiedziec? Nad Zen-Kernel'em zaczynam sie powaznie zastanawiam, jak do tej pory bylem zadowolony z gentoo-sources. Jednak czytajac Wasze wypowiedzi chetnie sprawdze jak to jajko zachowuje sie w praktyce.

 

Jeżeli chodzi o zen, to jest kilka problemów. Pierwszy to to, o czym wspomniał fallow. Z tego, co zauważyłem maintainerzy zena ładują w kernel każdy patch, który znajdą w necie i "może poprawić wydajność" -> jest tego dużo -> rejecty są nieuniknione. Nie wiem, jak oni się orientują w kernelu, dlatego nie powiem, że robią to źle, ale wiadomo, że im więcej takich sytuacji, tym bardziej prawdopodobna jest wpadka (chociażby przez nieuwagę).

Kolejna sprawa to reiser4 (dla mnie ważna, bo mam / na tym). Reiser4 w zenie jest afaik z mmotm, przez co zazwyczaj bywa niestabilny, co jest w zasadzie głównym powodem, dla którego nie używam tego patchsetu.

Btw, aktualnie używam gentoo-sources-2.6.32-r5 + reiser4 + bfs i faktycznie jest to zauważalnie bardziej responsywne niż 2.6.27, z którego się przesiadłem. Z tym, że nie wiem, czy to przez bfs, czy po prostu nowszą wersję kernela, a nie chce mi się już rekompilować bez bfs ;p

 *SlashBeast wrote:*   

> O reiser4 rozmawiac nie bede, moge na niego nawrzucac tyle, co na paludisa, po prostu ... nie.

 

Uzywałeś reiser4 z zen, czy stąd?

----------

## lmmsci

soban_: do katalogu z zenem kopiujesz .config i dajesz:

```
make oldconfig
```

Będzie Cię pytał o masę jakichś dodatków (np. zenowate pingwiny na starcie   :Wink:   ) ale wszystko idzie poprawnie.

----------

## SlashBeast

@unK Obu, na wielu kernelach, z odstepami po kilka miesiecy.

----------

## dylon

 *fallow wrote:*   

> 
> 
> 1) Nalezy pobrac odpowiedni do swojej wersji jadra patch ze strony Cona Kolivasa -> http://www.kernel.org/pub/linux/kernel/people/ck/patches/2.6/
> 
> 

 

Wlasnie sobie testuje i wstepnie wydaje sie, ze responsywnosc bardzo sie poprawila (chyba, ze to wersja kernela, bo wczesniej mialem gentoo-2.6.31-r4 a teraz 32-r5).

Minusem jest, ze wczesniej mialem lvg srednio 0,2 a teraz 0,9 (przez to, tez sie bardziej procek grzeje i wentylator sie juz daje slyszec:( )

----------

## Lord_Raven

Witam

Sam przez długi czas korzystałem ze starych łatek CK i pewnie korzystałbym dalej gdyby Con w pewnym momencie nie obraził się na cały świat i przestał rozwijać swoją koncepcje. Jak pamiętam były to czasy w który CFS był dopiero w planach. BFS? Ciekawe. Nie wiedziałem że Con "wrócił do świata żywych". Warto spróbować. Tym bardzie że zarówno w domu jak i w pracy zdarza mi się narzekać na obecnego schedulera.

Czytając Wasze wypowiedzi zastanawiam się czy sami wiemy czego chcemy? Z jednej strony wyzywamy na CFS, który w teorii ma być jednym słusznym schedulerm, dobrym dla dowolnych rozwiązań (serwer, desktop), a z drugiej jesteśmy pełni nadziei w stosunku do BTRFS, który ma szanse zostać jedynym słusznym systemem plików? Pytanie czego szukamy? Uniwersalności czy maksymalnego dostosowania do potrzeb. Z jednej strony chcąc nie chcąc trzeba nadążać za rozwojem technologicznym a z drugiej chciało by się, coby serwery czy desktopy działały maksymalnie wydajnie.

Wydaje mi się, że w tym całym zamieszaniu problemem jesteśmy my - użytkownicy. A w zasadzie wrzucanie do jednego wora nas "Gentowców", którym od zawsze zależało na wydajności, i "Ubuntowców", a wiec tych którzy chcą coby po prostu im działało. Nie chce tu urazić zwolenników Ubunto. Porównanie służy jedynie zobrazowaniu kontrastu pomiędzy systemami kompilowanymi a pakietowymi.

----------

## canis_lupus

Ma sens BFS na maszynkach serwerowych? Takich 4 procesorowych?

----------

## SlashBeast

 *canis_lupus wrote:*   

> Ma sens BFS na maszynkach serwerowych? Takich 4 procesorowych?

 

Zalezy od tego jakie aplikacje serwujesz. Ja jestem zadowolony, mysql jakos lepiej sobie radzi.

----------

## galimedes

 *canis_lupus wrote:*   

> Ma sens BFS na maszynkach serwerowych? Takich 4 procesorowych?

 

Hm kwasja czy przez procesory rozumiesz fizycznie CPU czy core natomiast przed wyborem warto się zastanowić nad przeznaczeniem ponieważ inne są wymagania względem systemów DB a inne web. Dlatego w takiej sytuacji należy przeanalizować słabe strony serwera i próbować je zniwelować optymalizując system w tym zakresie. Czyli reasumując najpierw siada się do narzędzi do projektowania architektury (celowo nie podaje jakie są ponieważ u mnie w grupie są wykorzystywane wiadomo jakie  :Wink:  ) następnie projektuje się scenariusze, dopiero po określeniu scenariuszy dojścia do założonego przeznaczenie można powiedzieć co się sprawdzi. Ciekawym i w sensie praktycznym potrzebnym urozmaiceniem były by testy aby weryfikować który scenariusz jest już zrealizowany. Trochę na to poświęcisz czasu natomiast będzie to podejście w 100% profesjonalne. Niestety na takie pytanie nie można nigdy odpowiedzieć wprost ponieważ było by to wróżenie z fusów a nie o to chodzi w IT   :Twisted Evil: 

 *fallow wrote:*   

> ...
> 
> Trudno powiedziec czy jest to dobre czy zle (IMHO). Z jednej strony umozliwia uzytkowanie technologi przez uzytkownikow kompletnie z nia niezwiazanych. Przykladowo jezeli beda istnialy w przyszlosci jakies diagnostyczne domowe urzadzenia medyczne zastepujace w pewnym stopniu lekarza pierwszego kontaktu badz innego tez nie chcialbym zeby warunkiem korzystania bylo posiadanie szerokiej wiedzy z zakresu medycyny. Chcialbym otrzymywac esencje badz uproszczony "output".
> 
> ...

 

Natomiast pamiętam jak powstawało gentoo było z przeznaczeniem dla ludzi świadomych wyborów jakie podejmują. Później nastąpiły moment w którym na topie było gentoo przez renomę ludzi którzy na nim pracowali co spowodowało że masę osób chciało poznać to distro, ale skutecznym filtrem umiejętności był instalator albo jak kto woli jego brak  :Wink: . Natomiast ostatnio jak obserwuję forum nie tylko polskie zauważam że moderatorzy nie zamykają wątków które się powtarzają albo rozwiązanie jest w bug bądź dokumentacji, co powoduje że dużo ludzi doświadczonych opuszcza community. Analogicznie dotyczy to systemów Unix/Linux wcześniej przeznaczone by dla ludzi o zainteresowaniach z zakresu IT i umiejących rozwiązać część problemów w własnym zakresie dziś stawia się Linux jako konkurencję dla Windows ale niestety to nie nastąpi przez następne 10-15 lat ba według mnie Linux "nigdy" nie powinien przypominać Windows te systemy powinny koegzystować nawet sam Linus też tak twierdził w którymś z wywiadów. Prawda jest taka że dzięki takiemu podejściu użytkownik ma wybór prosty działający (wolno przez brak optymalizacji) i Linux dla ludzi świadomych informatycznie. Sam mogę powiedzieć rzecz która może zostać odebrana jako herezja  :Wink:  natomiast i Windows i Linux są tak samo wydajne jedyną różnicą jest to że w Linuksie użytkownik ma wszystko jak na tacy natomiast żeby posiąść tą samą wiedzę odnośnie systemów M$ trzeba bardzo dużo czytać technet i msdn, które są naprawdę bardzo dobrym źródłem informacji. Zła renoma Windowsa jest spowodowana skalą jego użytkowania 3 na 4 komputery na świecie działają na którymś z Windowsów, a użytkownicy co nie posiadają wiedzy tworzą złą atmosferę sam się o tym przekonałem gdy zacząłem pracę w firmie która wykorzystuje w 98% produkty M$ nagle się okazało że moja wiedza z tego zakresu była praktycznie zerowa i musiałem się wiele nauczyć. Natomiast wracając do sedna sprawy produkty powinny by dostosowane do różnych poziomów wiedzy np:

Windows za raz po instalacji użytkownik z paczki ma wszystko co potrzeba do pracy

Linux użytkownik buduje swoje środowisko pracy

Celowo nie wspominam tutaj o różnych kompromisach i merg-ach  tych dwóch przykładów natomiast tak wygląda zdrowa sytuacja inaczej będą powstawać protezy które niby mają ułatwić życie ale dostarczają więcej problemów niż dają rozwiązań.

Sorki ale zauważam że robię z tego wątku Offtopic  :Wink: 

----------

## canis_lupus

Akurat serwery baz danych mam na oddzielnym serwerze a serwery apache, ftp itp na oddzielnym.

----------

## SlashBeast

http://www.phoronix.com/scan.php?page=news_item&px=ODAxOQ - Powrót patchsetu ck, 2.6.33-ck1. Co sadzicie o tych zmianach? Ja jakos nigdy nie moge sie zgodzic z tym irracjonalnie wysokim Hz, na dualcore laptopie zawsze 300MHz na serwerach zawsze 100Hz mam.

Edit: zaplikowalem latki 'calosciowa', chcialem z broken-outa ale rejecty mialem, przeszedle z 2.6.32-gentoo-r5 z bfsem i linux-phc na ck1 z linux-phc, config taki sam, trudno mi powiedziec czy jest jakas roznica. Ktos ma jakies odczucia?

----------

## gexcite

Aktualnie mam 2.6.32-gentoo-r5 z łatakmi ck. Muszę przyznać, że KDE-4.3.5 wyraźnie nabrało skrzydeł na Asusie A6000 z Sempronem  :Smile: 

----------

## Lord_Raven

a może ktoś by się pokusił o ebuilda z łatkami ck?

----------

## one_and_only

https://bugs.gentoo.org/show_bug.cgi?id=297169

----------

