Linux 2.6.35 wydany [aktualizacja]

No to domalujemy wąsy i powiedzmy że to synowie

Ja nie wiedzę problemu. W Polsce przeszła królowa Jadwiga więc dlaczego tutaj miało by się nie udać.

Tak bo kobiety nie mogą być programistami.

Albo Joanna Rutkowska

Albo – z Linuksowego poletka – Valerie Aurora. Inna sprawa, ze niedawno postanowila zerwac z developowaniem kernela (kolejna zla wiadomosc dla Btrfs-a) i zajac sie czyms ciekawszym.

1. Ona była królem, a nie królową/królewną

2. Ile jego córki mają lat? Linus jest jeszcze młodą osobą, więc może czas zacząć córki przygotowywać do przejęcia władzy?

3. I tak to wszystko bez znaczenia – władzę przejmie ten, kto najlepiej będzie się sprawować, jako władca. Nie zapomnijmy, że w przypadku śmierci Linusa dojdzie do pomnożenia królestwa i będzie istnieć sporo, z początku identycznych, królestw. Potem jedno przetrwa, a reszta upadnie(i wszyscy jednak będą szczęśliwi, więc nie nastąpi to szybko).

Ale sie przyczepiliscie Jasne ze moga byc, z tymi corkami to bylo do "Władza z ojca na _syna_!"

Joanna Rutkowska to akuratnie nietrafiony przykład bo, z całym szacunkiem do wiedzy i umiejętności, dopiero w trakcie studiów stała się nią zamiast nim

Teraz jest przynajmniej co poczytać. Widocznie trendy z mikroblogingu przechodzą również na zwykłe serwisy i stąd coraz większa popularność kadłubków.

To nie wina twórcy treści, tylko ich odbiorców.

Mikroblogi nie stały się popularne, bo ludziom nie chciało się więcej pisać. Mikroblogi stały się popularne, bo więcej niż 3 linijki to za dużo jak na przeciętnego internautę.

Dzięki, że Ci się chciało, bo wersja byiska była masakryczna.

Albo ustawiając smp_affinity dla danego IRQ.

@trasz: bzdura. Poczynając na tym, że irqbalance (czy to kernelowego czy userspace) do przerzucania przerwań z kart sieciowych to gruba pomyłka, taki błąd mógłby zrobić tylko kompletny laik, a kończąc na zupełnym pominięciu konfiguracji APIC (tryb logiczny-płaski/fizyczny, x2APIX) czy w ogóle architektury (broadcast przerwania na wspólną szynę przy FSB lub punktowo przy takim QuickPath w Nehalemach). NAPI pewnie też włączasz?

Krótko mówiąc: nie, żadnego irqbalance się nie używa. Korzysta się z smp_affinity na _odpowiednim sprzęcie_.

@trasz: o widzisz, dwi godziny pozniej piszesz, ze jednak dalo sie to robic w Linuksie duzo wczesniej… Fajnie, jakbys jeszcze rozumial idee irqbalance.

Tak jak piszesz, interrupt threads nie ma nic do pakietow out-of-order, ani z przetwarzaniem pakietow aplikacji na tym samym procesorze – dziekuje, ze uznales tym samym wyzszosc Linuksa.

@gotar: Jak zwal, tak zwal – wazne, ze nie dzialo sie to automatycznie, i ze calosc rozwiazania jest jednym wielkim hackiem, bo przy normalnej architekturze cale obciazenie rozklada sie "samo z siebie", automatycznie – w koncu watek to watek – a w Linuksie trzeba kombinowac, albo, jak wczesniej, recznie, albo uzywajac kolejnego workarounda.

@mangoo: Nadal nie rozumiesz. Interrupt threads nie sa zwiazane w zaden sposob z kolejnoscia pakietow czy "przetwarzaniem pakietow aplikacji na tym samym procesorze". W sensie, twoje pytanie nie ma sensu i sugeruje, ze nie rozumiesz, czym sa interrupt threads.

@gotar i mangoo: a może mały artykulik o tych rozwiązaniach i porównanie do 'innych uniksowatych'.

@trasz: sugerowanie, ze przy "interrupt threads" wszystko sie robi samo swiadczy o tym, ze kompletnie nie wiesz o czym piszesz.

