Jaderné noviny – 30. 8. 2012: Jaderný summit 2012 (diskuse)

[pc2005]

H. Peter Anvin

[joke] Osobně bych odstranil všechen x86 kód [/joke]

Kdyby existovala udržovaná větev pro tyto systémy, tak bych řekl skoro bez zaváhání Ano, ale i386 systémy pořád mohou existovat. Například jako opencore projekty a tam není jistota, že někdo implementuje pentium like core. Jinak 386 se od 486 liší minimálně (jen podpora writeback cache a CPUID u některých modelů a asi dvou až tří užitečných instrukcí), takže vyhození i386 by se mohlo dotknout i 486 strojů, což bych nerad, protože 486 je z x86 můj nejoblíbenější model (relativně. Absolutně je to fušeřina ). Hlavně tu taky pár 486 strojů mám a nejsou zrovna zakonzervovaný ve vitrínce.

[Michal Kubeček]

podpora … a asi dvou až tří užitečných instrukcí

Jednou z nich je ale cmpxchg, která je zrovna dost důležitá.

[pc2005]

Proto "dvou až tří užitečných instrukcí". Ale přiznávám, neměl jsem zavrhnout původní rozvedení včetně cmpxchg.

Atomické operace jdou i bez ní (narozdíl od non x86).

Otázka jak moc je cmpxchg užitečná v porovnání s pentiáckou cmpxchg8, jejíž existence je tuším jeden z důvodů, proč Win XP nejede na 486.

[pc2005]

P.S. Taktéž bychom mohli zavrhnout všechny <i686, protože cmov je tak sexy .

[R]

CMOV nemaju ani niektore 686 CPU, napr. starsie VIA C3...

[bohyn]

Pak se ale nabizi otazka jestli je to i686 CPU

[Ales Hakl]

No rozumna odpoved je, ze neni, ale. Opravdu stare C3 vraci z CPUID family = 5, tedy i586, ty ktere cmov uz umi vraci 6 jako i686. Ovsem mam takove podezreni, ze existuji procesory z nejake mezidoby, ktere sice vraci 6, ale cmov neumi. (spravne se stejne podpora CMOV ma poznat podle cpuid level 1 a patnacteho bitu v EDX, ale to je vec druha)

[Michal Kubeček]

Zvláštní, to bych spíš čekal, že bude někdo vyžadovat xchgadd.

[pc2005]

To je k těm XP? Jestli jo tak tohle.

[Michal Kubeček]

Do vnitřností XP nevidím, takže jsem to komentoval jen na základě toho, k čemu se jednotlivé instrukce mohou hodit.

[frr]

XP nejedou na 486? V tom případě Vortex86DX je asi o něco víc než 486, protože na Vortexu (DX, 600 MHz - 1 GHz) XPčka v zásadě chodí Nojo fakt:

flags : fpu tsc cx8

[Bůh Entony]

Otázkou zůstává, jak by se zachovala instalace Windows XP ve VMware nebo jiném virtualizačním nástroji, kdyby bežela na 386/486ce v Linuxu

Myslíte, že by dovolil vmware Xpečkům ošahat si procesor nebo dokáže tyto rozšíření nějakým způsobem emulovat a instalace by pokračovala dál jako by se nechumelilo? :) Já myslím, že by též zkiksovala :)

[pc2005]

Vmware nevím, ale qemu dokáže spustit win95 na armu, takže asi výrazně emulovat bude.

[stativ]

Až na to, že VMware je virtualizace, kdežto qemu je emulátor (který shodou okolností dostal i podporu virtualizace).

[pc2005]

Jenom virtualizace? Tak to pak asi nepojede, například kámošovi nešel virtualizovat ve VirtualBoxu win8, kvůli VT-x.

[stativ]

U VMware je to trochu složitější. Staré verze uměly virtualizovat na HW bez podpory HW virtualizace, což bylo pomalejší než HW virtualizace ale běželo to docela slušně (sám jsem to tak pár let používal na Pentiu 4). Samozřejmě guest musel používat stejnou architekturu CPU jako host. Relativně nedávno (asi tak rok, dva) tuhle možnost odstranili a teď VMware vyžaduje, aby CPU měl podporu HW virtualizace.

Qemu kromě podpory virtualizace přes KVM/Xen má navíc podporu emulace, kdy se prakticky všechno provádí hezky softwarově, a je to tedy líné jako šnek.

[Jendа]

Například jako opencore projekty a tam není jistota, že někdo implementuje pentium like core.

Proč by open-source procesor implementoval zrovna x86?

[trekker.dk]

