Ontwikkelaars geven versie 3.9 van Linux-kernel vrij

De ontwikkelaars van de Linux-kernel hebben versie 3.9 vrijgegeven. De nieuwe versie biedt onder meer experimentele ondersteuning voor raid5 en raid6 in combinatie met btrfs, evenals functionaliteit om ssd's als cache voor harde schijven in te zetten.

Versie 3.9 van de Linux-kernel is sinds maandag te downloaden vanaf kernel.org; geïnteresseerden kunnen de vers vrijgegeven kernelversie zelf compilen of wachten tot hij zijn weg naar de repositories van de Linux-distributies maakt. De nieuwe kernel-release maakt het onder meer mogelijk om een ssd als cache te gebruiken, zodat vaak geraadpleegde bestanden sneller laden. Daarnaast zijn veel nieuwe drivers toegevoegd.

Ook nieuw is ondersteuning voor raid5 en raid6 in combinatie met het nieuwe btrfs-bestandssysteem, al is die ondersteuning nog experimenteel. Daarnaast wordt het mogelijk voor verschillende threads om een socket op dezelfde poort te openen, waarbij het verkeer op die port gelijk over de sockets wordt verdeeld. Hierdoor kunnen bijvoorbeeld verschillende threads van een webserver los van elkaar op dezelfde port verkeer afhandelen. Daardoor zouden betere prestaties mogelijk moeten worden, vergeleken met een situatie waarbij één thread verkeer afhandelt en verdeelt over andere threads.

Verder is een nieuwe suspend_freeze-modus toegevoegd, waarbij alle componenten in slaapstand worden gebracht. Ze worden echter niet uitgeschakeld, zoals bij de klassieke standby-stand, waarbij alleen het geheugen actief blijft. Hoewel deze stand daarom meer stroom verbruikt dan de standby-stand, komt het apparaat wel iets sneller uit de suspend_freeze-modus, omdat de processors in een idle-toestand blijven en het bios wordt omzeild. Volgens H-Online kan de modus van pas komen in systemen die snel uit hun slaapstand moeten komen, of op apparaten die standby niet ondersteunen. Daarnaast zou de modus handig voor smartphones en tablets kunnen zijn.

Als de kernel-ontwikkelaars het ritme van de meest recente kernel-releases aanhouden, dan wordt versie 3.10 van de kernel in de tweede week van juni gepresenteerd. De nieuwe versie zal waarschijnlijk onder meer ondersteuning voor de Unified Video Decoder van nieuwere Radeon-kaarten bieden.

Reacties (23)

[Paul - K]

Daarnaast wordt het mogelijk voor meerdere threads om een socket op dezelfde port te openen, waarbij het verkeer op die port gelijk over de sockets wordt verdeeld. Hierdoor kunnen bijvoorbeeld meerdere threads van een webserver los van elkaar op dezelfde port verkeer afhandelen. Daardoor zouden betere prestaties mogelijk moet worden, vergeleken met een situatie waarbij één thread verkeer afhandelt en verdeelt over andere threads.

Misschien begrijp ik het verkeerd maar zou dit niet een enorme powerboost kunnen geven aan webservers als apache en ngix?

[ThomasG]

Ik verwacht het niet. Webservers als nginx gebruiken het Reactor pattern. Dit is in feiten een grote single-threaded applicatie, al kan het zichzelf forken over meerdere CPU cores. De hoofd lus wacht op eventen van het OS, dat er bijvoorbeeld informatie staat te wachten in de socket, dat het data kan lezen, etc. De single-thread kan zo effectief duizenden connecties te gelijk aan.

Bij thread-per-connection of fork-per-connection zou dit (met grote getalen aan bezoekers) fout gaan, omdat je een enorme overhead hebt door onder andere context-switching en geheugengebruik omdat elke thread een stack nodig heeft.

Je hebt ook nog het Proactor pattern, welke multi-threaded werkt. Het OS plaatst de gegevens van bijvoorbeeld de stocket in een gespecifieerde buffer. Maar dit zorgt voor meer geheugen gebruik, en is op Linux veel langzamer als je maar één CPU core ter beschikking hebt. Hier zou het een prestatiewinst winst geven, maar blijft het in veel gevallen alsnog langzamer dan het Reactor pattern.

Bij bijvoorbeeld real time game servers als voor FPS games, zou het wel kunnen werken. Omdat je daar met zo'n 64 spelers maximaal zit, en niet duizenden zoals bij een webserver. Of je moet geheugen bij prikken en misschien zelfs meer processor cores/kracht nemen.