I tak jak sam powiedziales: interrupt threads nie sa zwiazane w zaden sposob z kolejnoscia pakietow czy “przetwarzaniem pakietow aplikacji na tym samym procesorze” – czyli identycznie, jak dotychczas bylo z uzyciem SMP do obslugi sieci w Linuksie.

Linux z RPS i RFS nie ma ww. problemow (pakiety nie pokolei, cache misses).

@mangoo: Ponizej zostalo wyjasnione. W wielkim skrocie, zebys nie musial za duzo guglac – to, o czym piszesz, wyglada na problem specyficzny dla jakiegos Linuksianego eksperymentu, ktory rozrzucal pakiety roundrobinem na kilka CPU. Jest to glupie, wiec inne systemy tego nie robia.

@trasz: widze ze wygooglowales, czym sa pakiety nie po kolei w podsystemie sieciowym – bo kilka postow wczesniej nie miales w ogole pojecia, o co chodzi.

Nie wygoglales jeszcze, ze w "uniksowatych" nie zapewniaja tego interrupt threads, jak sugerujesz – potrzebny jest do tego specjalny mechanizm (choc tego typu mechanizm w Linuksie nazywasz "dorabianiem hackow"); z interrupt threads i wieloma procesorami mozna wresz byc pewnym, ze pakiety beda w zlej kolejnosci.

A ze teraz wycofujesz sie rakiem z glupoty, jaka palnales – typowe.

@trasz: "wazne, ze nie dzialo sie to automatycznie"

Ależ działo – smp_affinity właśnie służy do _ograniczania_ owej automatyki w sytuacji, w której administrator lepiej wie, jak co MA działać (np. nie chce, aby obciążenie z DDoS 'rozłożyło' się na wszystkie rdzenie uniemożliwiając zalogowanie się do maszyny).

"automatycznie – w koncu watek to watek – a w Linuksie trzeba kombinowac, albo, jak wczesniej, recznie, albo uzywajac kolejnego workarounda."

Chyba nie do końca wiesz, o czym piszesz – wektor przerwań (jeden wątek) domyślnie obsługiwany w round-robin na kolejnych rdzeniach (na odpowiednim sprzęcie, nie wszędzie to działa, w szczególności broadcasty są wyłączane przy dużej liczbie rdzeni) ograniczało się poprzez affinity tylko do wybranych. O ile w ten sposób wykorzystujemy więcej rdzeni, o tyle uwalamy cache coherence. Rozwiązaniem na to są karty wielokolejkowe (MSI-X), które używają hashowania kilku wartości z ramek w celu przypisania jednego połączenia na stałe do jednej kolejki – a przez to dalej do jeszcze węższej grupy rdzeni (idealnie: do jednego, gdy liczba kolejek RX==liczbie rdzeni, bo TX przy tym co ja np. robię nie ma żadnego znaczenia). RPS załatwia właśnie problem z cache na kartach 1-kolejkowych (ogólnie: mniej-niż-rdzenio-kolejkowych) oraz może ewentualnie takich, które nie obsługują hashowania. Zapewne pomoże to ludziom, którzy mając SMP używali NAPI (czy to z braku wiedzy, czy nieodpowiedniego sprzętu – choć zły zakup to też brak wiedzy). NIE SĄDZĘ, że pozwoli na rozłożenie SoftIRQ na sprzęcie, na którym do tej pory to nie działało; rozumiem że twierdzisz, iż w innych systemach działało to wszędzie!? Bardzo jestem ciekaw, bo mi się wydawało, iż problemem jest APIC, czyli sprzęt. Niezbyt sobie wyobrażam programowe obejście QuickPath kierującego w physical mode bez x2APIC przerwanie do konkretnego procesora – w tej łacie nie widzę przeprogramowywania APIC z każdą ramką; ale nawet gdyby coś takiego było możliwe – czyżbyś więc uważał, że rozwiązanie klasy '1 procesor przyjmuje przerwanie i przekazuje jego obsługę do innego, bo sprzęt nie umie tego zrobić', uważał za killer-feature dobrego systemu? Bo mi się zawsze wydawało, że po prostu należy kupić właściwy sprzęt.

Mówiąc krótko: RPS (a tym bardziej RFS) to mechanizmy wspierające cache locality oraz aplikacje korzystające z sieci. Obie te rzeczy mają tyle wspólnego z irqbalance, o którym wspomniałeś …że dają dokładnie odwrotny efekt!

