abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
dnes 00:11 | Zajímavý článek

Daniel Vetter se v příspěvku Upstream Graphics: Too Little, Too Late (Grafika v upstreamu: příliš málo, příliš pozdě) na svém blogu věnuje podpoře a problémům grafiky v upstream Linuxu. Jedná se o souhrn jeho stejnojmenné přednášky na Linux Plumbers Conference (videozáznam, pdf).

Ladislav Hagara | Komentářů: 0
včera 23:33 | Komunita

Na YouTube lze zhlédnout čtrnáctiminutový dokument televize CNBC s názvem The Rise Of Open-Source Software (Vzestup open source softwaru).

Ladislav Hagara | Komentářů: 0
včera 22:22 | Nová verze

Po roce od vydání verze 6.0 byla vydána nová major verze 6.1 multiplatformního virtualizačního nástroje Oracle VM VirtualBox. Přehled novinek v Changelogu. Nově lze například importovat virtuální počítač z infrastruktury Oracle Cloud.

Ladislav Hagara | Komentářů: 0
včera 20:11 | IT novinky

GOG nabízí klasickou cRPG Wasteland 2 do pátku 13. prosince 2019 zdarma. Hra je k dispozici pro Linux (oficiálně Ubuntu LTS) a bez DRM. Stojí za ní inXile Entertainment, navazující na Interplay, od nějž pochází původní Wasteland (1988) či Fallout.

Fluttershy, yay! | Komentářů: 0
včera 17:11 | Komunita

osxfuse, implementace FUSE (Filesystem in Userspace) na macOS, již není open source. Autor se prostě rozhodl zdrojové kódy pod licencí BSD dál nešířit. Diskuse na Hacker News.

Ladislav Hagara | Komentářů: 13
včera 10:44 | Zajímavý projekt

Na Humble Bundle běží akce Humble Paradox Management Bundle. Počítačové hry v balíčcích za 1 dolar, 7,91 dolaru a 18 dolarů běží také na Linuxu. Jedná se o série Prison Architect, Cities in Motion, Cities: Skylines a Surviving Mars.

Ladislav Hagara | Komentářů: 0
10.12. 22:55 | Bezpečnostní upozornění

Byl vydán Git ve verzích 2.24.1, 2.23.1, 2.22.2, 2.21.1, 2.20.2, 2.19.3, 2.18.2, 2.17.3, 2.16.6, 2.15.4 a 2.14.6. Opraveno je 9 bezpečnostních chyb: CVE-2019-1348, CVE-2019-1349, CVE-2019-1350, CVE-2019-1351, CVE-2019-1352, CVE-2019-1353, CVE-2019-1354, CVE-2019-1387 a CVE-2019-19604, viz například Ubuntu USN-4220-1.

Ladislav Hagara | Komentářů: 0
10.12. 22:33 | Nová verze

Google Chrome 79 byl prohlášen za stabilní (YouTube). Nejnovější stabilní verze 79.0.3945.79 tohoto webového prohlížeče přináší řadu oprav a vylepšení. Vylepšeny byly také nástroje pro vývojáře. Opraveno bylo 51 bezpečnostních chyb. Za nalezení nejvážnější z nich bylo vyplaceno 20 tisíc dolarů.

Ladislav Hagara | Komentářů: 0
10.12. 22:11 | Nová verze

V září Microsoft potvrdil, že portuje klienta Microsoft Teams na Linux. Dnes byla vydána první veřejná verze k testování. Ke stažení jsou balíčky .deb a .rpm. Microsoft Teams je firemní platforma, která umožňuje textovou komunikaci, video hovory, datové úložiště pro ukládání souborů (na těchto souborech lze také spolupracovat) a integraci dalších aplikací do tohoto prostředí. Služba je integrována v předplatném Office 365.

Ladislav Hagara | Komentářů: 9
10.12. 15:22 | IT novinky

