Jaderné noviny – 24. 11. 2010: Uspávání jako na Androidu

13. 12. 2010 | Jirka Bourek | Jaderné noviny | 4857×

Aktuální verze jádra: 2.6.37-rc3. Citáty týdne: Linus Torvalds, Matthew Garrett, Dave Airlie. Alokátor velkých kusů paměti. Alternativa k blokovačům uspání.

Obsah

• Aktuální verze jádra: 2.6.37-rc3
• Citáty týdne: Linus Torvalds, Matthew Garrett, Dave Airlie
• Alokátor velkých kusů paměti
• Alternativa k blokovačům uspání
  • Probouzecí zámky
  • Záležitosti s časem
  • Alternativní implementace

Aktuální verze jádra: 2.6.37-rc3

Současné vývojové jádro je 2.6.37-rc3 vydané 21. listopadu. Linus řekl:

A musím říci, že jsem poměrně spokojený s tím, jak všechno probíhá v tichosti a klidu. Samozřejmě je možné, že se lidé schovávají ve křoví a čekají, aby mě mohli příští týden, kdy jedu do Japonska, přepadnout s hromadou patchů, a to všechno jenom proto, aby dělali potíže.

Jedna významnější změna je, že pokus zakázat ve výchozím nastavení čtení ze souboru /proc/kallsyms byl vzat zpět, protože přestala fungovat starší distribuce (Ubuntu Jaunty).

Zkrácený changelog je v oznámení; všechny detaily vizte v kompletním changelogu.

Stabilní aktualizace: 22. listopadu vyšly aktualizace 2.6.27.56, 2.6.32.26, 2.6.35.9 a 2.6.36.1; každá obsahuje dlouhý seznam důležitých oprav. 2.6.35.9 je poslední aktualizace série 2.6.35.

Citáty týdne: Linus Torvalds, Matthew Garrett, Dave Airlie

Já chápu, že nás lidi od softwaru si všichni idolizují. Ano, opravdu jsme lepší, chytřejší a vypadáme lépe než návrháři hardwaru. Život není fér a obdiv mas může být někdy až nesnesitelný. Když jdu nakupovat, během minut jsem pokrytý dámským spodním prádlem – je to prostě trapné.

Takže ano, jsme Tom Jones světa techniků.

Chápu tedy, že návrháři architektur mohou přijít k nějakým komplexům. To chápu. Ale i když je celý tvůj život naprostá fraška a titul máš v EE místo CompSci, bojuj za sebe, chlape!

Opakuj po mě: „Ano, také můžu udělat něco významného! Nejsem jenom zbytečný pytel masa! Můžu navrhnout hardware, který je zázračný a nebudu se za něj muset stydět! Můžu pomoci těm krásným lidem od software, aby jejich kód běhal lépe! Můj život má smysl!“

Není to dobrý pocit? Tak, teď se podívej na klávesnici, teď zpátky na mě. Dolů. Zpátky. Možná nikdy nebudeš tak krásný a chytrý jako softwarový inženýr, ale s Old Spice tak můžeš přinejmenším vonět.

Hardware a software by měly spolupracovat. A to neznamená, že by hardware měl prostě ležet jako mrtvá ryba a všechnu práci udělat software. Měl by se aktivně spolupodílet a být opravdu nadšený z vlastních součástek a schopností.

-- Linus Torvalds (díky Georgi Spelvinovi)

Operační systémy napsané normálními lidmi jenom výjimečně mají požadované výkonnostní charakteristiky.

-- Matthew Garrett

Samozřejmě vím, že cílem je vytvořit perfektní jádro pro hardware, který používá Linus, ale rád bych byl schopen urgentně opravovat chyby i na hardwaru lidí, kteří nemají taková privilegia; chápejte to jako streetwork.

-- Dave Airlie

Alokátor velkých kusů paměti

napsal Jonathan Corbet, 24 listopadu 2010

Ovladače zařízení – obzvláště ty, které musí obsluhovat low-end hardware – někdy potřebují alokovat velké a fyzicky spojité buffery v paměti. Když systém běží a paměť se fragmentuje, roste pravděpodobnost, že tyto alokace selžou. To vedlo k mnoha snahám, které jsou založeny na technikách jako odložení kusu paměti při bootu; alokátor spojité paměti [contiguous memory allocator, CMA], o kterém jsme tu psali v červenci, je jedním z příkladů. Nicméně je k dispozici alternativní přístup v podobě alokátoru velkých kusů paměti [big chunk memory allocator], jehož autorem je Hiroyuki Kamezawa.