@Tomasz Woźniak – nie walczyłem z przetwarzaniem przerwań na innych unices, ale z informacji, jakie pobieżnie (zaznaczam) gdzieś mi się ujawniły, wynikało że FreeBSD ma to znacznie gorzej rozwiązane.

@trasz: "problem specyficzny dla jakiegos Linuksianego eksperymentu, ktory rozrzucal pakiety roundrobinem na kilka CPU. Jest to glupie, wiec inne systemy tego nie robia."

BUAHAHAHAHAHHAHHAAAAAAAAAAAAAAAAA

@gotar: Wiec twierdzisz, ze jakis system nie bedacy Linuksem ma watki przerwan bez CPU affinity. Ciekawe. Ktory konkretnie?

Odnosnie "przekazywania" przerwan miedzy kontrolerami – oj, cos mi swita, ze mocno nie rozumiesz tego mechanizmu. Przerwanie – w sensie, to zglaszane przez APIC – budzi watek i maskuje przerwanie. Nic wiecej nie robi. Nie obchodzi go, na ktorym procesorze watek sie wykona.

Znow – jestes pewien, ze nie mylisz normalnych interrupt threads z jakims Linuksianym eksperymentem, ktory byl po prostu strasznie kulawa implementacja?

@mangoo: Nie wyguglalem, tylko ktos w komentarzu ponizej wyjasnil, o co ci chodzilo. Odpowiedzialem: mowisz o problemach zwiazanych z jakas kulawa namiastka w Linuksie, nie o interrupt threads jako takich, bo one nie maja z twoim problemem zwiazku.

@trasz: ja mowie o tym, ze blaznisz sie, mowiac ze "to co w Linuksie zapewniaja jakies dzikie hacki, w innych systemach rozwiazuje interrupt threads". Co wy tam palicie?

@trasz:

"Wiec twierdzisz, ze jakis system nie bedacy Linuksem ma watki przerwan bez CPU affinity. Ciekawe. Ktory konkretnie?"

Nie pisałem nic o żadnym innym systemie, więc musisz rozjaśnić skąd wyczytałeś takie moje rzekome twierdzenie.

"Odnosnie “przekazywania” przerwan miedzy kontrolerami – oj, cos mi swita, ze mocno nie rozumiesz tego mechanizmu. Przerwanie – w sensie, to zglaszane przez APIC – budzi watek i maskuje przerwanie. Nic wiecej nie robi. Nie obchodzi go, na ktorym procesorze watek sie wykona."

Heheheh… W logical destination mode – owszem. Niestety ten tryb dostarczania przerwań (a maską CPU) nie jest jedyny i jest niedostępny np. w x2APIC, bo wymagałoby to rozgłoszenia każdego przerwania każdym(!) obecnym linkiem p2p.

Musisz zaktualizować swoją wiedzę poza ostatnie parę lat, bo chyba zatrzymałeś się tak w okolicach FSB.

Ostatni sprawdzany przeze mnie Nehalem miał 2 układy APIC, 4 QuickPath i …jedno przerwanie==jeden rdzeń. To nie była zaleta.

"Znow – jestes pewien, ze nie mylisz normalnych interrupt threads z jakims Linuksianym eksperymentem, ktory byl po prostu strasznie kulawa implementacja?"

Nie. W trybie, o którym sam piszesz, przerwanie jest rozgłaszane do wszystkich CPU, a przejmuje je ten, który akurat ma najmniej do roboty (lowest priority delivery mode, co w przypadku obciążania jedynie jednostajnym ruchem sieciowym oznacza de facto round robin). Pisałeś, że to głupie, więc inne systemy tego nie robią – i w porządku, jeśli tego nie chcesz, to wyłączasz (smp_affinity ustawiane z ręki albo przez irqbalance, tj. demona userspace, nie myl z kernelowym irqbalace). Czyli ta przewaga innych systemów polega na tym, że nie pozwalają zrobić 'czegoś głupiego'?

Tylko czekaj czekaj, wiesz co… "Pentium processor system architecture", rozdział 15, strona 365 – jakoś mi się dziwnie wydaje, że to nie jest żaden "strasznie kulawy linuksiany eksperyment", tylko zwyczajna funkcja SPRZĘTOWA. Czyli te "fajne systemy" po prostu jej nie obsługują (albo o tym nie wiesz)

