Linus Torvalds: Linux 2.6.35

Kernel

Linus tegnap bejelentette a 2.6.35-ös kernel kiadását. A bejelentésben közölte, hogy tetszett neki az a kicsit szigorított házirend, amelyet ebben a ciklusban alkalmazott, így folytatását tervezi. A soron következő ciklus alatt is szigorú lesz minden olyan patch-csel és git pull kéréssel szemben, amely a beolvasztási időablak bezárulása után érkezik.

Linus ezen kívül megjegyezte, hogy Andrew Morton néhány hete egész elégedetlen a linux-next fa stabilitásával, ezért arra kéri a fejlesztőket, hogy ne tekintsék azt afféle szemétlerakónak, ahova bármit be lehet szórni. A linux-next-be olyan dolgoknak kellene lennie, amelyek többé-kevésbé (a hangsúly a "többé"-n van) beolvasztásra érettek. Így ha valakiben kétség merülne fel a saját munkája stabilitását illetően, az azt jelenti, hogy a munka nincs még készen a beolvasztásra, nem fog a következő beolvasztási ablakban Linus elé kerülni, következésképpen nincs helye a linux-next-ben.

Kicsit vidámabb megjegyzésként Linus közölte, hogy reményei szerint a következő beolvasztási periódusban beemelésre kerülhet Nick Piggin frankó, VFS skálázhatóságot célzó patchsorozata. Linus egy ideje már használja a saját gépén. Megjegyezte, hogy ritkán látunk a core kódban jól látható, nagyobb teljesítménybeli javulást, éppen ezért egész izgatott Nick munkájával kapcsolatban.

A 2.6.35-ös kernel újdonságairól a KernelNewbies szokásos összefoglalója elolvasható itt.

A bejelentés elolvasható itt.

( trey | 2010. 08. 02., h – 10:47 )

A Nick Piggin-féle VFS munkáról:

"Nick claims "great" open/close scalability, and "good" create/unlink scalability. He showed the results of running a microbenchmark which just did close(open(path)) repeatedly; with current mainline, he was able to get 450 operations/second on each of 64 CPUs. With the scalability patches added, that rate went up to over 300,000 operations/second - a significant improvement. Running unlink(creat(path)) shows better scalability even with two CPUs - but it does, for some reason, impose a cost on single-threaded workloads on the ia-64 architecture. "

További részletek itt.

--
trey @ gépház

"An 8-core server with a tg3-based network interface went from 90,000 transactions per second to 285,000"

Egy desktop géppel (egy Pentium D CPU, még a régi P4-es érából, broadcom chippel, vsz. hasonlóval, mint a fentinél) két éve mértem kb. 500kpps forwarding teljesítményt csomagvesztés nélkül, és 7-800 kpps-t némi csomagvesztéssel.
Nem Linuxszal, FreeBSD-vel. Egy nyolc magos szervertől 285kpps ennek fényében elég szánalmasnak tűnik.

suckIT szopás minden nap! Android 2.2: használhatatlan

+1

Forwarding-al még az OpenBSD is tudja a 300kpps-t.

Zorp-al (ami proxy, szóval minden csomag kiesik userspace-be) szintén egy 8 core-os gépen nekem kb 90Kpps volt (és nem az userspace cpu fogyott el) a csúcs ha ez csak duplázódik az igen durva eredmény.

Szerk: Javasolt még a témában: http://vger.kernel.org/~davem/davem_nyc09.pdf

Ebben kétségtelenül igazad van, ez pedig már nem csak a kerneltől, hanem az alkalmazástól is függ.
Találtam egy ilyet:
http://arwen.ics.muni.cz/~hopet/FreeBSD/7.0-netperf/
határozottan nem mai, és itt is 300 kpps-ről ír (100B-os csomagokkal). Sőt, ha jól látom, a Linux rá is ver alul (erre számítanék).

Szóval ez a 90k nagyon kevésnek tűnik.

suckIT szopás minden nap! Android 2.2: használhatatlan

De nem sokat csinál a csomagokkal.

Itt egy real app teszt:

http://haproxy.1wt.eu/10g.html

Érdemes lenne futtatni FreeBSD-n is, bár a haproxy épít a tcp splice-ra nem tudom FreeBSD-n van-e splice() -hez hasonló rendszerhívás.

Egy kiemelés:

We measured 8.55 Gbps of HTTP traffic, and the network monitoring tools have measured 9.2 Gbps of ethernet traffic on the 1500-byte MTU interface (that was 746000 packets per second).

Eközben a system CPU terhelés 15%!! körül volt. Szóval mit is állapítottunk meg :): Jó ez a Myricom ethernet kártya.