IMO opencore procesor znamená procesor napsaný (třeba) ve VHDL, který potom nahraješ do nějakého FPGA. Tzn. zrovna x86, protože potřebuješ zrovna x86.

[pc2005]

Mě se ptej . (+ spousta 8080 implementací)

Nicméně (viz zet86) je otázka zda se někdo odhodlá k plnému 386 (32b, stránkování, chráněný mód). Protipříklad, takovej Vortex prej dělal i586 kompatibilní procesory, ale bez FPU, což je stav stejný jako u 386 nebo u hodně prvních 486.

[Spike]

Ty 486 (na 300 MHz!) bez FPU od Vortexu používáme. Ale ten SoC je strašná tragedie, hlavně IDE řadič...

[frr]

Tohle mě zajímá - nějaké konkrétnější poznámky k tomu IDE řadiči by nebyly?

Podle mých zkušeností asi žádný rychlík, ale kompatibilita s disky pokud vím OK (lepší než třeba Geode). Svého času RDC R1010 v rámci Vortex86DX vyžadoval pro XP F6 floppy, nová revize hardwaru zvaná RDC R1011 už je natolik generické IDE, že F6 floppy nepotřebuje. Pod Linuxem to tuším chodilo skrz ide_generic odjakživa, a taky se na to chytal ovladač it821x (pro R1011 snad dodnes neobsahuje PCI ID, ale když IDčko do zdrojáku rukama přidáte, tak normálně funguje). Všiml jsem si ve zdrojáku it821x.c nějakého workaroundu pro Vortex/RDC R1010, jako že cosi nefunguje jak má... Funguje UDMA - co do průchodnosti je brzdou spíš jádro CPU než zrovna IDE řadič (zejm. u Vortex86SX). Na to že celý motherboard žere 5W mi to jako tragédie nepřipadá.

[Spike]

Jo ty hardwarové revize... s těmi jsme si taky užili. Ty novější desky jsou skutečně lepší, ale s tehdejším opatchovaným kernelem 2.6.18 (podle dokumentace od Číňanů) ten starý V1 hardware byl dost citlivý na nastavení DMA a vůbec konkrétní model CF karty (nejlepší bylo, když výrobce, třeba Kingston, pod stejným produktovým kódem začal prodávat úplně jiné karty), bylo třeba různé harakiri s boot parametry, hdparm.

Ještě jsem zkoušel nějaký tehdy aktuální stabilní kernel z Debianu 5.0 (nebo to bylo něco z bpo?), ale pořád jsem měl s IDE problémy.

Tu DX variantu jsem v rukou neměl, ale práce s RB-262SXV2 (ale hlavně ještě tedy s V1) mi přišla dost otravná.

Jestli máte nějaké čerstvé zkušenosti, jak na tom pohodlně rozběhat třeba trochu aktuálnější distro (v podstatě jediný požadavek je, aby tam běželo nějaké Oracle/OpenJDK JRE a monit, z hardware akorát IDE (CF) a Ethernet), třeba Debian nebo Tiny Core Linux nebo něco podobného, rád se na to zkusím ještě podívat.

Bezpochyby je to rukama (žádný kernel developer nejsem, i když přidat ID do driveru bych ještě zvládnul :)), ale i se strýčkem Googlem to tehdy bylo asi nad moje síly dotáhnout do 100% uspokojivého konce.

[frr]

Hmm... asi jsem opravdu potkal Vortex v tu pravou chvíli, kdy se víceméně zbavil nejhorších dětských nemocí.

Vortex86SX zajisté potřebuje kernel s emulací mat.koprocesoru, což v dnešních distrech tuším už není běžné (ani v Debianu). Takže instalace Linuxu potenciálně znamená, nastartovat instalátor s custom kernelem. Což se dá, dokonce několika způsoby. Já osobně si už pár let skládám svoje vlastní pidi-distro ze součástek staré Fedory (i386), takže na procesorech kategorie "x86 kozí dech" s tímhle vcelku nemám problém...

Pokud se týče IDE, tak R1010/R1011 lze zprovoznit i bez it821x.ko, pouze na bázi ovladače ide_generic - je vhodné použít kernel cmdline argument ide_generic.probe_mask=0x03 (apod.) aby se ide_generic chytil. Pokud se použije it821x.ko, tak to podle mého funguje i bez cmdline argumentů. Tušímže jsem Vortex zkoušel tak od 2.6.33 výš - možná už jeho it821x obsahuje nějaké workaroundy pro R1010, takže jsem žádné problémy v oblasti IDE nepocítil. A možná že aktuální R1011 už ani workaroundy nepotřebuje.