Společnost PFU (divize Fujitsu) představila (prezentace v japonštině) novou generaci Happy Hacking Keyboard, řady klávesnic původně navržené Eiiči Wadou pro unixové systémy začátkem 90. let – bez nutnosti přidání dalších fyzických kláves. Nové modely (Hybrid, Hybrid Type-S a Classic) navazují na řadu Pro 2, stále je tedy vyrábí Topre a používají příslušné kapacitní spínače, všechny se ale nově připojují přes USB-C a „Hybrid“ navíc podporuje i Bluetooth.

Fluttershy, yay! | Komentářů: 45
Jaké hodinky nosíte (nejčastěji)?
 (23%)
 (5%)
 (17%)
 (54%)
Celkem 563 hlasů
 Komentářů: 135, poslední 6.12. 20:54
Rozcestník

www.AutoDoc.Cz

Dotaz: Dynamická změna vlivu dlouhotrvající MT-zátěže na hostitelský systém

13.3. 16:17 PetebLazar
Dynamická změna vlivu dlouhotrvající MT-zátěže na hostitelský systém
Přečteno: 993×
Virtualizace KVM/QEMU nám umožňuje jeden zajímavý trik. Rozběhnout VM s určitým počtem virtuálních cpu(core) a jejich obluhu pomocí například nástroje qemu-affinity svěřit stanovené podmnožině fyzických cpu(core). Umožňuje to například rozběhnout komlexni MT-úlohu v čase T nad všemi VM dostupnými N-virtuálními jádry(ve skutečnosti obsluhovanou např. pouze N/2 fyzických jader). Pokud sit́uace dovolí, je možné změnou affinity tentokrát již k N-fyzickým jádrům poskytnout stále běžící úloze v čase T+X více výkonu.

Umožňuje něco takového přímo prostředí Linuxu, tj. přesvědčit proces v době vzniku o dostupnosti N-jader a zajistit obsluhu její subprocesů/threadů pouze zvoleným počtem (konkrétních) jader?

Cílem je u dlohotrvající MT-zátěže umožnit měnit dynamicky míru zátěže hostitelského systému. Příklad: rendering výstupu NLE.

Řešení dotazu:


Odpovědi

13.3. 16:30 alkoholik | skóre: 38 | blog: Alkoholik
Rozbalit Rozbalit vše Re: Dynamická změna vlivu dlouhotrvající MT-zátěže na hostitelský systém
Jo, to se da udelat celkem jednoduse pres cgroups.
13.3. 20:06 PetebLazar
Rozbalit Rozbalit vše Re: Dynamická změna vlivu dlouhotrvající MT-zátěže na hostitelský systém
Zatím v cgroups nějak nenalézám schopnost přesvědčit task, že je dostupno pouze N-jader a on tomu přizpůsobil v době zahájení míru své multithreadovosti.
13.3. 23:02 alkoholik | skóre: 38 | blog: Alkoholik
Rozbalit Rozbalit vše Re: Dynamická změna vlivu dlouhotrvající MT-zátěže na hostitelský systém
Jo takhle to myslis. To asi budes muset delat hotplug CPU ve virtualu.
13.3. 23:38 PetebLazar
Rozbalit Rozbalit vše Re: Dynamická změna vlivu dlouhotrvající MT-zátěže na hostitelský systém
To by asi nepomohlo, algoritmus úlohy by musel průběžně ověřovat počet dostupných cpu(core) a měnit dynamicky šíři své MT dle toho. Mám obavu, že takto se asi málokterý (NLE) program chová. Skze VM to není problém vyřešit, VM spustí se s určitým (limitním) počtem virtuálních jader a jejich obsluha se svěří omezenému(případně rozšířenému) počtu fyzických jader dle požadavků na výkon.

I toto řešení je přijatelné, do VM bych asi nasadil edici CentOS7.3 od BMD, který má podle všeho slušnou podporu Davinci Resolve (aspoň funguje mi v něm GPU decoding Blackmagic-RAW, k čemuž jsem zatím Xubuntu 18.04 nepřesvědčil). Pouze musím vyřešit překlopení nainstalovaného VM CentOS7.3 z Legacy na UEFI, kvůli OVMF GPU-passthrough.

