Dansk Linux-maintainer fjerner flaskehals i Linux

Nogen der ved hvor meget forbedring der er tale om i procent?

Dog er det et stort skridt fremad, ligegyldigt hvad.

Synes lidt det er en pseudo nyhed. Det er rigtigt, at man vil kunne få højrere hastighed på pipes, men man kunne jo bare bruge en anden form for IPC. Eks.
shared mem

Det var sku på tide.

Jeg har tit undret mig over hvorfor man ikke havde variable størrelser på pipes.

Thanks I say.

Jeg er ret overbevist om at %delen er forholdsvis stor hvis vi snakker ex. filservere.

Ikke på en desktop PC.

For nogle år siden var størrelsen af en pipe i Linux på en page, dvs. 4KB på de mest udbredte arkitekturer. Der blev så lavet en ændring der forøgede det til 16 pages, hvilket var en større ændring i hele pipe koden.

Størrelsen er i øvrigt ikke fast, den kan variere fra 1 til 16 pages. Men hvis den process der generere data er hurtigere end den der modtager det, så vil det altid ende med at pipe størrelsen er 16 pages.

Hvis der er nogen som betvivler hvordan det fungerer, så tag et kig på linux/fs/pipe.c

»Vi fandt frem til, at problemet måtte ligge i størrelsen af pipe’en, som vi så forsøgte at udvide. Men det kunne umiddelbart ikke lade sig gøre,« siger Anders Porsbo.

Alt hvad der skal til for at ændre størrelsen er at man ændrer PIPE_BUFFERS i linux/include/linux/pipe_fs_i.h fra 16 til noget større og recompilerer sin kerne. Det er ikke nogen god løsning hvis man ønsker meget flexibilitet, men det er altså ikke specielt svært at ændrer det fra 16 til 32 og så undersøge om det giver en målbar forbedring i performance. Hvis ikke man kan måle en forbedring fra 16 til 32, så er det ikke pipe størrelsen der er flaskehalsen.

Det skal på ingen måde forstås sådan, at den gamle kode er perfekt. DVD brænding bliver nævnt som et eksempel. Brændersoftware har længe implementeret sin egen buffer for at altid have nok at forsyne drevet med. Og der taler man typisk om en buffer på flere MB. Hvis man generelt tillader pipes store nok til at man kunne bruge en pipe i stedet for at implementere sin egen buffer, så ville man løbe ind i helt andre problemer. Der ville nemligt være mange pipes i systemet, som hver især ville bruge den mængde buffer plads til pipes. Og jeg tror ikke at pipe buffers kan swappes ud, så systemet løber hurtigt tør for RAM.

Man skal altså ikke lave sine pipe buffers for store, for det er en dårlig udnyttelse af RAM. Det ville selvfølgelig være smart, hvis man for hver pipe kan angive hvor stor den må have lov at blive. På den måde vil man kunne bruge mere RAM på de pipes hvor det kan betale sig. Der skal selvfølgelig også være en måde at kontrollere at ingen brugere kan sætte sig på for meget af systemets RAM til pipe buffers. Måske er det den slags ting som denne patch gør.

#1 Læste på Comon at det var omkring 50%.
Undskyld det var på V2

nomissenrojb (5) skrev:

#1 Læste på Comon at det var omkring 50%.
Undskyld det var på V2

Der står de fik 50% af den performance de håbede på. Det siger egentlig ikke ret meget. For det første ved vi jo ikke om deres oprindelige håb var realistiske. Der står heller ikke noget om, hvor meget hurtigere det bliver af flere buffers.

Desuden afhænger det optimale i høj grad af anvendelsen. I nogle tilfælde vil flere buffers hjælpe. I nogle tilfælde vil det være ligegyldigt. Og i nogle tilfælde vil flere buffers skade performance fordi applikationen så står og mangler den RAM et andet sted.