Alokátor velkých kusů paměti poskytuje novou alokační funkci pro velké spojité bloky:

struct page *alloc_contig_pages(unsigned long base, unsigned long end,
                                unsigned long nr_pages, int align_order);

Na rozdíl od CMA si alokátor velkých kusů při bootu neodkládá paměť stranou. Místo toho se pokouší vytvořit dostatečně velký kus paměti při alokaci tak, že přestěhuje jiné stránky. Postupem času se mechanismy shlukování paměti [memory compaction] a migrace stránek zlepšily a paměti se zvětšily. Dá se tedy předpokládat, že alokace těchto větších kusů proběhne úspěšně častěji, než tomu bylo dříve.

Tento přístup má několik výhod. Vzhledem k tomu, že si nepotřebuje odložit paměť stranou, nemá na systém žádné dopady, když nejsou velké buffery zapotřebí. Také je flexibilnější a nevyžaduje, aby správce systému zjistil, kolik paměti je potřeba při bootu rezervovat. Nevýhodou je, že alokace paměti je dražší a zvyšuje se šance, že selže. Který systém bude v praxi fungovat lépe, nikdo neví; odpověď na tuto otázku bude vyžadovat hodně testování lidmi, kteří takto potřebují alokovat paměť.

Alternativa k blokovačům uspání

originál tohoto článku pro LWN.net napsal Rafael J. Wysocki

Jestli jste sledovali vývoj Linuxu za posledních několik měsíců, bylo těžké přehlédnout masivní vlákno na LKML, které vzešlo ze snahy Googlu začlenit blokovače uspání z Androidu do hlavní řady jádra. Lze se dohadovat, že prezentace těchto patchů mohla být lepší a vysvětlení problémů, které řešily, mohlo být přímočařejší [PDF], ale nakonec se ukázalo, že jejich začlenění by nebylo z technického úhlu pohledu tím nejlepším nápadem. To je bohužel těžké vysvětlit bez ponoření se do technických záležitostí, které se za sadou patchů blokovačů uspání skrývají, takže jsem napsal článek Technical Background of the Android Suspend Blockers Controversy [PDF], který je detailně diskutuje a který je shrnut v tomto článku.

Blokovače uspání či probouzecí zámky [wakelocks] v původní terminologii Androidu jsou součástí specifického přístupu ke správě napájení, který je založena na agresivním využívání kompletního uspání systému tak, aby se ušetřilo co největší množství energie. S tímto přístupem je přirozeným stavem systému režim spánku [PDF], ve kterém se energie používá pouze k obnovování paměti a poskytování napájení těm několika zařízením, která mohou vygenerovat signál pro probuzení. Do pracovního režimu, kde CPU vykonává instrukce a systém obecně dělá nějakou užitečnou práci, se vstoupí pouze v reakci na nějaký probouzecí signál od jednoho z vybraných zařízení. Systém v tomto stavu zůstane jenom tak dlouho, jak je nutné k vykonání práce požadované uživatelem. Když je tato práce dokončena, automaticky se zase uspí.

Tento přístup lze nazývat oportunistické uspávání, což má zdůraznit fakt, k uspání dojde pokaždé, kdy k tomu je příležitost. Efektivní implementace musí řešit mnoho problémů včetně možných souběhů mezi uspáváním systému a probouzecí událostí (tj. událostí, které způsobí, že se systém probudí z režimu spánku). Jmenovitě jedna z prvních věcí, která se provede během uspání systému, je uspání procesů v uživatelském prostoru (kromě uspávajícího procesu) a když je to dokončeno, uživatelský prostor již nemůže reagovat na žádné události signalizované jádrem. Důsledkem toho je, že pokud probouzecí událost nastane přesně v okamžiku, kdy se nastartuje uspání, uživatelský prostor může být zmrazen dřív, než dostane šanci událost zpracovat, takže mu bude doručena, až když je systém probuzen z režimu spánku po další probouzecí události. Bohužel na mobilním telefonu může být touto „odloženou“ událostí velmi důležitý telefonní hovor, takže scénář popsaný výše je pro takováto zařízení jenom těžko přijatelný.

Probouzecí zámky