A mi ona jest potrzebna…

Już wyjaśniałem, że wolę mieć 240% sumarycznego obciążenia niż 160%, ale z zapasem kolejnych 560% zamiast marnych 40%, jeśli wektorów przerwań mi po prostu brakuje w sprzęcie. Tylko ja do swojego Linuksa mogę włożyć kartę z 16 kolejkami RX/TX i mi to zadziała.

@gotar: Nadal sie nie rozumiemy. Znaczy, mniej wiecej rozumiem, co probujesz powiedziec, natomiast niespecjalnie rozumiesz, o czym mowie ja. Wiec jeszcze raz:

Jakie znaczenie ma, do ktorego procesora zostaje dostarczone przerwanie, ktore poza obudzeniem wątku nic nie robi? W przypadku interrupt threads rola procedury obslugi przerwania – w sensie, tego kawalka kodu, ktory z punktu widzenia procesora wykonuje sie w przerwaniu w reakcji na sygnal z kontrolera przerwan – sprowadza sie do "wygaszenia" przerwania i obudzenia watku. Znaczy, dobrze jest to jakos rozrzucic po procesorach, ale nie ma to zadnego zwiazku z round-robinem pakietow ani w ogole czymkolwiek sieciowym, poniewaz rzeczy zwiazane z faktyczna obsluga urzadzenia dzieja sie zupelnie gdzies indziej – na przyklad w watku, ktory jest budzony, i ktory moze wykonywac sie na innym procesorze, jak kazdy inny watek.

Czy w Linuksie "threaded interrupt handlers" dzialaja jakos mocno inaczej?

@mangoo: Ja z kolei mowie o tym, ze twoje stwierdzenie, jakoby "z interrupt threads i wieloma procesorami mozna wresz byc pewnym, ze pakiety beda w zlej kolejnosci" dowodzi, ze wydaje ci sie, ze interrupt threads w systemach innych niz Linux dzialaja jak "threaded interrupt handlers" w Linuksie, ktory to mechanizm faktycznie – z tego co twierdzisz – moze byc "nieco" niedorobiony. No wiec tlumacze: nie.

Czy "threaded interrupt handlers", czy "interrupt threads" – zadne z nich nie zajmuje sie porzadkowaniem pakietow stosu sieciowego!

Wbrew temu co twierdzisz, do tego w kazdym systemie jest _odrebny_ mechanizm, czy to jest Linuks, czy inne, "uniksowate".

Cos niedorobiony jest twoj troll-mode.

@mangoo: Poguglaj dokladniej. Zadne "porzadkowanie pakietow" nie jest potrzebne.

@trasz: doskonale rozumiem co chcesz powiedzieć. Otóż w odpowiedzi na:

"Rozkladanie obciazenia sieciowego miedzy klika procesorow Linux mial od… zawsze?"

stwierdziłeś, iż:

"Nie mial, trzeba bylo przerwania bindowac uzywajac irqbalance’a."

co nie jest prawdą, jak wykazałem powyżej. Najwyraźniej więc zrozumiawszy ów fakt lub zignorowawszy go próbujesz niepotrzebnie zejść na temat "threaded interrupts" – te owszem, od workqueue różnią się właśnie tym, że mogą być wykonywane na innym CPU niż ISR, stąd jeszcze więcej różnic do taskletów i softirq. W Linuksie dokładnie tak to działa, chcesz jeszcze kilka linków?

I nie, nie wiem jakie sterowniki z tego korzystają – jak powinno wynikać z tego, co napisałem wyżej, dużo ważniejsza jest implementacja multiqueue, gdyż mając to …nie potrzeba TI. W Linuksie zrobiono zatem najpierw tę część ważniejszą, logiczniejszą z punktu widzenia inżynierskiego, a we FreeBSD najpierw dodano ulepszenia dla gorszego sprzętu. Wynika stąd, że obecnie oba systemy mają te same funkcje, ale to Linux pierwszy był dostosowany do dużych (profesjonalnych) maszyn.

Później skomentowałeś coś o działaniu APIC i odesłany do konkretnej strony książki na ten temat znów zamilkłeś.

