Jaderné noviny – 24. 5. 2012: Čtyři bajty, na kterých sejde (diskuse)

[pc2005]

podpora pro asymetrický multiprocessing

Můžeš poslat link? Asi jsem slepý, ale v těch odkazech v textu okolo jsem žádnou zmínku nenašel .

[kralyk z abclinuxu]

Asi je to jen spekulace, ale x32 ABI by možná mohlo přinést zrychlení wine záležitostí (čti: her) na x86-64, ne?

[chrono]

Predpokladám, že všetky dôležité časti sú optimalizované a využívajú MMX/SSE, takže pár registrov navyše príliš nepomôže. Navyše "bežná" 32 bitová aplikácia asi nebude fungovať na x32 ABI priamo.

[lyon]

A program compiled to this ABI will run in native 64-bit mode, but with 32-bit pointers and data values. The full register set will be available, as will other advantages of the 64-bit architecture like the faster SYSCALL64 instruction.

Coz podle meho soudu znamena, ze pripadne zrychleni by se tykalo jen wineserveru, ale aplikace jako takova by stejne musela bezet v nativnim 32-bit rezimu. Nejsem si uplne jist, jakym zpusobem by to melo nahradit 32-bit rezim kompatibility (viz odkazovany clanek), kdyz stare 32b binarky s tim stejne fungovat nebudou a nove neni duvod nekompilovat do 64b.

[Luboš Doležel (Doli)]

Cílem je právě nahradit 64bitový režim.

Win32 binárka bude samozřejmě pořád stejná, ale všechen kód Wine by IMO mohl být x32. A to je docela dost.

[lertimir]

Jak jsem už psal před časem v dotazech. Spuštění dvou proudů kopírovaní do pomalejší USB flashky mi v podstatě zastavilo celé KDE asi na 20 minut, než se vše nakopírovalo. Jak jsem pochopil pak z diskuse, problém je v plánovači. Pracuje se na něčem v plánovači, co by bylo schopno udržet prostředí pro uživatele se slušnou reakční dobou i když některé části budou čekat?

[pc2005]

Hmm trochu mě to zní jako problém pro ionice ne?

[Dr. Eddy]

Jaky mas distro?

V Archu s timhle neni problem. Jadro je plne preemptivni, to v Ubuntu myslim nebyvalo. Ale muzes zkusit Brain-fuck scheduler. Ten ale neni v mainline, jen jako patch, jestli se nepletu.

[lertimir]

Distro mám openSUSE, ale podle reakcí jiných na můj dotaz to na distru nezáleží a má to i Arch. A jasně mohu to nějak oflikovat třeba "Brain-fuck" shedulerem, také si mohu dát pozor a s flashkou pracovat tak, že dva proudy tam nedám, ale na druhou strany mě to připadá, že je to systémový problém, a v nějakém delším běhu by se na něm mělo pracovat.

[Michal Kubeček]

Nepomohl ani poslední update jádra (3.1.10-0.9)? Tam by měl být tento problém opraven. Při intenzivnějším zápisu na pomalá zařízení se mi sice nějaké ty záseky pořád objevují, ale ne delší než asi sekundu.

[lertimir]

Nevím. Mám plně aktualizované distro, ale v poslední době jsem takový zápis nezkoušel. Přece jen čas mi byl dražší. Zkusím jak budu mít čas a poreferuji. A i ten případ o kterém jsem referoval byla v podstatě moje chyba ve stylu práce. Standardně jakékoliv větší kopie dělám v krusaderu pomocí jeho funkce "Fronta", pak je zápis dost sekvenční. V tom případě jsem kopíroval dva sety fotek každý tak 3GB a 500 souborů a první jsem poslal do fronty a u druhého jsem se ukliknul a poslal ho přímo kopírovat. Tím vznikly dva paralelní proudy. Celkem si dokážu představit, jak v situaci, kdy tam jely oba proudy současně, se do flasky posílají sektory z každého setu na střídačku a flash se může zbláznit, jak pro každý sektor načte celý erase blok, přepíše jeden sektor a blok zase zapisuje. A je mi jasné, že tímhle jsem snížil rychlost zápisu více než 10 krát (faktická rychlost byly asi 2MB/s). Nicméně v žádném případě, když jeden či několik procesů čeká na HW by to nemělo skoro nijak zasáhnout procesy, které s tím HW nemají, co dělat.

[Kaacz]

oSuse ma z ofiko repos jadro jen 3.1.10. Mám pocit, že vylepšení plánovače pro desktop aby USB IO neblokovalo interaktivni praci prislo ve verzi jadra 3.2. Našel jsem na OBS neofiko repos s jadrem 3.3, ale s tím mi zase nejede Virtualbox ..

[Michal Kubeček]

O dva příspěvky výše píšu, že poslední update na 3.1.10-1.9 ten hlavní problém s THP řeší, je tam i odkaz na bugzillu.

[Kaacz]

No ja si nebyl jisty, jestli "tento problem" (link) je ten problem o kterem je rec. Oficialne to bylo ve vanila 3.2, toz osuse zrejme udelalo backport do 3.1. V tom pripade to asi nefunguje. USB rezie mi tuhne desktop stejne (mozna vice) nez drive.

[Kaacz]

Mno. na druhou stranu .. tento repo-release kernelu 3.1 sice oficialne fixuje odkazovany !! NOVELL !! bug .. jak z toho zjistim, jestli sami neco podrbali nebo jestli backportovali tu upravu z kernelu 3.2 ? Nikdy jsem se v techto vecech nehrabal.

[Kaacz]

Odkazovane CVE nevedly na ten vanila fix. Ale po procteni toho vlakna buzilly to vypada, ze to byla aplikace :toho: patche z 3.2. Mno, tak tam asi jeste zbyva doladit nejakou drobnost. :)

[Kaacz]

Navic nikdy nedelam 2 operace nad jednim usb zarizenim. Ale bezne prehazuju data s tremi USB massstorage najednou. Jako treba kopirovat jeden USB disk na druhy USB disk .. mnamka. :( Ne ze by to vytuhlo tak dlouho. Ale uzasne prace s tim desktopem taky neni.