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í
×
včera 03:00 | Nová verze

Byla vydána nová major verze 3.0.0-1 linuxového prostředí pro operační systémy Windows Cygwin (Wikipedie). Přehled novinek v oficiálním oznámení.

Ladislav Hagara | Komentářů: 6
včera 02:00 | Nová verze

Byl vydán Debian 9.8, tj. osmá opravná verze Debianu 9 s kódovým názvem Stretch. Řešeny jsou především bezpečnostní problémy, ale také několik vážných chyb. Předchozí instalační média Debianu 9 Stretch lze samozřejmě nadále k instalaci používat. Po instalaci stačí systém aktualizovat.

Ladislav Hagara | Komentářů: 0
15.2. 12:33 | Pozvánky

Příští týden bude na MFF UK zahájena série přednášek o architektuře a implementaci operačních systémů. Mezi přednášejícími budou odborníci z firem Kernkonzept, Oracle, Red Hat, SUSE či SYSGO. Pokud si chcete rozšířit obzory (virtualizace, ptrace, ZFS, kdump, ...), vyberte si z harmonogramu téma, které vás zajímá a přijďte. Přednášky se konají každý čtvrtek od 15:40 v učebně S4 na Malostranském náměstí 25 v Praze. Přednášky jsou přístupné veřejnosti (registrace není nutná), studenti UK a ČVUT si je mohou zapsat jako standardní předmět.

Vojtěch Horký | Komentářů: 8
15.2. 05:00 | Nová verze

Bylo vydáno Ubuntu 18.04.2 LTS, tj. druhé opravné vydání Ubuntu 18.04 LTS s kódovým názvem Bionic Beaver. Přehled novinek v poznámkách k vydání a v přehledu změn.

Ladislav Hagara | Komentářů: 0
15.2. 03:00 | Zajímavý software

Git History umí u souborů v git repozitářích zajímavým způsobem zobrazit jejich historii a následně jednotlivé změny, viz animovaný gif. Použít jej lze lokálně nebo aktuálně na soubory umístěné na GitHubu. Máte-li ve webovém prohlížeči zobrazen soubor umístěný na GitHubu, nahraďte v URL doménu github.com doménou github.githistory.xyz a nové URL odešlete. Využít lze také rozšíření Chrome i Firefoxu. V plánu je vedle GitHubu také podpora GitLabu a Bitbucketu.

Ladislav Hagara | Komentářů: 3
15.2. 01:00 | Nová verze

Byla vydána verze 1.0 webové a na frameworku Electron postavené desktopové verze svobodného decentralizovaného skupinového komunikátoru Riot (Wikipedie) využívajícího protokolu Matrix (Wikipedie). Přehled novinek i s náhledy v příspěvku na blogu. Zdrojové kódy jsou k dispozici na GitHubu.

Ladislav Hagara | Komentářů: 4
14.2. 14:22 | Nová verze

Společnost Collabora oznámila vydání verze 4.0 online kancelářského balíku Collabora Online a také Collabora Online Development Edition (CODE) pro domácí uživatele. Kancelářský balík vychází z LibreOffice Online (cgit).

Ladislav Hagara | Komentářů: 0
14.2. 12:11 | Nová verze

Byla vydána verze 241 správce systému a služeb systemd (GitHub, NEWS). Řešeny jsou také bezpečnostní chyby.

Ladislav Hagara | Komentářů: 0
14.2. 11:44 | IT novinky

Evropský parlament, Komise a Rada (trialog) se dohodli na návrhu reformy autorského práva včetně kontroverzních článků 11 a 13. Více v příspěvku na blogu europoslankyně Julie Redy.

Ladislav Hagara | Komentářů: 11
14.2. 07:00 | Komunita