Možná by stačilo nějakým způsobem přesvědčit program při spouštění, že systém disponuje pouze N-jádry (plus parking na stanovená jádra). Otázkou je, jak si to program zjišťuje.
13.3. 20:36 rastos | skóre: 61 | blog: rastos
Rozbalit Rozbalit vše Re: Dynamická změna vlivu dlouhotrvající MT-zátěže na hostitelský systém
13.3. 21:49 PetebLazar
Rozbalit Rozbalit vše Re: Dynamická změna vlivu dlouhotrvající MT-zátěže na hostitelský systém
Taskset nastaví affinitu jader k procesu, ale neovlivní kolika dostupných jader si je proces vědom. Pokud se tento rozhodne využít všech dostupných jader (fyzických/logických) nic mu v tom asi bránit nebude. Samozřejmě i to by nejspíš fungovalo, ale obsluhovat více vláken jedním jádrem by zvyšovalo podíl režie. Na druhou stranu to poskytovalo asi největší rozsah regulace (až k 1:1).
14.3. 21:31 PetebLazar
Rozbalit Rozbalit vše Re: Dynamická změna vlivu dlouhotrvající MT-zátěže na hostitelský systém
Nevím nakolik je to "košer", ale jednou z možných cest asi může být dočasné vypnutí určeného počtu jader procesoru(ů) před spuštěním omezovaného programu (v prostředí Ubuntu pomocí echo 0 | sudo tee /sys/devices/system/cpu/cpux/online).

Spuštěný program (jeho úloha) se pak musí spokojit maximálně s v dané době dostupnými jádry (jejich počtem) a po rozběhnutí dlouhodobé úlohy pak stačí vypnutá jádra opět zapnout (echo 1 | sudo tee /sys/devices/system/cpu/cpux/online).

Výše zmíněný taskset pak poslouží k nastavení affintity procesu k určeným jádrům (v době "sucha" k menšímu počtu, v době "hojnosti" k většímu). Maximální vytížení by však nemělo přesáhnout úroveň z doby vypnutí jader (samozřejmě v případě úlohy, která si průběžně počet dostupných jader neověřuje).
20.3. 17:36 trekker.dk | skóre: 71
Rozbalit Rozbalit vše Re: Dynamická změna vlivu dlouhotrvající MT-zátěže na hostitelský systém
To by asi šlo, ale pozor, u virtualizovaného hardware na Debianu stable (virtio_scsi, pokud si dobře vzpomínám), tohle vede na pád jádra.
Quando omni flunkus moritati
20.3. 22:36 PetebLazar
Rozbalit Rozbalit vše Re: Dynamická změna vlivu dlouhotrvající MT-zátěže na hostitelský systém
Jde o postip (disablování jader) uvažovaný pro nativní běh aplikací (v rámci HostOS). Nebude to uplaťnováno při využití virtualizace (tam jsou jiné možnosti).
21.3. 12:06 trekker.dk | skóre: 71
Rozbalit Rozbalit vše Re: Dynamická změna vlivu dlouhotrvající MT-zátěže na hostitelský systém
Jasně, šlo mi spíš o to, že podobný problém může mít i ovladač pro jiný hardware
Quando omni flunkus moritati
21.3. 20:42 PetebLazar
Rozbalit Rozbalit vše Re: Dynamická změna vlivu dlouhotrvající MT-zátěže na hostitelský systém
Zatím jsem žádnou nestabilitu nepozoroval, pokud by se tak stalo určitě to zde uvedu. Někde se zmiňuje, že po vypnutí jádra daným postupem je toto stále dostupné pro již existující procesy, ale nedostupné pro nové. CPU0 nejde tímto způsobem (asi logicky) vypnout.

Možná, že nejbezpečnější cestou by byl parametr isolcpus v kernelu (ten by měl vyřadit izolovaná jádra z uvažování kernel-scheduleru), takže by předpokládám funkce ovladačů (až na ty v userspace) neměla být hrátkami s jádry ohrožena. Tedy za předpokladu, že v userspace o vzniklé procesy/thready bude postaráno (schedulingem).