Na Androidu byla tato záležitost vyřešena s pomocí probouzecích zámků. Probouzecí zámek je v podstatě objekt, který může být ve dvou stavech – aktivní či neaktivní – a systém nelze uspat, pokud je aktivní alespoň jeden zámek. Takže když jaderný subsystém řešící probouzecí událost aktivuje hned po jejím přijetí probouzecí zámek a deaktivuje ho, když je událost předána uživatelskému prostoru, souběh popsaný v předchozím odstavci lze odvrátit. Navíc na Androidu se uspání zahájí z jádra pokaždé, když nejsou žádné aktivní probouzecí zámky, což řeší problém rozhodování o tom, kdy se uspat; uživatelskému prostoru je umožněno manipulovat s probouzecími zámky. Bohužel to vyžaduje, aby každý proces v uživatelském prostoru, který dělá nějakou důležitou práci, probouzecí zámky používal, což vytváří neobvyklé a problematické záležitosti, se kterými se musí potýkat vývojáři aplikací.

Samozřejmé je, že proces používající probouzecí zámky může významně ovlivnit výdrž baterie, takže možnost používat je by měla být považována za privilegium a neměla by být dána k dispozici všem aplikacím bez přemýšlení. Bohužel ale není žádné obecné pravidlo, které by návrháři systému umožnilo zjistit, které aplikace jsou tak důležité, že by se jim ve výchozím nastavení mělo používání probouzecích zámků povolit. Tím pádem je rozhodnutí ponecháno na uživateli, což může fungovat jenom v případě, že je uživatel dostatečně kvalifikovaný k tomu, aby rozhodl správně. Krom toho, pokud se od uživatele očekává, že se rozhodne, měl by být přesně informován o možných důsledcích. Uživateli by také mělo být umožněno kdykoliv vybrané aplikaci zakázat používání probouzecích zámků; to se na Androidu nicméně přinejmenším do verze 2.2 včetně prostě neděje.

Krom toho některé vlastnosti aplikací na Androidu kvůli oportunistickému uspávání prostě nefungují. Konkrétně jde například o aplikace, které mají periodicky něco kontrolovat na vzdálených serverech v Internetu. Za tímto účelem se musí spustit, když přijde čas, ale to se zjevně nestane, když systém spí. Periodické kontroly, které by měly proběhnout, tedy neproběhnou ve správný čas; ve skutečnosti proběhnou pouze v případě, že systém v dané době náhodou běží z jiného důvodu. To s největší pravděpodobností není to, co uživatel postižené aplikace očekává.

Záležitosti s časem

Další problém spojený s kompletním uspáním systému souvisí s měřením času, i když to není omezeno na oportunistické uspání vyvolané z jádra. Každý cyklus uspání-probuzení, bez ohledu na to, jak byl vyvolán, zatahuje do jaderného subsystému pro udržování času nepřesnosti. Obvyklé je, že když se systém uspí, vypne se hardware pro měření času, na který daný jaderný subsystém spoléhá. Během následujícího probuzení je tedy potřeba ho znovu inicializovat. Mezi jinými je poté potřeba přenastavit globální jaderné proměnné reprezentující aktuální čas, aby se reflektoval čas strávený v režimu spánku. To znamená načíst aktuální hodnotu času z trvalých hodin, které jsou typicky mnohem méně přesné než hodiny, které jádro používá za běhu. To tedy během každého cyklu uspání-probuzení zavádí náhodný posun jaderné reprezentace aktuálního času závislý na rozlišení trvalých hodin. Jaderné časovače používané pro naplánování budoucí práce v jádře jsou touto záležitostí postiženy podobným způsobem. Následkem toho je, že časování některých událostí v systému, který se uspává a probouzí, se liší od analogického časování na systému, který běží bez přerušení.

Pokud je uspání spuštěno z uživatelského prostoru, jádro může předpokládat, že uživatelský prostor je na to připraven a nějak se vyrovná s následky. Například může použít settimeofday() a nastavit monotonické hodiny jádra podle času získaného z NTP serveru těsně po probuzení systému. Na druhou stranu pokud uspání zahájí jádro oportunisticky, uživatelský prostor nemá žádnou šanci něco takového udělat.