Edit: Apache is trouwens wel thread-per-connection, maar als het aan komt op statische of gecachede pagina's, dan wint nginx het met een factor van twee cijfers. Apache daar en tegen is weer iets beter in het serveren van dynamische pagina's in bepaalde programmeertalen.

[Reactie gewijzigd door ThomasG op 25 juli 2024 08:30]

[RobertMe]

je een enorme overhead hebt door onder andere context-switching

Met deze wijzigingen zal dat dus komen te vervallen. Nu zal inderdaad de kernel de wachtende thread laten draaien waarna de wachtende thread een andere thread aanslingerd. Waarbij er inderdaad een extra context switch plaatsvind door het wisselen tussen de wachtende thread en de worker thread. Met deze wijziging heb je echter geen losse wachtende thread meer nodig, en kan elke worker thread dus zelf op de socket wachten, in plaats van dat daarvoor de losse thread nodig is. Daarnaast zal het extra geheugen gebruik door multi threading ook reuze meevallen. Op het moment dat de worker thread aan het wachten is zal deze namelijk ook een zeer kleine stack hebben. Alleen als de worker thread bezig is zal deze meer geheugen gebruik hebben, maar dat zal ong. precies hetzelfde zijn als dat hij heeft als bij een thread. Als de server bv. 10 requests moet afhandelen, en je hebt eentje die dat met 1 thread doet en een die dat met 10 worker threads doet zal het totale geheugengebruik in die tijd ongeveer hetzelfde zijn (op het beetje overhead van het bestaan van de extra threads na), alleen heb je bij een single-threaded oplossing wat langer meer geheugen vast.

Daarnaast kan Nginx ook voordeel hebben van deze wijziging. Want zoals je zelf al zegt gebruikt Nginx ook al meerdere threads, 1 voor elke core. Dus daar zal nu ook ergens een hoofd thread zijn die de load over de meerdere workers verdeeld. Waar dat met deze wijziging niet meer nodig is omdat de kernel zelf bepaald in welke request de connect request aankomt.

[Mr_Light]

Veel threads was vroeger een probleem, waardoor bepaalde aanpak (bv thread per connectie) nog al uit de gratie was geraakt.

Maar threads zijn 'goedkoper' en worden efficiënter gemanaged sinds NPTL is geintroduceerd. Waar het eerst al snel ophield bij 100-200 threads is nu 10k-20k threads geen probleem meer.