Pozn. Vypadá to, že vypnutí dostatečného počtu jader umožní spuštění starších her (Steam/Proton), které mají s vyšším počtem jader problém.
21.3. 09:09 j
Rozbalit Rozbalit vše Re: Dynamická změna vlivu dlouhotrvající MT-zátěže na hostitelský systém
Rekl bych, ze toto fungovat nebude. Jednoduse proto, ze prakticky kazdy nomalni system si bez problemu poradi s hotplugem CPU a i aktualne bezici ulohy na ne v klidu presune. Tohle se bude chovat nejspis uplne stejne.

Vetsina aplikaci si pak v prubehu behu spousti a ukoncuje hromadu threadu, ktere opet system prubezne distribuuje na dostupny jadra. Co se tyce omezeni mnoztvi vyuzivanych jader, prevazne je to soucasti konfigurace aplikaci.

V tuxovi nativne IMO bude nejlip fungovat zmena priority (niceness), coz sice neomezi vyuzivany jadra, ale velice dobre to uprednostni nebo upozadi vybrany aplikace (priklad - na desktopu bezi kompilace, CPU jede na 100%, ale protoze ma nizkou prioritu, tak nema temer zadny vliv na odezvu systemu, a uzivatel si muze vesele browsat po webu, poustet videa ... protoze to vse ma prioritu vyssi).
21.3. 12:33 PetebLazar
Rozbalit Rozbalit vše Re: Dynamická změna vlivu dlouhotrvající MT-zátěže na hostitelský systém
Pro aplikaci DRS (DaVinci Resolve Studio, o kterou mi jde) to vypadá funkční. Když na CPU se všemi jádry spustím export projektu, zátěž procesem GUI_Thread dosahuje cca 1400%. Když před spuštěním DRS omezím procesor například na 8 jader a v něm spustím export, zátěž GUI_Thread dosahuje 800%. Rozhodující je okamžik spuštění DRS, kdy si asi aplikace zjišťuje počet dostupných jader a tomu přizpůsobuje svou budoucí multi-threadovost. Zátěž zůstane omezená, i když jsou před samotným spuštěním exportu všechna jádra zase aktivní.
24.3. 16:35 OldFrog {Ondra Nemecek} | skóre: 32 | blog: Žabákův notes | Praha
Rozbalit Rozbalit vše Re: Dynamická změna vlivu dlouhotrvající MT-zátěže na hostitelský systém
No ale na toto skutečně stačí pro DRS nastavit vyšší nice. Anebo nastavit nižší počet threadů - divil bych se, pokud by DRS neměl možnost nastavit počet threadů.
-- OldFrog
21.3. 08:57 Peter Golis | skóre: 59 | blog: Bežné záležitosti | Bratislava
Rozbalit Rozbalit vše Re: Dynamická změna vlivu dlouhotrvající MT-zátěže na hostitelský systém
Nebude jednoduchšie použiť CPU Hotplug, a dynamicky adaptovať počet threadov výpočtovej aplikácie clustera aby vyťažili pridelené VCPU (alebo to nechať na optimálne maximálnom počte, ak to zle napísané úlohy nedovolia)?

Hranie sa so zbytkovým výkonom jadier mi nepripadá moc optimálne. Ako hlavolam na dlhé zimné večery to môže byť veľmi dobré, ale dnes je predsa prvý jarný deň.
21.3. 12:39 PetebLazar
Rozbalit Rozbalit vše Re: Dynamická změna vlivu dlouhotrvající MT-zátěže na hostitelský systém
Jde o hledání řešení v rámci nativního běhu aplikace, nevím zda odkazované nepředpokládá využití virtualizace?
21.3. 13:04 Peter Golis | skóre: 59 | blog: Bežné záležitosti | Bratislava
Rozbalit Rozbalit vše Re: Dynamická změna vlivu dlouhotrvající MT-zátěže na hostitelský systém
nevím zda odkazované nepředpokládá využití virtualizace
Prví napísané slová: Virtualizace KVM/QEMU.
21.3. 14:03 PetebLazar
Rozbalit Rozbalit vše Re: Dynamická změna vlivu dlouhotrvající MT-zátěže na hostitelský systém
V úvodním dotazu jsem formuloval otázku na možnost řešení v rámci nativního běhu (řešení skrze virtualizaci jsem uvedl jako příklad cíle).