Z tohoto důvodu by se zdálo, že by bylo lepší systém vůbec neuspávat a místo toho použít pro správu napájení systému framework cpuidle. Tento přístup podle všeho umožňuje některým systémům přechod do stavu snížené spotřeby, který připomíná režim spánku. Tento framework nicméně nemusí garantovat, že systém bude do tohoto stavu přepínán dostatečně často kvůli aplikacím, které používají čekací smyčky, a kvůli jaderným časovačům. Požadavky na kvalitu služby PM [PDF] mohou cpuidle také zabránit použít stav hlubokého spánku CPU. Krom toho i když je během uspání jenom několika zařízením povoleno signalizovat probuzení, rutiny správy napájení za běhu, které cpuidle může použít pro uspání I/O zařízení, mají tendence umožnit signalizovat probuzení všem. Systém se tedy ze stavů nízké spotřeby probouzí mnohem častěji než ze „skutečného“ režimu spánku, takže jeho schopnost šetřit energii je omezena. To zjednodušeně znamená, že systém založený na cpuidle nemusí být dostačující a neušetří na stejném hardwaru stejné množství energie jako oportunistické uspávání.

Alternativní implementace

I když se na daném systému nebude používat oportunistické uspávání, dává smysl systém občas uspat – například v situaci, kdy uživatel ví, že v blízké budoucnosti nebude muset nic dělat. Nicméně problém možných souběhů mezi uspávajícím procesem a probouzecími událostmi, který je na Androidu řešen probouzecími zámky, postihuje všechny podoby uspání, ne pouze ty oportunistické. Problém by tedy měl být řešen obecně a není vhodné jednoduše pro tento účel použít probouzecí zámky, protože to by znamenalo modifikovat všechny programy v uživatelském prostoru, aby je používaly. I když pro Android, jehož uživatelský prostor je již v určitém rozsahu takto navržen, jsou dobré, nebyly by velmi praktické pro jiné linuxové systémy, jejichž uživatelský prostor rozhraní probouzecích zámků nepoužívá. To vedlo na patch jádra, který zavádí framework probouzecích událostí, který byl vydán v jádře v 2.6.36.

Patch zavádí čítač signalizovaných probouzecích událostí event_count a čítač probouzecích událostí, jejichž data jsou v dané chvíli zpracovávána jádrem, events_in_progress. Byla přidána dvě rozhraní, která jaderným subsystémům umožňují tyto čítače modifikovat konzistentně: pm_stay_awake() má zabránit systému v uspání, zatímco pm_wakeup_event() zajišťuje, že systém zůstane vzhůru během zpracování události.

Za tímto účelem pm_stay_awake() inkrementuje events_in_progress a doplňková funkce pm_relax() ho dekrementuje a zároveň inkrementuje event_count. pm_wakeup_event() inkrementuje events_in_progress a nastavuje časovač, který ji v budoucnu dekrementuje a inkrementuje event_count.

Současnou hodnotu event_count lze přečíst z nového souboru v sysfs /sys/power/wakeup_count. Zápis do tohoto souboru způsobí, že se současná hodnota event_count uloží do pomocné proměnné saved_count, takže ji lze v budoucnu porovnat s aktuální event_count. Zápis nicméně uspěje jenom v případě, že zapsané číslo je shodné s event_count. Pokud se to stane, je nastavena další pomocná proměnná events_check_enabled, která jádru správy napájení řekne, aby zkontrolovalo, jestli se nezměnil event_count nebo jestli se při uspání systému events_in_progress rovná nule.

Tento relativně jednoduchý mechanismus umožňuje jádru správy napájení reagovat na probouzecí události signalizované během uspání systému, pokud je o to požádán uživatelským prostorem a pokud jaderný subsystém detekující probuzení používá buď pm_stay_awake() nebo pm_wakeup_event(). Nicméně jeho podporu pro sběr statistik zařízení spojených s probouzením nelze srovnávat s tou, kterou nabízí framework probouzecích zámků. Krom toho předpokládá, že probouzecí události budou vždy spojené se zařízením nebo přinejmenším s entitami, které jsou reprezentovány objektem zařízení, což ve všech situacích nemusí být pravda. Potřeba řešit tyto nedostatky vedla k jadernému patchi zavádějícímu objekty zdrojů probuzení, které existující framework rozšiřuje o více flexibility.

