Jaderné noviny – 27. 7. 2012: Co bude v jádře 3.6 (diskuse)

[100% Lenin]

Первый.

[berger]

Zdravim,

na zaciatok vdaka za dobru pracu pri preklade, ale naslo sa par zabudnutych veci. Pri druhom citate chyba meno autora (-- Mike Galbraith). Dalsia vec, ktoru som si vsimol: Takže jsme přišli s nápadem implementovat většinu funkčnosti CPT v jádře, tedy jako program nezávislý na linuxovém jádře.

V originali je user space. Z mojho pohladu sa asi stala chyba a namiesto mimo jadra, sa objavilo v jadre.

[Luboš Doležel (Doli)]

Díky, opraveno.

[Sten]

Obojetné uspání mi přijde jako úplně úžasná fíčura. I v Redmondu se totiž systém musí probudit, aby se hibernoval, na což ale někdy nemusí mít dost baterie (a někdy ani žádné baterie nemá).

[R]

IBM to malo uz pred 18 rokmi v ThinkPadoch - pod nazvom RediSafe. Myslim, ze teraz to ma MacOS X.

[tom]

Todle umely bezne thinkpady z minuleho tisicileti, bylo to implementovane castecne v biosu. Dalo se to nastavit i tak, ze se system uspany do ram vzbudil, kdyz zjistil, ze mu dojde stava, a pak se uspal na disk.

[Sten]

To, že se systém vzbudí, když mu dochází baterie, dělá už dneska cokoliv s Windows nebo Linuxem, ale osobně mám vyzkoušené, že to není úplně spolehlivé (baterie může dojít během hibernace, když už je stará a má hodně malou kapacitu, a nejde to na desktopu) a navíc, když při uspání zahodím klíč k LUKS, tak to kromě vzbuzení nic neudělá.

[tom]

Po probuzeni to skocilo do firmware notebooku, ktery provedl uspani na disk. Interakce systemu IMO nebyla potreba.

[Sten]

To bych se divil a současné systémy to tak ani nedělají. Kam by se to uspalo, když disk je šifrovaný klíčem, který není k dispozici? A kdo by zrestartoval všechny periferie, které se při uspání do RAM nevypínají/nemažou, ale při hibernaci se vypnou (třeba USB nebo cache procesoru)?

[tom]

Uspavalo se to na partitionu, ktera k tomu byla vyhrazena. Pouzivalo to nejaky vlastni format. Periferie se v dobe pred 12lety mohli chovat jinak, pamatuji si jen, ze to neslo probudit USB klavesnici. Duvodem mohl byt i fakt, ze uspany notebook mohl byt vyndan z doku, v kterem byl i jeden PCI slot.

[tom]

A taky to vydrzelo v RAMce uspane mnohem dele - pamatuji si, ze jsem po posledni cervnove zkousce NTB zavrel a pak ho v zari otevrel a on nabehl z RAMky :)

[Jendа]

když při uspání zahodím klíč k LUKS, tak to kromě vzbuzení nic neudělá

Zahazuješ i klíč k /? Používáš ten Mrkvův patch, nebo jsi to vyřešil nějak jinak?

[Sten]

Mrkvův patch neznám, ale řešil jsem to tak, že screensaver a cryptsetup (včetně knihoven) zkopíruju do tmpfs. Ale kvůli tomu, že se to neumí vzbudit a zahibernovat, to nakonec nepoužívám.

[Honza Jaroš]

Neuměl tohle i swsusp2/TuxOnIce? Mám neodbytný pocit, že jsem kdysi něco takového zkoušel...

[Václav HFechs Švirga]

Co vim, tak umi, asi to je akorat tedka uz v jadre, driv to bylo asi nejak externe.

[Jendа]

Určitě, na Archu kolem 2.6.30 jsem měl s2both. Proto nechápu ty bombastické články.

[Václav HFechs Švirga]

Takova ficura mi neprijde k nicemu, pokud chci uspani do ram, chci to proto, at se to uspi rychle. Treba konec prednasky, chci uspat (i s vizualni kontrolou, ze se skutecne ntb uspal, protoze v Linuxu se to nekdy na necem sekne a pak by byl ntb zaply v brasne), nacpat do brasny a jit pryc. Pri obojetnem uspani ale musim cekat uplne stejne dlouho jako pri uspani na disk, jedina vyhoda je ta, ze se mi to rychleji zapne. Ale to je mi uplne k nicemu, ja to potrebuji rychle schovat .

Naopak ficura typu, ze se ntb uspany do ram pri 1 % baterky sam probudi a zasuspenduje se mi prijde podstatne uzitecnejsi (a musi mit hw podporu), nicmene lepsi je to samozrejme nenechat do takoveho stavu dojit. Pokud mam jen par procent baterky, o suspendu do ram se nepokousim, pokud je baterka aspon na 25 %, tak to vydrzi i den.

[Sten]

S automatickým probuzením je jeden problém: co když se to probudí v tašce, kde to má i během hibernace velkou šanci se přehřát?

Jinak bych to samozřejmě viděl jako další možnost, nikoliv jako náhradu samotného uspání

[Jendа]