Proto ta má sondujíci otázka, říkal jsem si jestli nejde o nějaký trik s QEMU o nemž nemám tušení.

Za preferencí nativního běhu mj. stojí snaha zapojit do akcelerace exportu DRS obě přítomné Geforce(OpenCL/CUDA). Při virtualizovaném řešení využiji pouze jednu (druhou bude okupovat HostOS). Sekundárním důvodem je výkon IO, ten může na vstupu překonávat dlouhodobě 500MB/s(ve VM obtížněji dosažitelné).
Řešení 1× (OldFrog {Ondra Nemecek})
21.3. 21:00 lertimir | skóre: 63 | blog: Par_slov
Rozbalit Rozbalit vše Re: Dynamická změna vlivu dlouhotrvající MT-zátěže na hostitelský systém
Nevidím přímo, proč bych potřeboval tak silně omezovat jádra, a nestačilo by snižovat pouze niceness nebo ioniceness. To v mých případech je dostatečné na udržení priority používané aplikace před background výpočtem. Jediný problém je s buffery, jejichž velikost je třeba hlídat, zvláště když jsou velké objemy paměti a mohly by buffery narůst na velké velikosti v poměru k přenosovým rychlostem do diskových zařízení.
23.3. 07:25 PetebLazar
Rozbalit Rozbalit vše Re: Dynamická změna vlivu dlouhotrvající MT-zátěže na hostitelský systém
Šlo mi o minimalizování nutné režie. Pokud by proces použil všechna dostupná jádra (32) pro svůj běh a já je následně affinitou přiřadil na 8-jader (snaha izolovat je na node v NUMA). Poběží 4 thready/jádro, takže výsledná efektivita běhu může být nižší (klesne cache/thread, RAM bandwidth/thread, ...), než dejme tomu při 2 thr/jádro.
23.3. 20:51 GeorgeWH | skóre: 39
Rozbalit Rozbalit vše Re: Dynamická změna vlivu dlouhotrvající MT-zátěže na hostitelský systém
A neslo by to opacnym smerom? Neobmedzovat VM na pocet vCPU (teda dat mu plny/max mozny pocet), ale obmedzovat mu vykon - znizovat/zvysovat frekvenciu/cpu vahu/pool (podla moznosti danej virtualizacie).
23.3. 21:59 PetebLazar
Rozbalit Rozbalit vše Re: Dynamická změna vlivu dlouhotrvající MT-zátěže na hostitelský systém
Připomínám, nejde o VM. Jde o custom omezení nativně běžící aplikace pod Linuxem (konkrétně DaVinci Resolve Studio). Cílem je omezit maximální multi-threadovost aplikace (pro dlouho bežící task .. rendering projektu). Dejme tomu na max. 12-16 jader, přičemž v době potřeby výkonu jinde ji affinitou jejím procesům/threadům poskytnout pouze 6-8 fyzických jáder (zjednodušeně řečeno omezit na cca 50% výkonu). V době volných zdrojů ji affinovat k 12-16 fyzickým jádrům (možnost běžet naplno .. 100% výkonu). Rendering může běžet i několik hodin, podle délky timeline a množství(složitosti) korekcí.
24.3. 15:39 sigma
Rozbalit Rozbalit vše Re: Dynamická změna vlivu dlouhotrvající MT-zátěže na hostitelský systém
Pokud to v aplikaci nejde nastavit (jako že asi ne, jinak by se to tu neřešilo) pak záleží na tom, jakým mechanismem si daná aplikace zjišťuje počet CPU v systému.

Podle toho by šlo použít buď standardní mechanismy používané pro kontejnery (namespaces, cpuset) nebo by bylo možné trik s LD_PRELOAD pro vložení vlastního kódu překrývajícího příslušnou knihovní funkci nebo odchytávajícího příslušný syscall a modifikující odpověď.

Těch mechanismů je vícero:

sysconf(_SC_NPROCESSORS_ONLN)

get_nprocs_conf()

get_nprocs()