Combineer dit met het feit dat stack size voor een thread is instelbaar is. (bv Java -Xssn of via http://linux.die.net/man/2/setrlimit of ingeval van posix via de constructor) en de problemen zijn in eens beperkt.

(Overigens doet linux nog wat raars hier:

The default stack allocation strategy for LinuxThreads is nearly optimal: stacks start small (4k) and automatically grow on demand to a fairly large limit (2M).

dat on-demand kan niet voor fijne throughput zorgen, volgens mij doen daarom ze bij .net en java dit nog eens expliciet laten 'groeien' bij het creëren van een thread.

De voordelen van de thread per connectie aanpak is dat het makkelijk te programmeren is en te optimaliseren(door de runtime omgeving - prefetching, geheugen al/delocatie et al). Reactor zou afhankelijk wat je met de data van de connecties doet nog het snelste zijn maar afhankelijk van de situatie is het verschil dermate klein dat het in ieder geval geen performance hotspot is.

De feature zou voornamelijk tot doel hebben connectie afhandeling over meerdere cores gelijkwaardig te verdelen. Ben skeptisch overigens; immers afhankelijk van de data die binnen komt gebeuren er totaal andere dingen. Echter in de kernel space heb je waarschijnlijk betere informatie over de load op een core.
Het betreft deze commit en hier staat nog meer er over (van de maker).

//edit
het is puur het verdelen vaan het aantal accepts wat nu niet gelijk verdeeld wordt (soms 3 tegen 1) vanwege de unfaireness van de accept wake-ups. Dit gaat alleen helpen voor homogene workloads en misschien wel slechter voor hetrogene workloads

[Reactie gewijzigd door Mr_Light op 25 juli 2024 08:30]

[Infinitive]

Het is niet noodzakelijk een "thread per connectie". Het idee is juist om alle beschikbare cores in te zetten om de inkomende connecties af te handelen, in plaats van dit door maar een enkele core te laten doen. Het programmeermodel is dat je meerdere threads een verbinding op dezelfde socket kan laten accepteren (bijv. per core een thread). Onder de motorkap gaat dit echter veel verder: het volledige pad van netwerkkaart tot programma moet over verschillende cores kunnen lopen. Dat kan de kernel voor je doen wanneer je dit programmeermodel volgt.

Hoe de kernel dat precies doet is een andere vraag. Een jaar geleden heb ik een artikel gelezen waarin de auteurs een implementatie voorstelden en de nodige benchmarks gedraaid hebben. Daar werden o.a. load-balancing truuken gebruikt om de uiteindelijke verbindingen te laten afhandelen. Het lijkt me echter sterk dat zoiets binnen een jaar in de kernel geaccepteerd wordt, en ik neem maar aan dat de onderliggende implementatie wat minder geavanceerd is, maar dat door het beschikbaar stellen van het programmeermodel alvast de weg voorbereidt wordt om dergelijke implementaties te ondersteunen.

[Mr_Light]

Het thread per connection verhaal; richt zich meer op de opmerking van thomas

Bij thread-per-connection of fork-per-connection zou dit (met grote getalen aan bezoekers) fout gaan, omdat je een enorme overhead hebt door onder andere context-switching en geheugengebruik omdat elke thread een stack nodig heeft.

Het staat meerdere acceptors toe, wat ik begrijp kon dit al echter door het achterliggende meganisme zorgde het er doorgaans voor dat de ene acceptor 3 keer zo veel connecties te accepten kreeg dan een andere acceptor daar cores doorgaans nog homogeen zijn was de efficientie/utilisatie van de andere core maar 33% in slechte gevallen.

The problem with this technique, as Tom pointed out, is that when multiple threads are waiting in the accept() call, wake-ups are not fair, so that, under high load, incoming connections may be distributed across threads in a very unbalanced fashion. At Google, they have seen a factor-of-three difference between the thread accepting the most connections and the thread accepting the fewest connections; that sort of imbalance can lead to underutilization of CPU cores. By contrast, the SO_REUSEPORT implementation distributes connections evenly across all of the threads (or processes) that are blocked in accept() on the same port.

Dit is opgelost door (waarschijnlijk) Round-robin data structuur met sockets welke een port delen de houden en binnen komende connecties expliciet toe te wijzen. In tegen stelling tot de oude situatie waarbij de wachtende threads/acceptors zaten te dringen om connectie te bemachtigen.

De round robin aanpak welk simpel te implementeren is gecombineerd dat het feit dat er niet heel veel stuk kan gaan heeft waarschijnlijk geleid tot de 'snelle' toevoeging.

//edit
Kort samengevat, de flow of control is aangepast en de scheduling van connectie is van FCFS naar Round-robin scheduling veranderd. Verwacht in de toekomst een vorm van gewogen scheduling hiervoor waarbij de cpu utilization wordt meegenomen.

[Reactie gewijzigd door Mr_Light op 25 juli 2024 08:30]

[Mijzelf]

Dat zal wel de bedoeling zijn ja. Hoewel je dat 'enorm' waarschijnlijk kunt vergeten, het werk moet nog steeds gedaan, al is het nu van userland naar de kernel verplaatst.

[Vinnienerd]

Ik denk het niet, want de thread die de binnenkomende verbinding afhandelt spawnt sowieso een nieuwe thread hiervoor.

[sniek]

Waar we ooit wel eeuwig in de 2.6 versie leken te blijven hangen, is 3 en nu 3.9 snel opgevolgd...

Iemand al ervaring met die nieuwe poweropties? Die blijven toch al sinds alle tijden vrij brak in welke kernel dan ook...

[Verwijderd]

Er is een nieuwe driver (PowerClamp) geïntroduceerd welke idle percentage kan afdwingen om zo software-matig je CPU minder hard te laten werken.

That thread operates as a high-priority realtime process, so it is able to respond quickly when needed. Its job is relatively simple: look at the amount of idle time on its assigned CPU and calculate the difference from the desired idle time. Then, periodically, the thread will run, disable the clock tick, and force the CPU into a sleep state for the required amount of time. The sleeping is done for a given number of jiffies, so the sleep states tend to be relatively long — a necessary condition for an effective reduction in power usage.

Bron: lwn.net

kernelnewbies.org ligt momenteel plat vanwege de belangstelling vermoed ik.

[RedShift]

2.6 was de "stable" tree, maar Linus vond dat de ontwikkeling stagneerde omdat grote veranderingen op de lange baan geschoven werden om 2.6 "stable" te houden. Dus werd er gekozen voor een aggresievere release schedule en om versienummers dus sneller te "bumpen".

Maar goed, laat je dus niet leiden door versienummers, ze stellen niet zo heel veel voor en om de zoveel maanden gebeurt er toch een verschuiving. 3.8 is nu "stable*", 3.9 "mainline*" is een iets wat riskantere* versie

* Termen onder voorbehoud

Edit: grammatica

[Reactie gewijzigd door RedShift op 25 juli 2024 08:30]

[RobertMe]

3.9 is nu gewoon stable hoor. Ook met het ontwikkelprocess van de kernel is niks veranderd tussen 2.6 en 3. Door het snelle ontwikkelen (een release elke 1,5, 2 maanden), en op de achtergrond ontwikkelen van nieuwe dingen en toevoegen aan mainline ("dit wordt de volgende versie", dus niet wat jij zegt) als ze klaar zijn waren er nooit meer grote wijzigingen. Daardoor liep bij 2.6 de boel zo snel op tot 2.6.40. Toen is besloten om met het nummer opnieuw te beginnen met 3.0, maar aan de manier van ontwikkelen, wat stable en niet stable is, wat wel en niet in nieuwe versies mag komen ("grote wijzigingen") is absoluut niet veranderd. 2.6.49 zou dan ook net zo goed het versienummer kunnen zijn.

Er zijn dus ook geen grote wijzigingen geweest tussen 2.6.40 en 3.0, zoals jij beweerd. Er waren toen wel wat nieuwe dingen, logischerwijs, maar die nieuwe dingen zijn er met elke update wel. De keuze is toen puur gebaseerd op dat het nummer toch wel begon te worden, en dat het derde decennia aanbrak voor Linux.

[Dorank]

Helemaal correct, het stabiel/onstabiel verhaal stamt uit de pre 2.6 tijd waar even stabiel en oneven ontwikkel was.

In 3.x.y is x min of meer een snapshot vanuit features standpunt, y de bugfixes van deze specifieke branch.

Sommige x versies zijn bedoelt als long term supported voor de behoudende distributies, zo zal 3.2 wellicht langer supported worden van 3.4 doordat 3.2 in Debian/stable komt. Dat dit even nummers zijn is puur toeval, 3.6 en 3.8 zijn niet anders voor supported periode dan 3.5 en 3.7. Deze nummering zat min of meer ook in de 2.6.x.y reeks.

[Verwijderd]

Wie heeft hem al en weet oftie ook echt Goldfish support heeft ?

[7o9]

Volgens Kernel Log: Coming in 3.9 (Part 2) zit Goldfish support er nu in (onder kopje 'Processor support')

[wpoely86]

Goldfish zit erin.

[VW-Arjan]

Ben wel benieuwd naar de SSD caching functie voor "normale" harddisks.
Kun je toch simpel een snelle nas maken met intelligentie.

[MoonWatcher]

Het scheelt ook enorm in de kosten. Zeker voor de consument.
Een RAID controller met SSD ondersteuning is toch al snel vrij prijzig.

Natuurlijk ontstaat hierdoor een cap wat betreft de PCI bus maar dit is nog steeds meer dan snel genoeg voor de gemiddelde gebruiker.

[MoonWatcher]

"Daarnaast wordt het mogelijk voor meerdere threads om een socket op dezelfde port te openen, waarbij het verkeer op die port gelijk over de sockets wordt verdeeld"

Lees ik hier een vrij luie oplossing om single threaded applications te schalen op machines met enorme hoeveelheden cores?

[Amanoo]

Ik vind wat ze de sockets hebben aan gedaan tamelijk bizar. Is niet juist het idee dat een poort, en daardoor een socket op die poort, dient als applicatie identifier, of op meer technisch niveau een process/thread identifier? Het idee is juist dat Minecraft niet zomaar dezelfde poort kan gebruiken als mijn browser, zodat het altijd duidelijk/deterministisch is waar een pakket heen moet, aangezien er maar één mogelijkheid is. Dit gaat dat idee tamelijk in de war gooien. Bijzonder idee om in de kernel te bouwen.

[RobertMe]

Het gaat hier over threads. En een thread is intern tot een programma (een programma kan een X aantal threads draaien, die allemaal onderdeel zijn van 1 process). Wat jij zegt met dat programma X en Y dezelfde poort kunnen gebruiken is dus niet zo, omdat dit verschillende processen zijn, niet verschillende threads.

[MSalters]

Nee, dat laatste idee slaat nergens op. Apache webserver draait op poort 80, dus elk pakket is voor Apache, maar hoe Apache z'n threads gebruikt is een intern Apache probleem en geen OS zaak. Het OS moet de pakketjes tot de voordeur afleveren, en niet verder.

[Bastiaan V]

Dat is nu ook nog steeds het geval.
et wordt enkel op een andere manier afgeleverd (de tcp/ip stack zit gelukkig al een tijdje in de kernel)

Net als det een bedrijf meerdere postbussen kan hebben en de postbode de post al sorteert op postbusnummer.