Jakou tak může mít tepelnou kapacitu notebook? 1 kJ/K? Tak to se za minutu (tak dlouho může trvat uspání) při příkonu 20 W ohřeje o stupeň.

[Václav HFechs Švirga]

Tak můj "thinkpad" (SL model) byl zaplý v těsném neprodyšném prostoru asi hodinu (právě kvůli nějakému bugu při uspávání, kdy jsem to pak nezkontroloval :/), když jsem ho vytahoval, tak jsem si spálil pracky, protože byl žhavý úplně všude. Byl zaseklý a když jsem ho zrestartoval, jen zapípal že je přehřáty, zapnout šel až po čtvrthodince kdy se už dostatečně ochladil (ale horký byl ještě tak 2 hodiny ). Žádné následky to ale naštěstí nezanechalo.

Nicméně i tak by takové probuzení nemuselo být veselé a to ne kvůli přehřátí, ale možnosti poškození hdd. Ale to už je každého věc, jaké uspání si zvolí dle situace. Máme 4 alternativy: na disk, do ram, do ram s případným probuzením a zapsáním na disk, do ram i na disk. Každé má své výhody a nevýhody a záleží na situaci.

[Ondrej 'SanTiago' Zajicek]

co když se to probudí v tašce, kde to má i během hibernace velkou šanci se přehřát?

No, horsi asi bude, kdyz se probudi zrovna ve chvili, kdy s nim v batohu na zadech nekde bezim nebo jedu na horskem kole krajinou (a notebook ma klasicky HDD).

[Kvakor]

A pokud máte starší notebook, kde baterie už má nejlepší léta za sebou a funguje spíš jako vestavěné UPSka, tak se obojetné uspání hodí, protože pokud se notebook v suspendu vybije "do mrťe", tak se místo normálního startu (a kontroly disků) protě jen odhibernuje.

[Václav HFechs Švirga]

Toho jsem si samozřejmě vědom, pokud by to fungovalo dobře, klidně bych u sebe uspání na disk v situacích, kdy ho potřebuju, nahradil tímto (pokud se baterka nevybije, mám šanci, že se mi ntb probudí rychleji - co víc si přát...), ale pokud potřebuju ntb rychle uspat a schovat, tak mi je tohle na nic, protože někdy se mi ta ram do swap oddílu zapisuje i 5 minut :-/, naopak uspání do ram je rychlejší než vypnutí!

[Jendа]

Mně se zase líbí to rychlé zapnutí. Ale samovznícení samoprobuzení už jsem asi dvakrát zažil :(.

Nicméně u mého EE není spotřeba v s2ram tak velká, aby se vyplatilo tlačit ten gigabajt na disk (protože disk nedá ani 20 MB/s ).

[Ondrej 'SanTiago' Zajicek]

EE ma jen 2/3 spotreby bezneho EEE? ;&ndash)

[Jendа]

Nevšiml jsem si, že by se po tom, co jedno E upadlo, snížila spotřeba .

[2X4B-523P]

asus k53sv s Debian wheezy se mi při slabé ze spánku probudí a sám zahibernuje, poprvé mě to vyděsilo a docela jsem zíral, že ta fičura takhle fachá sama od sebe jak to bude se starou baterií uvidím, můj funguje od prosince a používám baterii denně... baterii podle mého zabije trvalé připojení notebooku do el. sítě...

[Jendа]

baterii podle mého zabije trvalé připojení notebooku do el. sítě

Proč proboha?

[David Jaša]

Zkus pracovat s notebookem co rok nebyl mimo síť (tedy s baterkou o 0 cyklech) a pochopíš.

[chachar87]

tak ja takhle provozuju svuj ntb doma a nemam problem...ntb uz bude starsi tri let a z toho ty dva roky to provozuju trvale pripojene do site...vyjimecne jedu jenom z baterky ale kdyz jo tak vydrz pres 3 hodiny...kde je problem?

[David Jaša]

Tak to máš (mnou) nevídané štěstí na kvalitu elektroniky baterky.

[chachar87]

aspon neco to HPecko udelalo dobre, kdyz uz to chlazeni stoji za vyliz prdel :)

[Gilhad]

Tak nevim, ja mam NB pripojeny do site skoro porad (rekneme minimalne 24 h/denne, po 6 dni v tydnu) a po nekolika letech je baterie sice slabsi nez na zacatku, ale nijak zvlast vyrazne. Spis se mi zda, ze v porovnani s tim, jak zhuntovana by mela byt pri "beznem a planovanem" pouzivani, tak je stale jeste prekvapive dobra a lepsi, nez se planovalo.

[Michal Kubeček]

Nějak jsem si vsugeroval, že odstranění routing cache bude až ve 3.7, tak díky za vyvedení z omylu.

[Harvie.CZ]

Vtipnej dusledek asi bude, ze konkurencni vServer pravdepodobne dostane podporu checkpointovani na disk aniz by jeho vyvojari museli napsat vic nez par radek v bashi... vServer je proti OpenVZ spoustu let za opicema, ale i tak to treba oddali migrace z vServeru na OpenVZ u lidi, ktery potrebujou OpenVZ primarne kvuli checkpointovani...