Čtenářům a čtenářkám AbcLinuxu vše nejlepší k Valentýnu aneb Dni lásky ke svobodnému softwaru (FSF, I love Free Software Day, #ilovefs).

Ladislav Hagara | Komentářů: 4
Máte v desktopovém prostředí zapnutou zvukovou znělku po přihlášení se do systému?
 (8%)
 (1%)
 (90%)
 (2%)
Celkem 333 hlasů
 Komentářů: 11, poslední 14.2. 07:59
Rozcestník

Jaderné noviny – 12. 7. 2018: Řízení latence blokového I/O

22. 7. 2018 | David Kolibáč | Jaderné noviny | 3385×

Stav vydání jádra. Řízení latence blokového I/O.

Stav vydání jádra

Kernel release status. Jonathan Corbet. 11. července 2018

Současné vývojové jádro je 4.18-rc4, vydané 8. července. Zdá se, že Linus je zatím spokojený: „Vypadá to tady celkem normálně a co do velikosti to taky vypadá dobře, takže je to další z těch týdnů ‚solidní pokrok směrem k vydání‘. Nudný je dobrý.“

Stabilní aktualizace: 4.17.5 a 4.14.54 byly vydány 8. července a poté 11. července následovaly aktualizace 4.17.6, 4.14.55, 4.9.112, 4.4.140 a 3.18.115.

Řízení latence blokového I/O

The block I/O latency controller. Jonathan Corbet. 5. července 2018

Velká datacentra běžně používají řídící skupiny, aby vyvážila využití dostupný prostředků mezi uživateli. Při určitých typech zátěže šířka pásma blokového I/O může být jedním z nejdůležitějších prostředků, ale řízení I/O v jádře nemusí jako řešení zcela postačovat. Chystané řízení latence blokového I/O by zbývající mezeru mohlo v blízké budoucnosti zaplnit, aspoň pro některé skupiny uživatelů.

Moderní bloková zařízení jsou rychlá, zvlášť v případě nasazení SSD. Ale některé druhy zátěže mohou generovat požadavky na blokové I/O ještě rychleji. Když zařízení nestíhá, fronta (fronty) požadavků se prodlouží, jakožto i čas nutný k vyhovění požadavku. Samotné zpomalení není skoro nikdy vítáno, ale odpovídající nárůst latence je zvláště nepříjemný, je-li druh zatížení citlivý právě na latenci.

Jádro sice dnes řízením blokového I/O disponuje, leč s výhradami. Reguluje se využitá šířka pásma, nikoliv přímo latence, což se hodí, když uživatelé platí za větší maximální šířku pásma, ale když při zátěži záleží hlavně na latenci, už to tak užitečné není. Když některé skupiny svou alokovanou šířku pásma nevyužívají, blokové I/O zařízení se může zastavit, přestože jiné skupiny narazily na své limity a přebývají jim požadavky na I/O. Dále řízení blokového I/O silně závisí na plánovači I/O CFQ a bez něj ztrácí na funkčnosti. Vůbec nefunguje s vícefrontovými blokových zařízeními, tedy těmi, která se v případech, kdy je potřeba řízení I/O, používají nejspíš.

Řízení latence blokového I/O, napsané Josefem Bacikem, tyto problémy řeší tím, že (místo šířky pásma) reguluje latenci, a to na poměrně nízké úrovni blokové vrstvy. Když je povolené, v každém adresáři řídící skupiny se nachází soubor io.latency, který slouží k nastavení parametrů příslušné skupiny. Řádky v tomto souboru odpovídají vzoru:

major:minor target=target-time

Z toho major a minor určují konkrétní blokové zařízení, o které jde, a target-time je maximální latence (v milisekundách), která se u této skupiny může objevit.

Příslušný kód sleduje skutečnou latenci v poměrně malém okně (100 ms), jak ji vidí jednotlivé skupiny. Pokud latence některé skupiny překročí svůj limit, ostatní skupiny na stejné úrovni, které mají limit vyšší, budou omezeny tak, aby se uvolnila část pásma. Tzn. skupina s nejpřísnějším limitem latence má nejvyšší prioritu v přístupu k zařízení. Když se všechny skupiny vejdou do svých limitů, nic se neomezuje, a tak by žádná část šířky pásma neměla přijít vniveč, je-li pro ni využití.

Omezování blokového I/O od pohledu vypadá jako přímočará záležitost: když je potřeba zpomalit proces, prostě se na zařízení neodešle tolik jeho požadavků. Blokové I/O je ale poněkud zvláštní v tom, že se hodně vyvolává mimo kontext procesu, který je za něj nakonec zodpovědný. Příkladem budiž I/O metadat souborového systému, které generuje souborový systém, kdykoliv se mu to hodí. Zpomalení těchto I/O operací by mohlo zmást souborový systém v rozhodování o řazení a vyvolat problémy se zamykáním – přitom zodpovědný proces by vůbec zpomalen nebyl. Další příklad představuje I/O vyvolané swappováním. To vzniká, když jádro potřebuje zabrat paměť procesu, což ale nemusí být za běhu právě toho procesu, který je swappován. Zpomalením I/O swapu se zpomalí uvolňování paměti, aby mohla být použita jinak, – to není zrovna dobrý nápad, když systému paměť schází.

Jaderní vývojáři odpovědní za přidání takového chování by se v dohledné době měli začít poohlížet po pracovních nabídkách v oblasti služeb rychlého občerstvení. Řízení latence nic takového nedělá. Odeslání I/O skutečně zpomalí v případech, kdy jde o I/O generované přímo procesem běžícím v řídící skupině, která má být omezena. Takže například proces, který v krátkých dávkách čte ze souboru, může po aplikaci omezení postřehnout, že začátek čtení trvá déle.

V případě nepřímo generovaného blokového I/O je ovšem potřeba přístup jiný. Tehdy řídící kód zaznamená potřebné zpoždění přímo v kontrolní skupině. Kdykoliv v procesu, který běží v této kontrolní skupině, dojde k návratu ze systémového volání – za těchto okolností víme, že nedrží žádné zámky – tento proces bude uspán na dobu, která vyváží část zpoždění. V závažných případech spánek může trvat až 250 ms. Když hustota provozu I/O poklesne a omezení již není potřeba, zbývající zpoždění se zapomenou.

Bacik v patchi přidávajícím řízení upozornil, že použití řízení vede v souhrnu k mírnému navýšení počtu požadavků za sekundu (request per second, RPS) a výraznému omezení jejich výkyvů v čase. Další zajímavý výsledek je, že řízení může pomoci s ochranou systému před procesy, které se vymkly kontrole:

Další test, který provádíme, je pomalá alokace paměti v nechráněné skupině. Dříve nás to dotlačilo ke swappování a systém nakonec umřel a už se ho nepodařilo obnovit. S těmito patchi vidíme drobné poklesy RPS (obvykle 10–15 %), až je to, co spotřebovává paměť, řádně zabito a v řádu sekund dojde k návratu do normálu.

Zdá se, že omezování zpomaluje alokující proces natolik, že umožní OOM zabijáku (resp. obdobnému internímu nástroji Facebooku) udělat svou práci dřív, než systému dojde paměť.

Skupina patchů prošla do doby psaní tohoto článku šesti revizemi, během nichž došlo k významným změnám v implementaci. Práce se ovšem blíží ke konci. Dočkala se štítku Quacked-at-by od Andrewa Mortona a správce blokové vrstvy Jens Axboe naznačil, že míří do vývojového cyklu 4.19. Takže latence dodání řízení latence blokového I/O aktuálně vypadá na tři nebo čtyři měsíce.

       

Hodnocení: 100 %

        špatnédobré        

Nástroje: Tisk bez diskuse

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

Komentáře

Vložit další komentář

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