The Secret to 10 Million Concurrent Connections

[Chromanoid]

The Secret to 10 Million Concurrent Connections -The Kernel is the Problem, Not the Solution

[Lynxeye]

The Secret to 10 Million Concurrent Connections -The Kernel is the Problem, Not the Solution

Ich weiß, dieser Thread hier ist nicht der richtige Platz um eine Diskussion anzustoßen, allerdings kann ich mich nicht zurück halten:
Jeder der ernsthaft eine Umgehung des Kernels und den direkten Hardwarezugriff aus dem Userspace als eine gangbare Lösung ansieht hat meiner Meinung nach seinen Kopf da, wo keine Sonne scheint.

Gerade der Linuxkernel hat in der Vergangenheit bereits sehr viele Verbesserungen zum Thema CPU lokale Bearbeitung von Paketen gesehen und z.B. Google ist da auch weiterhin stark dabei den Stack zu verbessern.

Zudem ist der Artikel mit halbwahrheiten und schlicht veralteten Informationen gefüllt.
- Pro Paket einen Interrupt? Schon seit 2003 besitzt Linux eine API um im Netzwerktreiber je nach Lastsituation zwischen Interruptbetrieb und Polling zu wechseln.
- Syscalls zur Implementation von Locks? Seit Jahren (einführung der NPTL) wird auch hier ein Hybrider (und transparenter) User-/Kernelspace lock verwendet. Solange die Threads auf einem Kern laufen wird der Kernel nicht angefasst.
- Die Pagewalklogik hat eigene Caches und hat nichts mit den CPU-Kerncaches zu tun.
- Bei entsprechender Einstellung des Kernels werden genügend große Allokationen aus dem Userspace automatisch mit Hugepages hinterlegt.

Der Vorschlag den Netzwerkadapter aus dem Userspace zu verwalten ist gefährlicher Bullshit. Die Kontrolle eines einzelenen DMA Geräts an den Userspace abzugeben heißt jegliche Sicherheit des gesamten Systems auszuhebeln.

[Chromanoid]

Naja es geht hier ja um Server und Geld... Ich verschiebe das mal gleich, weil ich das was du zu sagen hast wichtig und interessant finde.

[Sternmull]

Mich würde mal interessieren wie du (Lynxeye) zu so detaillierten Wissen zu dem Thema gekommen bist. Machst du das beruflich? Ist das bei der Untersuchung irgend eines Problems abgefallen?

Meine bisherigen Anläufe mich mal näher mit dem Kernel-Code auseinanderzusetzen sind schlicht an der Code-Masse und der (meinem Eindruck nach) zerstreuten/veralteten/dürftigen Dokumentation gescheitert. Deshalb würde mich mal interessiern wie du zu deinen Einblicken gelangt bist.

[Lynxeye]

Ja, inzwischen mache ich das Ganze beruflich. Ich bin zwar von meiner persönlichen Interessenlage den Multimediasubsystemen treu geblieben, werkle aber im Kundenauftrag auch an anderen Stellen im Kernel.

Bei der Dokumentation sollte man sich nur die ganz grundlegenden Sachen, welche nur sehr langsam veralten, ansehen. Ansonsten gilt für den Linux-Kernel: "the code is the documentation"; der Kernel wächst/evolviert einfach so schnell, dass jede Form von Dokumentation außerhalb des Sourcecodes dazu verdammt ist nicht auf dem aktuellen Stand zu sein. Der Einstieg in den Kernel ist etwas hart, da man ohne konkrete Probleme wohl kaum die Motivation findet einfach anderer Leute Code zu lesen und zu verstehen. Sobald man allerdings ein grundlegendes Verständnis der aktuellen Situation hat, wird es einfacher, da man nur noch die Veränderungen verfolgen muss. Jedoch ist selbst die dazu nötige Zeit fast nur aufzubringen, wenn man ein berufliches Interesse daran hat bzw. sonst nicht viele Hobbys.

[odenter]

Ich persönlich bin ja FreeBSD Fan (Ich finde die Dokumentation ist besser als bei allen Linuxen). Ich hatte mir mal das Buch "Designing BSD Rootkits" zugelegt. War damals ein netter Einstieg. Die Idee hinter dem Buch war Leute dazu zu bekommen sich mit dem FreeBSD-Kernel zu beschäftigen.
Ich habs nur mal aus Interesse gemacht, falls jemand einen Einstieg sucht und mal ein bischen schnuppern will, kann diesen Empfehlen. :)

"Standards" zu verwenden hat halt Vor- und Nachteile. Ich finde es grundsätzlich nicht verwerflich zu sagen ok wir haben ein Problem also bauen wir die Software so um das unser Problem beseitigt ist. Ich meine wenn jemand so etwas machen würde, dann wäre das eben hoch spezialisierte Software, im Beispiel wurden ja Telcos genannt, die erstmal nicht verwendet werden würde um z.B. Webserver oder FTP-Server zu betreiben, irgendwann aber vielleicht schon wenn es sich bewährt hat.