Natomiast w odpowiedziach do mangoo wyczuwam, jakbyś uważał hashowanie pakietów za immanentną cechę TI – otóż nie jest tak. Mogę sobie wyobrazić dowolną implementację, zarówno z round robin jak i lowest priority czy random(), co mogłoby skutkować właśnie out-of-order.

Pomijając już fakt, że kierowanie programowe jest tylko obejściem na słabszy sprzęt, to wskaż odpowiedni kawałek kodu lub dokumentację – chętnie się zapoznam z możliwościami FreeBSD. Bo te wyliczenia numeru wątku to chyba nie są w ISR prowadzone, nie?

@trasz: jeszcze jedno

"Interrupt threads nic nie maja ani do pakietow out-of-order (skad to wziales w ogole?), ani z przetwarzaniem pakietow aplikacji na tym samym procesorze."

Dokładnie – zatem wskaż analogiczny mechanizm we FreeBSD.

"(Jestes pewien, ze rozumiesz, czym w ogole sa interrupt threads?)"

Ta rozmowa wygląda tak:

- Lubię cytryny, są tak genialnie kwaśne i wspaniale żółte.

- Moja kopareczka jest bardziej żółta!

- Ale jej sobie nie przegryziesz.

- Jesteś pewien, że rozumiesz, czym w ogóle jest koparka-zabawka!? Tego się nie je!

Fakt – o "interrupt threads" wspomniałeś już w pierwszym komentarzu. Tylko to było raczej nie na temat, więc "jak juz dojdziesz, do czego sluzy RPS i RFS" to powinieneś zrozumieć, że jest to zupełnie inna technika, niezależna od przerwań. Bo właśnie tymi swoimi przerwaniami nie dopasujesz pakietów do procesora, na którym wisi aplikacja je odbierająca.

Krótko mówiąc: przyjmij do wiadomości, że sensowne rozkładanie obciążenia między procesory to nie jest jakieś jedno proste hokus pokus, tylko cała gama komplementarnych metod. Aktualnie Linux ma zaimplementowane już wszystkie z nich – a ile ma FreeBSD?

@gotar: Duzo wazniejsze od sa interrupt threads, gdyz za jednym zamachem rozwiazuja cala mase problemow – upraszczaja locking, przy okazji umozliwiajac uzywanie pelnowartosciowych muteksow, co zwieksza skalowalnosc, likwiduja koniecznosc wylaczania przerwan (irqsave/irqrestore), ulatwiaja rozkladanie obciazenia, daja to, co dawalyby priorytety przerwan, gdyby byly i ogolnie sa fajne. Dlatego systemy inne niz Linux (i bodajze Windows) dorobily sie tego mechanizmu dawno temu, wywalajac tradycyjny model, nadal uzywany przez Linuksa, do kosza. RPS/RFS na systemach ze wspolczesnym modelem obslugi przerwan jest wazne, ale nie jest tak krytyczne dla wydajnosci jak w Linuksie.

Co do irqbalance – ok, prawdopodobnie masz racje. Nie wnikalem az tak gleboko – moja "wiedza" na ten temat konczy sie na zdawaniu sobie sprawy, ze ludzie naprawiali tym problemy z wydajnoscia. Zalozylem, ze problemy wynikaly z przybindowania przerwan do jednego procesora, a nie z losowego rozrzucania ich po roznych, no bo kto rozsadny implementowalby to drugie?

@trasz: dużo ważniejsze od interrupt threads jest multiqueue – jeśli nie napisałem tego wyraźnie.

RPS/RPF jest mniej ważny – zgadzam się. W Linuksie zostało to zatem zaimplementowane we właściwej kolejności, FreeBSD natomiast do dzisiaj ma wyłącznie interrupt threads.

Co do 'losowego' (dokładnie lowest priority z RR przy jednakowym prio) rozrzucania, to jak już wspomniałem zostało to zaimplementowane w sprzęcie, więc niezależnie jaki to OS, kwestia jest wyłącznie zaprogramowania APIC-a.

> Nie ma zadnego roundrobina. Kernel robi thread affinity, wiec watki obslugujace poszczegolne polaczenia nie lataja bez sensu miedzy procesorami.