čtení /proc/cpuinfo nebo i iterace přes sys/devices/system/cpu, podle kreativity vývojářů
24.3. 15:59 PetebLazar=
Rozbalit Rozbalit vše Re: Dynamická změna vlivu dlouhotrvající MT-zátěže na hostitelský systém
Také mne to zpočátku toto napadlo, do chvíle kdy mi Google vyhodil odkaz "12 způsobů jak zjistit počet jader CPU v Linuxu." ;-)

Zatím je to vyřešeno dočasným "vypnutím" patřičného počtu jader před spuštěním omezované aplikace. Vypadá to, že ta si počet dostupných jader zjišťuje pouze při spuštění a během života s ním počítá. Otázkou je, zda zvolený zůsob (dočasného vypnutí jader) může být důvodem nestability na úrovni OS/APL?
24.3. 20:45 Gregi
Rozbalit Rozbalit vše Re: Dynamická změna vlivu dlouhotrvající MT-zátěže na hostitelský systém
A taky jednoduchy script v crone, co overuje zataz jadier v systeme, alebo procesu, ktory ma vyssiu prioritu pre ktory to robis (all) a na zaklade toho dynamicky pridelovat Davinci procesu max. CPUs technikami co pani uz spomenuli? Samozrejme ak to ta aplikacia nevie za behu overit a pada, potom asi len cez ten sysCall.
24.3. 23:19 PetebLazar
Rozbalit Rozbalit vše Re: Dynamická změna vlivu dlouhotrvající MT-zátěže na hostitelský systém
Taková dynamičnost ani není požadavkem, jde čistě o uživatelské(ruční) přidělování zdrojů. Výše zmíněná technika (uvedení X-jader do offline před spuštení DRS a jejich vrácení do online po jeho startu) se zatím jeví nejjednodušší a funkční, do vzniků problémů vydržím s ní.
26.3. 08:00 cronin | skóre: 49
Rozbalit Rozbalit vše Re: Dynamická změna vlivu dlouhotrvající MT-zátěže na hostitelský systém
Krása akéhokoľvek "ručného" riešenia v unixovom prostredí je, že ide zvyčajne jednoducho automatizovať skriptom.

Ničmenej, je relatívnne bežná prax offloadovať rendering videa na iný, na to určený stroj, tak pri procese vkladania nových zdrojových videí, ako aj pri exporte finálnych výsledkov. Nebola by toto cesta?

26.3. 09:30 PetebLazar
Rozbalit Rozbalit vše Re: Dynamická změna vlivu dlouhotrvající MT-zátěže na hostitelský systém
Zda po editaci bude probíhat i rendering může tušit pouze uživatel, odpovídající skript může příslušné opatření pouze provést, nikoli rozhodnout. Stejně tak míru potřeby dostupných zdrojů pro případnou paralelní činnost.

Offload renderingu určitě ano, druhou licencí DRS dokonce disponuji (byla součástí kamery), je to dlouhodobý cíl (offloadovat na stroj s méně zdroji než poskytuje primární PC by zatím nemělo smysl, kromě paralelní editace/renderingu).Uvidíme jak na tom bude nová generace Ryzenů/Threadripperů/EPYCů. Řešení by muselo být komplexnější nejen kvůli změně storage projektu (postgresql místo FS), ale i s ohledem na potřebu sdílení soubororů projektu (xTB se síťovou průchodností v řádu 1GB/s). Vhodné řešení storage pro tento účel vyplynulo z příspěvků v nedávném vedlejším té́matu.
26.3. 09:37 Peter Golis | skóre: 59 | blog: Bežné záležitosti | Bratislava
Rozbalit Rozbalit vše Re: Dynamická změna vlivu dlouhotrvající MT-zátěže na hostitelský systém
Zda po editaci bude probíhat i rendering může tušit pouze uživatel
A presne kvôli tomuto vznikli kadejaké výpočtové clustre ktoré takéto banality riešia. Človek si zadefinuje úlohu, a tá sa mu distribuuje podľa daných kritérií.

Založit nové vláknoNahoru

Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

ISSN 1214-1267   www.czech-server.cz
© 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.