Názory k článku
Linus Torvalds dává Bcachefs ultimátum
-
Jaké jsou dnes big endian stroje? Mám doma PowerPC G4 (Apple notebook/macOS a PC desktop/Windows NT), ale obojí je jednojádro, 1.3GHz (ten desktop je polovina, myslím, že jedno z prvních PowerPC) a 133MHz sběrnice (ten G4). Už v roce 2005 byla ta G4 dost pomalá proti Core 2. To by se autor moderního SW nedočkal kompilace a testů. Modernější je ten Blackbird s POWER9, ale to stojí od 80 tis. Kč a výkon dnes taky žádná sláva.
7. 10. 2024, 11:26 editováno autorem komentáře
-
Viz níže, všechny architektury mají už dlouho instrukci pro swap bajtů, takže tohle problém není. Limitem je najít CPU arch, kterou QEMU zvládá dobře (příklad taktéž v odkazovaném příspěvku). Pro zajímavost, emulace x86 mi jede na PowerPC G4 na 1/3 nativního výkonu (mám na notebooku Apple z roku 2005 v emulaci Windows 2000 a 98).
-
Nejrozšířenější big endian architektura je asi s390x. Na modernějších PowerPC se spíš přechází (nebo spíš už přešlo) na ppc64le.
Tady je ale podstata v něčem trochu jiném; to, že ten patch zrovna rozbil build na big endian architekturách (protože změnil název prvku struktury jen ve variantě deklarace pro little endian a ve variantě pro big endian nechal původní), je spíš náhoda. Problém je, že šlo o patch, který nic neopravoval ani nevylepšoval z funkčního hlediska, a přesto byl na poslední chvíli přidán na konci merge window, aniž by prošel aspoň mailing listem nebo byl aspoň pár dní v nějakém veřejném stromu. A z té diskuse je zřejmé, že nejde o mimořádný úlet, ale spíš standardní režim práce, a že Kent Overstreet odmítá připustit, že je to špatně.
Pro srovnání: v síťovém subsystému, se kterým mám přeci jen víc praktických zkušeností, by se takový patch musel dostat do net-next ještě před vydáním 6.11 final, protože pak se net-next uzavře a další patche, které nejsou opravy, se přijímají až po skončení merge window (a jdou do dalšího cyklu). Takže i kdyby tam přišel úplně na poslední chvíli, pořád by byl asi tři dny v net-next, kde by prošel mnoha testy, a pak další týden a půl v mainline, než by se objevil v 6.12-rc1.
-
Přemýšlel jsem přesně o tom samém. Z hlavy mě napadají tak maximálně 2-3 příklady, Leon2/3 (ESA cpu pro vesmírné projekty, vlastně ani netuším zda se někdy fyzicky realizoval), pak IBM Z-System, ale tam zase netuším proč by na tom někdo chtěl provozovat Linux místo Z/OS a jako poslední mě napadá, že i moderní ARM se dá nabootovat jako Big-Endian, ale opět mi chybí důvod, proč by to někdo dělal (někde jsem viděl návod na Nvidia Jetson)
-
... a jako poslední mě napadá, že i moderní ARM se dá nabootovat jako Big-Endian, ale opět mi chybí důvod, proč by to někdo dělal (někde jsem viděl návod na Nvidia Jetson)
Duvod?
Nemela by sitarina bezet na BE strojich lepe, kdyz vetsina, ne-li vsechny sitove vrstvy maji struktury v BE formatu?
Jako ty ntoh()/hton() swapy v modernich cpu zaplni urcite uops bubliny, ze to neni prace navic - ale stejne.. treba by to melo mensi spotrebu?
Diky za tip na BE Jetson (a dalsim k obecnemu aarch64).. takovou divocinu musim zkusit :)
-
BSWAP instrukce už byla na 486.
PowerPC umí přes nativně BE datový segment namapovat alias v little endianu.
Z jednoho segmentu se zapisuje a čte v BE formátu a skrz alias v LE formátu, konverzi reší HW transparentně a nic navíc to nestojí.ARM má instrukci REV.
MIPS má WSBH.
SPARC žádnou podporu pro LE neměl, bswap se musel rozepsat na shifty.Největší brzdou na RISC architekturách jsou nezarovnané struktury, to je horší jak BE/LE.
-
Tak Leonů a dovozených procesorů ve vesmíru léta hodně. Přehled procesorů
https://www.gaisler.com/index.php/products/processorsPřehled součástek na křemíku
https://www.gaisler.com/index.php/products/componentsZajímavostí je pak osmijádrový GR765, kde se pinem na začátku přepíná, jestli naběhne jako Noel-V (RISC-V) nebo LEON5FT (SPARC)
https://www.gaisler.com/index.php/products/components/gr765Jinak mnoho implementací bude i na FPGA, ale ty téměř jistě nemá smysl provozovat s GNU/Linuxem. Bude to pomalé. I ty na křemíku budou většinou s RTOS RTEMS https://www.rtems.org/.
Ale určitě má být kód otestovaný. CAN FD driver k CTU CAN FD IP core jsem před posláním do mainline testoval v buildech x86_64, ARM (několik) a MIPS v QEMU s využitím mnou spravovaného QEMU CAN subsytému. Ano, dalo to trochu práce najít kombinaci MIPS big-endian architektury rozumně podporovanou QEMU až po PCI a pak i nějakou kontrolu naší emulace CTU CAN FD přes PCI na big-endian systému. Ale file-system driver je jednodušší, tam není potřeba podpora HW, stačí třeba i jen soubor v ramdisku použít přes loop a vše lze otestovat, tedy do nějaké rozumné velikosti FS. Ale ve velkém to jde na x86, protunelovat velký image i do MIPS, ARM atd ale také nebude problém.
Takže problém bude opeavdu asi v přístupu autora a je otázka, jestli takto spravovanému FS svěřit svoje data.
-
Existuji u nas v CZE i na SVK zakaznici, kteri IBM Power9 normalne pouzivaji s aktualnim AIXem 7.3 a bezi na nich napr. Informix Database nebo 4GL programy apod.
Zadna anomalie to neni, jsou to extra vykonne a hlavne stabilni servery spolecne s PowerVM virtualizaci (VIOS).
Jeden takovy (nejsilnejsi) spravuji, ma 128 vCPUs, 750 GB RAM, par desitek TBs diskove kapacity...
Kazdopadne dle AI uz od Power8 umi tyto masiny i LittleEndian (pro lepsi kompatibilitu s okolnim infra).
-
Pro zajímavost, PowerPC mělo podporu Little/Big Endian, ale POWER ne, ten až o dost později, jak vám řekla AI. Proto byl problém s PowerPC G5, který už byl z nedostatku lidí, financí a nálady odvozen od serverového POWER, a ten v té době little endian neuměl. Trvalo dost dlouho, než lidi zprovoznili emulaci x86. Myslím, že i s několikanásobně větším výkonem G5 oproti G4 to nejelo rychleji. Já mám doma iBook G4 s Microsoft VirtualPC, a v něm Windows 2000 a 98, a první PowerPC (šest set něco) s Little Endian Windows NT. Nemám žádnou G5, abych to porovnal. To jen pro info, že výše Marvin píše, že je PowerPC je LE-přátelská architektura (neplatí pro G5).
-
No nejen s Linuxem, ale ještě s polední verzí jádra a s divočinou jako bcachefs, aby je takovýhle problém poškodil.
Nicméně Linusovi jde o princip, pokud jsem to pochopil správně. Teď nad tím mávne rukou, a za půl roku z tohohle přístupu bude kernel panic na polovině používaných zařízení.
8. 10. 2024, 07:44 editováno autorem komentáře
-
Nemusel by mít celou distribuci zkompilovanou pro BE? Dle https://stackoverflow.com/a/55945594/15717902 asi jo.
-
Stačí zkompilovat nějakou LibC, i GlibC jde nebo jí lze stáhnout z libovolné distribuce, která danou architekturu podporuje. Pak se zkompiluje https://busybox.net/ . Případně ho lze zkompilovat i přímo proti klibc, která vypadne z buildu jádra. Pak stačí malý initramfs a vše naběhne. Můj testovací initrafs for x86 má pod 4 MB, pro ARM 32 o kousek více, pro MIPS jen asi 3.3 MB a pro RISC-V pod 3 MB. Záleží, jaké moduly jádra a něco málo na víc k BusyBoxu si tam přidám.
Příklad jak z běžící distribuce Debian připravit QEMU initramfs tak aby rozjel aktuální jádro v HW virtualizaci a pak v něm rozjel tu původní distribuci tak, že v ní má uživatel roota a svůj reálný domovský adresář jako RW mout zde
https://github.com/ppisa/qemu-utils/blob/master/qemu-run-trick/qemu-setup-and-run
Možná je v skriptu již něco zastaralé a vůbec neručím za to, že Vám nesmaže, neponičí Váš domovský adresář. Ale Debian 12 bookworm mi teď na kontě tmp najel. Musel jsem akorát vykomentovat KVM, protože to na mém počítači nemá uživatel tmp povolené. Pro su bez hesla používám v /etc/pam.d/su
auth [success=ignore default=1] pam_succeed_if.so user = tmp auth sufficient pam_succeed_if.so use_uid user = skutecny_login_name
-
Asi z historických důvodů. Dlouho byly ALU jednotky drahé, takže se operace s větší šířkou čísel dělaly na více kroků. Ať už programátorem (32 bit čísla na 16bit CPU, 64bit čísla na 32bit CPU, 8bit čísla na 4bit Intel 4004), nebo mikrokódem (8bit čísla na Zilog Z80 s 4bit ALU, 32bit čísla na Motorola 68000 - až 020 měla 32bit ALU):
-
BE na postupné sčítání právě vychází špatně. Potřebujete začít ADD na LSB a pak ADDC (s přenosem carry) na vyšších bytech. Tedy pokud proměnné na adresách v ukazatelích začínají LSB (tedy little-endian), tak to vychází lépe. U BE je nutné nejdříve přičíst délku operandu a pak načítat s predekrementem... Naopak big-endian vychází lépe při porovnávání, tam stačí začít od MSB a při první neshodě je jasné, jaká je relace. MSB by mohlo mít smysl na sítích, kde by se v routeru mohlo začít směrovat již podle prvních přijatých bitů adresy (pokud maska nižší zcela ignoruje). Pro běžné 32 bit IPv4 a asi i pro 48 MAC je to jedno. Pro 128 bitů IPv6 by to trochu smysl mít mohlo. Ale většinou se přijímá asi celá hlavička a v případě zaplněného výstupního portu je nutné stejně uložit celý paket a pak ho vyslat znova z bufferu. Ale pro low latency TSN a nebo nějaká time-triggered řešení by BE mohl mít smyl a zrovna díky SUNu a SPARCu a dalším je network order pro RPC a IP adresování tvrdě big-endian. Zde tedy mají little-endian trošku nevýhodu. Naopak ta multiprecission aritmetika vychází většinou na little-endian lépe. Dnes si myslím, že je to spíše jedno a díky převálcování mnoha systémů Intelem a jeho little-endian je dnes častá situace, že s BE jsou problémy a plikace na něj nejsou otestované. Takže LE nakonec vychází jednodušeji. Zároveň třeba PCI a PCIe jsou v základu little-endian a tak klasická pultová síťová karta v BE systému bude vyžadovat otáčení endianingu a znamenat určitý overhead. Na PowerPC se to ale vyřeší i v BE případě mapováním a instrukcemi...