Jak kernel może zrobić thread affinity w przypadku forwardowania pakietów, tak aby dany flow trafiał cały czas na jeden CPU? A może chcesz powiedzieć, że dla każdego flowa FreeBSD tworzy nowy wątek? Chyba nie…

> Co do kilku kolejek – FreeBSD to obsluguje, ale nie wiem, od kiedy dokladnie.

Strzelam: od wersji 8.0, wydanej pół roku temu? Czyli jakieś dwa lata po tym, jak pojawiło się to w Linuksie.

To teraz ponawiam pytanie: co się dzieje, jeżeli karta obsługuje mniej kolejek niż jest CPU?

A nie wiem, jakos sobie pewnie hashuje cztery numerki identyfikujace oba konce polaczenia i wyciaga z tego numer CPU.

> A nie wiem

To może sprawdź i dopiero wtedy pisz?

@trasz: "Co do ‘kojarzenia’ watku z procesem [...]"

to właśnie to, o czym nie masz pojęcia, załatwia RFS.

"Co do kilku kolejek – FreeBSD to obsluguje, ale nie wiem, od kiedy dokladnie."

http://lists.freebsd.org/pipermail/freebsd-net/20…

I dwa linki bonusowo:

http://lwn.net/Articles/324980/ https://patchwork.kernel.org/patch/19739/

@HQAW: Moze sam sprawdz, zanim oznajmisz, ze jest to niemozliwe? Powyzej podalem ci jedna z prostych mozliwosci.

@gotar: Pierwszy link jest z roku 2008. "Troche" sie od tamtego czasu pozmienialo.

Drugi sugeruje, ze Linux faktycznie dorobil sie jakichs "threaded interrupt handlers", tylko mocno fragmentarycznie – w sensie, sa "opt-in" i uzywane tu i tam zamiast byc podstawowym mechanizmem. Czyli calkiem prawdopodobne, ze maja jakies powazne problemy i ze ktos patrzacy tylko z perspektywy Linuksa moze uznac problemy implementacji za problemy z samym mechanizmem – tak bylo chociazby z Linuksowym devfs-em, na podstawie ktorego sporo osob uznalo, ze devfs jako taki to glupi pomysl.

Zwiazku z tematem trzeciego linka nie widze. Rozjasnisz?

@trasz: no przecież wiem, że z 2008 – znaczy to tyle, że FreeBSD na pewno było w tyle. W 7.0 nadal nie było, jak jest dzisiaj – nie wiem, teraz sam poszukaj.

Drugie – owszem. Razem z trzecim dostałeś niczym dwa nagie miecze, żebyś wojował z Linuksem (i przypadkiem nie wmówił mi kiedyś fanboizmu).

@trasz: poszukałem i jest mi niezmiernie przykro, FreeBSD 8.0 miało wyłącznie TX multiqueue (czyli to banalne w implementacji): http://www.freebsd.org/releases/8.0R/pressrelease…
Nigdzie nie mogę znaleźć informacji na temat RX, czyli możliwe, iż nie ma go do dziś. Jako że nie ma też RFS i – jak chyba twierdzisz, nie używa round robin do obsługi HI (bo to tylko jakieś upośledzone systemy i kulawe linuksiane implementacje), mamy obraz nędzy i rozpaczy…

Zatem jedyne co jest, to interrupt threads i domniemany analog RPS. Wszystko fajnie, ale ja wydałem 600 zł na kartę sieciową i chciałbym wykorzystać jej możliwości.

@gotar: Wydaje mi sie, ze najpierw powinienes zmierzyc wydajnosc pod jednym i drugim. Moze sie okazac, ze wydales 600 zlotych na sprzetowe obejscie niedorobek w systemie. ;->

No przecież pisałem. Pół roku temu wyszło FreeBSD 8.0. Jako jedna z innowacyjności to właśnie TX multiqueue dla karty zgłaszającej wiele przerwań. W sumie fajnie, tylko że:

1) ponad dwa latam po tym, jak obsługiwał to Linux

2) aktualnie obsługiwane są raptem 4 (!) sterowniki: em, ixgb, cxgb i mxgb. A gdzie np. Broadcom (bge, bce) ja się pytam?

2b) tutaj warto nadmienić, że FreeBSD do dzisiaj nie ma działającego sterownika do Braodcoma 10G (BCM57710/BCM57711/BCM57711E).