Nejdůležitější je, že nový patch zavádí objekty typu struct wakeup_source, které reprezentují entity, které mohou vygenerovat probouzecí události. Tyto objekty jsou automaticky vytvořeny pro zařízení, kterým je povoleno signalizovat probuzení, a interně se používají v pm_wakeup_event(), pm_stay_awake() a pm_relax(). I když rozhraní na nejvyšší úrovni jsou stále navržena tak, že hlásí probouzecí události relativně k zařízením, což je obzvláště vhodné pro ovladače zařízení a subsystémy, které obvykle pracují s objekty zařízení, nový framework umožňuje používat probouzecí objekty přímo.

„Samostatný“ objekt – zdroj probouzení je vytvořen funkcí wakeup_source_create() a přidává se do jaderného seznamu zdrojů probuzení funkcí wakeup_source_add(). Poté lze používat tři nová rozhraní __pm_wakeup_event(), __pm_stay_awake() a __pm_relax(), která s ním manipulují; když objekt již není zapotřebí, lze ho odstranit z globálního seznamu voláním wakeup_source_remove() a smazat pomocí wakeup_source_destroy(). Hlášené probouzecí události tedy již nemusí být spojeny s objektem zařízení. Na úrovni jádra je navíc možné probouzecí zámky Androidu nahradit objekty probouzecích událostí jeden za jeden, protože rozhraní výše jsou naprosto analogická k těm, která zavádí framework probouzecích zámků.

Infrastruktura popsaná výše by měla zjednodušit portování ovladačů zařízení Androidu do hlavní řady jádra. Nebyla navržena s ohledem na oportunistické uspávání, ale teoreticky by ji mělo být možné použít k implementaci velmi podobné techniky. V principu lze všechny probouzecí zámky v jádře Androidu nahradit objekty zdroje probuzení. Pak, pokud se správně použije rozhraní /sys/power/wakeup_count, bude výsledné jádro schopno zastavit uspání v reakci na probouzecí události za stejných okolností jako původní jádro Androidu. Uživatelský prostor ale nemůže k objektům zdroje probuzení přistupovat, takže tu část frameworku probouzecích zámků, která umožňovala uživatelskému prostoru s nimi manipulovat, bude nutné nahradit jinými mechanismy implementovanými zcela v uživatelském prostoru, což zahrnuje proces správy napájení a vhodné IPC rozhraní pro procesy, které by v Androidu používaly probouzecí zámky.

IPC rozhraní by mohlo být implementováno s použitím tří komponent: sdílené paměti, která by obsahovala čítač nazvaný „čítač uspání“, následuje mutex a podmínečná proměnná spojená s tímto mutexem. Pak by proces, který chce systému zabránit v uspání, získal mutex a inkrementoval čítač; proces, který by chtěl systému umožnit uspání, by získal mutex a dekrementoval čítač. Pokud by v tu chvíli čítač dosáhl nuly, procesy čekající na podmínečnou proměnnou by se odblokovaly. Mutex by byl následně uvolněn.

S IPC rozhraním výše by proces správy napájení mohl ve smyčce dělat následující:

1. Číst /sys/power/wakeup_count (to bude blokovat, dokud jaderná proměnná events_in_progress nebude nulová)
2. Získat mutex
3. Zkontrolovat, jestli je čítač uspání roven nule. Pokud ne, zablokovat se na podmínečné proměnné (to mutex automaticky uvolní) a po odblokování se vrátit k bodu 2.
4. Uvolnit mutex
5. Zapsat hodnotu přečtenou v kroku 1 zpět do daného souboru. Pokud zápis selže, přejít k bodu 1
6. Zahájit uspání nebo hibernaci a vrátit se k bodu 1, když se dokončí

To samozřejmě znamená, že by systém byl uspáván velmi agresivně. I když to není zcela ekvivalentní oportunistickému uspávání Androidu, zdá se, že se mu blíží dostatečně na to, aby se uspořilo stejné množství energie. Tento přístup nicméně také trpí mnoha problémy, které přístup Androidu má. Některé z nich lze vyřešit zesložitěním správce napájení a IPC rozhraní mezi ním a procesy, které blokují a povolují uspání, ale jiným se vyhnout nejde. Možná by tedy bylo lepší systém uspávat méně agresivně, ale v kombinaci s jinými technikami popsanými výše.