Vortex86SX@300 je procesorově dost slabý, takže se na něj nezlobím, že z "moderních" IDE disků nevytáhne až tolik, co dospělé počítače. Vortex86DX@800 má na IDE sekvenční průchodnost v podstatě stejnou, jako velké kompy s intelským čipsetem.

Problémy s UDMA jsem nezaznamenal. Přinejmenším ne u značky ICOP, která prodává "průmyslové provedení" Vortexu. Je fakt, že mi procházejí rukama ATA Flashky a CF karty převážně od firmy InnoDisk (opět věci do průmyslu) a občas Transcend nebo Sandisk - taky se nám v servisu válí nějaké starší kousky od zapomenutých (ne)značek (Jmau, Afaya).

Svého času byl trvalý problém s kompatibilitou CF karet vůči čipsetům Geode. A nebyl to problém s UDMA - prostě ta flashka nereagovala rozumně ani na Inquiry. Nebo ji třeba BIOS našel, ale ona dřív nebo později "na IDE kanále uhnila". Jako kdyby nějaký problém na velice elementární elektrické úrovni - časování na sběrnici nebo tak něco. Přitom tatáž média proti Intelu chodila jako víno. Bylo to v dobách řádově 256MB flashek - a pozoroval jsem to u značky Pretec a pár dalších "rádoby průmyslových nonamů". Jak jinde píšete, užili jsme si legraci, když Pretec pod jediným partnumberem dodával paměti z různých výrobních linek / sérií, s jiným interním target-mode ATA Flash řadičem, dokonce s různou geometrií. Navenek se to projevovalo tak, že některé CF karty proti Geodovi chodily, jiné ani za boha. Zkusil jsem pár těch problémových karet lousknout a uvnitř jsem objevil společného jmenovatele: ATA flash řadiče od firmy SSS (též 3S) - modely 8873 nebo 8883.

Tohle jsem u Vortexu nikdy nepozoroval. Cokoli jsem připojil na jeho IDE, to chodilo.

Pokud se týče DMA, jeden čas nám procházely rukama průmyslové motherboardy (nebyl to ještě Vortex), kde výrobce tvrdošíjně používal onboard CF sloty bez podpory UDMA, přestože čipset (Intel) UDMA dávno uměl a na trhu se začly hromadně objevovat CF karty, které UDMA podporovaly. To byl průser. V Linuxu se to muselo opět řešit kernel cmdline argumentama v bootloaderu (několik variant - viz odkaz výše).

Vybavuju si, že jsem onehdá potkal taky jakéhosi "Vortexího OEM levobočka" - SoC nápadně podobný Vortex86SX, ale na 150 MHz a výrazně slabší než Vortex86SX@300. Nebudu jmenovat. Asi starší generace SoCu od RDC. A tenhle šváb (v konkrétnim počítači) se choval tak, že s UDMA proti CF kartám pod Linuxem fungoval fajnově, ale jenom řádově asi dva dny (náhodná doba) - pak se celý komp *kousnul* (nereagoval ani na magic SysRq). Pokud jsem zakázal UDMA, nebo snad i pokud jsem vyměnil CF za točivý disk v UDMA režimu, tak ten komp jel navždycky bez problému. Čtyři kusy se chovaly do puntíku stejně. Přitom modernější Vortex SX/DX se stejným datem výroby motherboardu ten problém rozhodně nevykazoval.

[frr]

Jo a ta Java to je někde trochu jinde... předpokládám, že bináry plnotučné Javy SE od Sunu (nyní Oracle) jsou zkompilované pro i686, takže na Vortexu asi smůla. OpenJDK jsem nikdy v ruce nedržel.

Obecně mi přijde trochu zvláštní, vzít naprostý kozí dech x86 a ještě mu naložit Javu My jsme tehdy napoprvé od toho chtěli základní běh a laditelnost Cčkových programů, bez potřeby složitého portování(na ARM)/cross-kompilace/cross-ladění, plus podporou WiFi v MiniPCI slotu (nové jádro bylo hlavně kvůli tomu).