3) Wsparcie w em jest takie… słabe:

# grep -i multiqueue -A1 ./dev/e1000/if_em.c|grep *

** Multiqueue capable stack interface, this is not

** yet truely multiqueue, but that is coming…

*/

* This is not really Multiqueue, rather

* its just multiple interrupt vectors.

/* Multiqueue tx functions */

4) Wsparcie multiqueue w samym stosie ethernet jest umiarkowane: nie wspiera go pf, vlan. Wsparcie w lagg jest takie średnie.

5) rozwiązania typu RPS/RFS – brak.

Sorry trasz, przytrolowałeś na zły temat. Pokazałeś jedynie swoją niewiedzę i ułomność FreeBSD.

@HQAW: Patrz odpowiedz powyzej.

@trasz – całkiem możliwe, nie wykluczam, bo nie mam wystarczających kompetencji, żeby zrobić to czego potrzebuję na FreeBSD. Jeśli jesteś chętny do zrobienia eksperymentu i przygotowania takiego środowiska, to zapraszam.

Niemniej jednak, skoro ktoś zadał sobie trud wyprodukowania układu, który ma 846 stron dokumentacji, to przyświecał mu jakiś cel.

Pomaga, ale wtedy zmieniasz kolejność pakietów, czego nie wolno robić.

Ma to bardzo zły wpływ na UDP i High Speed TCP – zmniejsza wydajność, zwiększa jjiter, zwiększa zapotrzebowanie na pamięć RAM po stronie nadawcy/odbiorcy, powoduje dodatkowy ruch sieciowy, chociażby przez to, że SACK może akcować tylko ograniczoną liczbę obszarów, itd.

No niestety – doświadczyłem tego sam niecałe 3 tygodnie temu.

Wszystkie gałęzie są równe, ale niektóre są równiejsze.

No to już nie Linusa wina

Jak ktoś chce to nikt nie broni używać innych

@norbert_ramzes: Nie jest. Linus nie robi review patchy, ktore przez niego przechodza – zreszta przy takiej predkosci committow jakikolwiek review przez jedna osobe jest fizyczna niemozliwoscia.

@Reddie: Nikt poza Linusem nie moze committowac do glownego drzewa. Ergo, Linus robi za frontend do gita. W innych systemach tego problemu nie ma – dostep ma wiecej osob.

@trsh

A cos sie tak podniecił głównym drzewem? Git nie jest svnem.

Linus robi w jakimś stopniu review patchy (zdarza się że ich nie przyjmuje), chociaz głównie polega na zdaniu osób prowadzących dany podsystem.

@Edek: w distributed VCS nie ma głównego drzewa. Może jednak doczytaj?

@trasz 4 sierpnia 2010 o godz. 8:14 : Chyba nie masz na myśli systemów zamkniętoźródłowych. Tam po prostu jakiś komitet decyduje, że warto wydać jakąś wersję i tyle, więc dostęp do ostatecznego wydania ma 0 osób. Oczywiście wiem, czym się różni oficjalne wydanie od gałęzi dla programistów. Jest to jednak spowodowane tym, by Linus mógł wydać kolejną wersję wtedy, gdy uzna to za stosowne – w przypadku śmietnika najpierw należałoby zamrażać wszystko, przez co i tak dostęp miała by tylko jedna osoba lub jakiś komitet; komitet musiałby wszystko sprawdzić, co by opóźniło wydanie. Teraz nie ma takich problemów, bo każda łatka musiała zostać włączona przez osobę, która decyduje o wydaniu kolejnej wersji.

Spójrz na Debiana. Model rozwoju jest całkiem inny i mają problemy w związku z innym modelem. Ciągłe zamrażanie i odmrażanie kodu stwarza tylko problemy. W Linuksie główne drzewo jest ciągle zamrożone i to wszystko.

@ak47: Oczywiscie, ze jest glowne drzewo – Linusa. Jedyna roznica to to, ze nie jest to wymuszone technicznie, tylko organizacyjnie.

@Edek: nie jest niczym wymuszone.

Jak chcesz to możesz sobie utworzyć gałąź i merge'ować do niej inne. Możesz nawet zaprosić do tego kolegów. Jeśli efekt będzie dobry, ludzie zaczną tego używać. Póki co używają gałęzi Linusa, co oznacza, że daje on sobie radę a rzekome "wąskie gardło" występuje tylko w twojej wyobraźni.