Celkově, i když nápad uspávat systém agresivně může být kontroverzní, nezdá se být rozumné úplně zavrhnout automatické uspávání jako platné opatření pro úsporu energie. Mnoho dalších operačních systémů dělá totéž a díky tomu dosahují dobré životnosti na baterie. Není zde žádný důvod, proč by se linuxové systémy nemohly chovat stejně, obzvláště když nemají k dispozici napájení z elektrické sítě. Co se desktopů a podobných systémů (laptopy, netbooky) týče, dává smysl nakonfigurovat je tak, aby se v některých situacích automaticky uspávaly, pokud je známo, že uspání systému na daném hardwaru funguje spolehlivě. K tomu by se mohla použít nová rozhraní a nápady zmíněné výše.

       

Komentáře

[Milan Lajtoš]

Ten Linusov komentár o HW je epický! :)

[Zdenek]

A mel i jiny smyl nez jen informovat, ze Linus pouziva Old Spice?

[Jan Marek]

Jasně. Hlavně informoval o tom, že když jde Linus nakupovat, tak je po několika minutách pokryt spodním dámským prádlem...

[frankenštajn]

hele jsem laik, takže nevím, jestli píšu o tý samý věci jako je blokování uspávání. Zajímá mě, jestli už někdo řeší tu nepříjemnost, že se mi spouští spořič obrazovky při sledování videa v Adobe flash playeru v prohlížeči. Je to fakt nepříjemný a nikde se mi to nepodařilo nijak nastavit.

[Selmi]

skus nainstalovat programik caffeine https://launchpad.net/caffeine

[Radek]

Existuje neco takovyho jako Caffeine taky pro Fedoru?

[kyytaM]

V gnome je applet pre gnome-panel s menom Ihibit, ktory je tusim na potlacenie spanku. :)

[frankenštajn]

nojo, ale proč to neumí poznat gnome samo od sebe, že když koukam na flash, tak nechci aby spalo? Windows to umí, Gnome to umí třeba u filmů, tak v čem je problém?

[Jendа]

Buď by musel usínání blokovat přímo Flash nebo by se musel Flash detekovat a podle toho blokovat uspávání. V prvním případě je chyba Flashe, jestli to nedělá, ve druhém je to prasárna (a záležitost pár řádků v bashi), která zabrání usnutí, když necháš zapnutý prohlížeč se spuštěnou reklamou.

[frankenštajn]

tak v tom případě by měli soudruzi z Adobe opravit flash, protože ve Win to nedělá

[MX]

Víte co byla bomba?

Kdyby se do cache procesoru vešlo jádro s moduly...

... a X-window, FF, T-bird, mplayer, OO, flash :)))

[Jan Grmela]

Flash? To abych si pořídil nový, aspoň čtyřjádrový, procesor jen pro něj

[disorder]

mne by stacil 120G MLC SSD za 100 €

[trekker.dk]

Ach jo. Já vim, že jste se rozhodli přidávat do těch článků nadpisy za každou cenu, ale "Uspávání jako na Androidu"? Jako? Článek je o tom, jak uspávání Androidu dostat do jádra, žádné jako...

[Jirka]

Podle me jde prave o to jako.

Uspavani Androidu bylo uz odmitnuto. Ted jde o to dostat do jadra neco, co se mu bude, co se usporene energie tyce, aspon hodne blizit. Nebude to ale totez.

Prijde mi to z clanku docela zrejme. Leda, ze bych mel jako produkt ceskeho skolstvi problem s chapanim textu.

[trekker.dk]

Ted jde o to dostat do jadra neco, co se mu bude, co se usporene energie tyce, aspon hodne blizit.

...a co bude Android používat, tudíž to bude uspávání na Androidu

[Jirka]

Taky bych chtel mit vesteckou kouli.

[Pev]

"postav za sebe, chlape!" nezní moc česky :).

[Jirka]

To je něco jako "All your base..."

Jednou z toho bude kultovní hláška.

[Luboš Doležel (Doli)]

Dal jsem tam bojuj.

[Jirka]

Bojovat za sebe? V danem kontextu nevim, nevim... Neslo by tam dat jen to "bojuj"?

[Luboš Doležel (Doli)]

"Stand up for yourself" není prostě jen "bojuj".

[m-a]

Co takto: Hlavu hore !

[Luboš Doležel (Doli)]

?! To se tomu významově ani trochu nepodobá.

[prcek]

"Stuj si za svym." ?
nebo opisem v kontextu
"Tak s tim neco delej." ?

[Jirka]

Ptám se, abych pořád netápal, co si mám koupit.

[HonzaRez]

Mac.