Taky už jsem zkoušel provozovat na Vortexu nějaký softwarek v Perlu, nepříliš složitý - a jenom start Perlu 5 na Vortexu z CF karty je docela tragédie. Trvalo mi asi 20 vteřin, než se program rozběhl (= load z disku + překlad zdrojáku do interního syntaktického stromu). Možná to souvisí spíš s IOPS té CF karty, než s výkonem procesoru při kompilaci zdrojáku. On ten softwarek používal docela velké knihovny jako Expect, Switch a POSIX(termios) - spoustu malých souborků v /usr/lib/perl5/*

Pokud se týče práce v kernelu, považuju se taky za učedníka/začátečníka - a přesně proto se ARMu vyhýbám obloukem. Už jsem potkal pár lidí, kteří se o Linux na ARMu pokusili, byli o ligu výš než já, a většinou dost naříkali.

[Spike]

Ta služba (přehazování průmyslového protokolu na nějaký ASCII protokol + webové rozhraní k tomu) jsou docela jednoduché a (nějaké "starší" ještě suní) 1.6 JRE na tom SX běží - novější Oracle JRE už ale myslím ne. Volných systémových prostředků je vcelku dost a že to celé nabootuje a naběhne do použitelného stavu za minutu nás nějak zvlášť netrápí. Pak už to z karty nic moc nečte.

Já dostal právě za úkol rozběhat to na tom laciném krámu RB262 + nějakých pokud možno co nejlacinějších CF kartách, tak možná proto jsem se s tím taky tak trápil. :)

Ale díky za rady, asi se na to brzy budu muset zase podívat.

[Spike]

Jinak kernel jsem si kvůli té emulaci matematického koprocesoru překompilovával z distribučních zdrojáků, to jo. No nakonec jsem zůstal právě u toho čínského opatchovaného 2.6.18.

[pc2005]

Nepřemýšleli jste nad přechodem na ARM?

[Spike]

Tehdy ani moc ne, nechtěli jsme se pouštět zrovna do embedded vývoje.

Potíž taky je, že kolega tu věc, co na tom pouštíme, napsal v Javě. Ne že by nebylo JRE pro ARM, ale přijde mi to takové divočejší.

Ten Vortex měla být cesta nejmenšího odporu (dobrá dostupnost "v krámu za rohem", "známá" platforma).

Možná teď s RPi nad tím trochu pouvažujeme.

[JS]

Taky mi prijde, ze pokud uz nekdo nakoduje cely virtualni rezim u 386, tak uz tam tech par instrukci, co ma navic 486, muze snadno dodelat...

Mimochodem, 486 se vyrabely v SMP konfiguraci, ze je ta cmpxchg() tak dulezita?

[pc2005]

Taky mi prijde, ze pokud uz nekdo nakoduje cely virtualni rezim u 386, tak uz tam tech par instrukci, co ma navic 486, muze snadno dodelat...

Pokud by podpora 486 zůstala, tak by se mě to asi nedotklo. Ale bál bych se, že by po krátkém čase chtěli zaříznout třeba i 486 a toby už byl problém.

Mimochodem, 486 se vyrabely v SMP konfiguraci, ze je ta cmpxchg() tak dulezita?

Jj přesně tohle mě napadlo taky . Samotná 486 to nepodporuje, myslím, že by byl nutnej hodně speciální čipset. Jediný o čem vím je NCR Voyager, kde je prý stále podpora v kernelu pro cca 3 lidi na světě . Doufám, že jim to podporu neukončí, pokud by se v kernelu dohodli na odstranění podpory.

Jinak je otázka do jaké míry se cmpxchg používá i pro atomické operace na jednom CPU, třeba chtějí v linuxu všude použít cmpxchg. Jako cmpxchg se totiž přímo jmenujou linuxové lowlevel funkce pro atomickou operaci na sběrnici třeba i u MIPSu .

Atomicita operace na sběrnici je u x86 dost jednoduchá, pokud se použije prefix LOCK (i386 má prý u XCHG LOCK implicitní), tak má sběrnici jen jeden procesor a to na celou dobu CISC operace (načtení a uložení).

[Ales Hakl]

Ono tady nejde o to, ze 486 SMP nepodporuje, ale ze od i686 vyse je Intelem doporucovany konkretni zpusob jak SMP delat, ktery vicemene nevyzaduje zadny moc specialni hardware na desce. 386 a nize je dostatecne jednoduchy procesor na to, aby mu bylo uplne fuk, jestli je pouzity v nejake SMP konfiguraci (nema zadny zajimavy interni stav, zejmena L1/L2 cache, ktery by vadil v tom postavit kolem toho SMP system vylozene tupe), kdezto 486 na urovni sbernici jakousi podporu pro SMP ma, ale takovou, ze poskytuje chipsetu rozhrani jak SMP system drzet s velkou snahou pohromade, ne i686-style propojim draty paralelne, sem dam odpor proti plusu a sem kousek diskretni logiky.

[pc2005]

Jj. Ono v době 486 se tomu ani nedalo pořádně říkat SMP, ale víc procesorů na sběrnici šlo už na 8086 a nedivil bych se kdyby i na 8080 . Jinak u 486 je L2 cache mimo procesor, takže tam snad není problém (nebo jí CPU před pasivní čipset ovládá? :-O).

[Ales Hakl]

486 ma navic oproti 386 na chipu 8-16KB L1 cache se kterou je potreba pocitat. Na to ma 486 FSB dva draty AHOLD a #EADS. Princip je, ze pri AHOLD = 1 procesor uvolni adresovou sbernici a chipset tam muze vystavit adresu, jakmile to udela, tak stahne #EADS, cimz procesor zahodi z L1 cache pripadny radek, do ktereho ta adresa spada.

[Miloslav Ponkrác]

„Taky mi prijde, ze pokud uz nekdo nakoduje cely virtualni rezim u 386, tak uz tam tech par instrukci, co ma navic 486, muze snadno dodelat...“

Kódit atomické instrukce je práce pro vrahy.

Ona to není sranda.

Ve skutečnosti 386 nemá žádnou komplexní atomickou instrukci. Zatímco 486 jich má několik – XADD a CMPXCHG.

Přičemž jejich činnost není úplně jednoduchá.

Doporučuji jako cvičení napsat si v C dva programy – jeden, který sčítá 100 bajtové číslo bez synchronizace. A druhý, který zaručuje synchronizaci při tom, když sto threadů se pokouší o sčítání na stejném místě paměti. A sychronizace musí minimálně blokovat a nesmí používat synchronizační primitiva daná operačním systémem (ty totiž procesor nemá k dispozici). Pochopíte velmi snadno mylnost tvrzení „může snadno dodělat“.

---

„Mimochodem, 486 se vyrabely v SMP konfiguraci, ze je ta cmpxchg() tak dulezita?“

Milý JS, atomické instrukce jako je xmpxchg zaručují ATOMIČNOST. Tedy pokud nějaké hw zařízení nebo přerušení nebo cokoli jiného zapíše asynchronně do paměti (třeba pomocí DMA nebo pomocí vámi sestrojeného zařízení po sběrnici) nebo převezme násilím řízení – vždy je zarušena atomičnost celé instrukce xchg nebo – to nejčastěji – dojde k přepnutí procesu v rámci multitaskingu.

Jinak řečeno se nikdy nestane, že by instrukce cmpxchg porovnal akumulátor s operandem instrukce xchg, pak přepnul operační systém proces, který změní hodnotu cílového operandu, pak operační systém přepne proces zpět a zbytek instrukce by konal chybně.

Atomické operace jsou užitečné nejenom pro SMP.

Miloslav Ponkrác

[Ales Hakl]

Implementace atomickych instrukci na i386 a i486 spociva v tom, ze procesor po dobu vykonavani instrukce stahne na FSB drat #LOCK do nuly, atomicnost jako takova je problem chipsetu (coz se trivialne overi napriklad tim, ze si clovek veme manual k i80386 kde je prefix LOCK presne takle definovan, o atomicnosti se tam rika jenom to, ze to je motivace tohohle mechanizmu a problem chipsetu s takovou poznamkou, ze se nepredpoklada, ze to bude atomicke vuci jinym akterum na sbernici nez jinym CPU, takze DMA ci memory-mapped periferie se toho fakticky netykaji). i686 a vyse to implementuje kdovijak (pravdepodobne tak, ze si LOCK interne prelozi na moralni ekvivalent LL/SC znameho z ne-x86 CPU), ale to neni pro tuhle diskuzi relevantni.

Implementacne to skutecne jednoduche je (v te i386/i486 variante), jedine o co jde je po dobu vykonavani nasledujici instrukce ten drat podrzet dole. Jinak na x86 (a vicemene vsech normalnich CPU) jsou vsechny instrukce atomicke vuci interruptum, jestli se ma vyvolat HW preruseni se kontroluje na rozhrani mezi dvemi instrukcemi (ono to vlastne ani jinak nejde, jak by jako procesor reprezentoval na zasobniku, ze byl prerusen v pulce vykonavani instrukce?), prefix REP z tohohle pohledu neni jedna instrukce, ale cyklus o delce jedne instrukce. Ze na to aby OS preemptoval proces musi prijit (pokud tomu chceme rikat preempce, tak HW) preruseni je doufam naprosto zrejme.

[Aleš Kapica]

I když by se to mohlo zdát OT, rád bych upozornil ty co používají OCFS2, že aktuální stable verze v řadě 3.5.x obsahují drobnou chybu, která způsobuje to, že modul zhavaruje. Jde o chybu ve funkci ocfs2_fast_symlink_readpage. Patch, který to opravuje, je již k dispozici, pouze není zařazen do stable větve.

[Petr Tomášek]

Nebylo by přiléhavější napsat „přibližné“, než „nepřesné“?