@Reddie: Oczywiscie, ze moge – podobnie jak moge zrobic to w przypadku SVN-a, tylko szybciej – ale glownym drzewem pozostanie drzewo Linusa. Ludzie tworzacy dystrybucje beda tego, jako "waniliowego" i oryginalnego kernela, uzywac.

Ogolnie – postaraj sie troche mniej skupiac na swoich fantazjach, a bardziej na rzeczywistosci.

Oczywiscie, ze moge – podobnie jak moge zrobic to w przypadku SVN-a

Nie możesz. W SVN branche są razem z trunkiem w głównym repo.

Ogólnie – przeczytaj w końcu, czym różnią się distributed VCS od zwykłych.

@Reddie: Ogolnie – pouzywaj jakis czas jakichs VCS-ow zamiast zyc wiedzą forumową.

Edziu, czy chcesz przez to powiedzieć, że w SVN można tworzyć i udostępniać lokalne branche? :>

Ale co tu ma rodzaj VCS do rzeczy? Na upartego mogę sobie utrzymywać swoją linię Linuksa bez żadnego wersjonowania ręcznie aplikując diffy w notatnku.

@el.pescado: no właśnie to ma do rzeczy, że pozwala nie robić tego "na upartego". Nawiasem mówiąc właśnie tak działało wersjonowanie Linuksa przed wprowadzeniem BitKeepera

Kupiłeś klaptopa z windowsem? Wstyd!

Nie żaden wstyd tylko konieczność.

1. Nie znalazłem laptopa bez windowsa o odpowiedniej konfiguracji sprzętowej (odpowiedniej=wymarzonej). Wiem, że teoretycznie można odzyskać kasę za windowsa, ale ja nie mam siły i cierpliwości żeby użerać się z producentem (w dodatku nie ma 100% gwarancji że się uda).

2. Jestem w technikum i część programów (a raczej większość), z którymi miałem lub będę miał styczność nie ma wersji na linuksa i nie można ich odpalić pod wine np. Bascom AVR. Windowsa i tak odpalam tylko jak potrzebuje jakieś wyjątkowej aplikacji, a na co dzień pracuje na linuksie bo mi wygodniej (LXDE bez zbędnych bajerów lepiej do mnie przemawia niż interfejs Win7).

Tak więc widzisz w punkcie 2, że windowsa i tak musiałbym zainstalować. Następnego laptopa kupię najwcześniej jak skończę technikum (chociaż chciałbym żeby posłużył mi jeszcze dłużej). Podejrzewam że na studiach też będzie mi potrzebne oprogramowanie "only for windows" więc siłą rzeczy też będę musiał mieć lapka z tym systemem. Wychodzi, że laptopa bez windowsa kupię pewnie dopiero po zakończeniu kształcenia.

To może wolicie urzędowy język?

Jakikolwiek, byle:

1) zrozumiały

2) wiadomość w tym języku powinna być logicznie spójna i informacyjnie pełnosprawna.

Tutaj:

1. nie wiadomo co to "inne" (bo np. gdzieś raz piszesz o ext4, potem przerwa, a potem ext4 to przykład "innego"),

2. nie wiadomo co to "również" i co jeszcze "ucierpiało", bo odnosisz się do nieistniejącego wcześniejszego zdania. Na siłę interpretując pisałeś coś o ext4, ale tutaj to jest w grupie "inne", więc odpada.

3. nie wiadomo co to "ucierpiało". "Ucierpiało" to jest *jakaś* regresja, ale takiej informacji nie znajduję. Could you be more specific?

Reasumując, wartość informacyjna zerowa. A po prośbie o informację dostajemy nierelewantny link z końcówką "a w ogóle to sprawdźcie sobie logi".

Tak się nie robi newsów kolego. Po to Ci wskazuję błędy, byś mógł to poprawić.

Pozdro.

@aegis maelstrom – powinno być 'kartach graficznych' zamiast 'karty graficznej'. poza tym jest niekoniecznie pięknie stylistycznie, ale raczej poprawnie.

A najlepiej tak:

“Wsparcie dla sprzętowego dekodowania H.264 w zintegrowanej z procesorem 'Intel Ironlake' karty graficznej”