WeiXiao
2019-05-24 18:33

I/O Is Faster Than the CPU – Let’s Partition Resourcesand Eliminate (Most) OS Abstractions

https://penberg.org/parakernel-hotos19.pdf

https://news.ycombinator.com/item?id=19818899

czysteskarpety

Obecnie to mam wrażenie, ze sytuacja się odwróciła i to sprzęt czeka na soft, kiedyś w erze szczególnie wolnych HDD było odwrotnie, obecnie dokładanie szybkich SSD już właściwie nic nie zmienia.

czysteskarpety

@WeiXiao: No, z tym, że pomimo porażającej liczby IOPS, jak pisałem, niewiele to zmienia w testach realnych, coś jak pixele smartfonowych aparatach, czy dodatkowe rdzenie, soft już tego nie wykorzysta.

jarekr000000

@WeiXiao: Immer wenn ich auf deutsch etwas lese, nehme ich an - es blöd ist

WeiXiao

@jarekr000000: posttraumatische belastungsstörung rückblenden? :)

nalik

Akurat pracują przy data plane, to że stos sieciowy jądra jest powolny to powrzechnie znany fakt. Producenci dedykowanego sprzętu od dawna pomijają stos sieciowy jadra. Co innego w przypadku hypervisorow i działających na nich klastrów kontenerów. Jądro nadzorcy pomija się przez SRIOV, jak słusznie zauważyli, ale potem pakiety i tak trafiają do jądra hosta. Tylko szkoda, że to research, a nie inicjatywa dostawców. Do tego żeby to miało sens, to w typowej zwirtualizowanej serwerowni potrzeba porgramowalnych kart sieciowych. No i trzeba wyprzeć Linuxa z całą bazą oferowanych narzędzi, który na pewno też będzie starał się zaadresować problem. Do tego pozostaje kwestia kiedy taki system będzie na tyle stabilny by ktoś zechiał go wdrożyć. Dlatego dopóki to projekt uniwersytecki, a nie coś wspieranego przez branżę, to myślę, że skończy się na paru publikacjach z zakresu OS i jakimś prototypie.

vpiotr

TL;DR. Jakiś skrót dla zabieganych? Chodzi o to żeby mieć partycje mainfrejmowe na PC? W czym to jest lepsze od KVM czy VirtualBoxa?

nalik

@vpiotr Można tak to ująć. Odniosę się tylko do stosu sieciowego. KVM i VBox ciągle korzystają z implementacji stosu w jądrze. Pakiety najpierw lądują w jądrze, gdzie są składane, by potem trafić do userspace. Raz, że to jest już jedna kopia, dwa, że wymaga syscalli by trafić do userspace, które tanie nie są. Do tego jądro ma swoje problemy ze skalowalnością ( https://lwn.net/Articles/787754/ ). Niby nic, ale co jeżeli chcesz postawić w swojej chmurze węzły przez które przechodzi ruch, jak na przykład firewall, CDN, router (bo np. robisz sieć nakładkową), etc? Do tego obecnie telekomy chciałby budować infrastrukturę na rozwiązaniach zwirtualizowanych i kubernetes ( chociażby cała koncepcja NFV: https://en.wikipedia.org/wiki/Network_function_virtualization ). Wprowadzasz wąskie gardło i jedyne na co możesz liczyć, to że dostawca ma to już rozwiązane (nie zawsze jest to prawda, a niektórzy jak telekomy budują centra danych samemu korzystając z gotowych rozwiązań). Obecnie mowa o sieciach 400Gbps (50 GBps), okazuje się, że obecnie nie ma szans obsłużyć tego w klasycznej architekturze. Architektóra, w której samemu programujesz kolejki karty sieciowej i tworzysz po jednym wątku/procesie czytającym bezpośrednio z kolejki, pomijając jądro, jest realizowalna ( https://www.slideshare.net/garyachy/dpdk-44585840 ), ale wymaga wsparcia ze strony sprzętu i dedykowanego systemu z uprawnieniami (ale nie zrobisz tego już w generycznym klastrze kontenerów) i w zasadzie bezużyteczna dla współczesnych "aplikacji" (chyba, że robić coś w tym stylu: https://martinfowler.com/articles/lmax.html ), co ogranicza jej zastosowanie do dedykowanego rozwiązań. Nie znam się na mainframe, ale z dyskusji na hacker news wnioskuję, że podobny problem był kiedyś rozwiązany, ale odszedł w zapomnienie z powodu ery x86.