Pegasusq guvernér

Pegasusq guvernér


Většina z nás jsme flash maniaci, a děláme to hodně. Ale pro jádra flash, jsme se můžeme divit: Q1. "Dobře jsem se blýskl /flash/toto jádro xyz. Co všechny tyto guvernéry Jak mám vědět, který z nich je pro mě nejlepší? Jak mohu vyladit jejich podjatosti své postavy do Battery-life/Performance/Balance mezi nimi." Q2. "Co je to fuzz o těchto modulů, které přichází s jádrem. Jak mohu používat. Jsou k ničemu. Je to OK, opomíjet?" Q3. "Jakou roli má I / O plánovače hru Jak si vybrat spolehlivý I / O plánovač?" Q4. "Mohu mít větší kontrolu na CPU: Více informací a vychytávky na dvoujádrový procesor, Frekvence sběrnice, atd.?" Q5. "Lepší pochopení vlivu různých hodnot pro základní / pokročilé parametry v App konfiguračním systému jádra, takže mohu vyladit nastavení podle svého vkusu?" Doufám, že toto vlákno mohl dát odpovědi na všechny tyto otázky. Jsme pokrývající guvernéry, moduly, I / O plánovače, který je dodáván s jádrem Siyah, a další. To by mělo pokrýt téměř všechny populární guvernéry / modules / IO plánovačů! Mnoho lidí se zdá, aby se ztratil v závitech jádra dev bez získání odpovědi o guvernéry a podobně. Informace v tomto vlákně má dobré pro non-Siyah jádra uživatelé taky. Měli byste najít zde informace o většině z guvernérů / modulů / IO plánovače v jádře, ne-li všechny. Díky 1) Gokhanmoral pro jeho mocnou sladké jádro Siyah, které mě inspirovalo k napsání tohoto vlákna. 2) moderátorů pro mačkání v dalších pozic když jsem běžel z vesmíru, aby se vešly vše pouze 3 volná místa. 3) Uživatelé / Čtečky pro vaše teplé komentáře. příspěvek 1: KERNEL guvernérů PO 2: guvernér vychytávky POST 3: zatížitelné moduly jádra PO 4: I / O plánovače POST 5 : Dual Core CPU Q & A a vylepšení PO 6: Konfigurace KERNEL AIO APP - Perník POST 7: KONFIGURACE KERNEL AIO APP - ICS





























1.. Guvernéři

I) MANUAL:

. Jedná se o 19 guvernéři mluvíme 1) OnDemand 2) Ondemandx 3) Konzervativní 4) Interaktivní 5) Interactivex 6) Lulzactive 7) Lulzactiveq 8)chytráku 9) SmartassV2 10) Intellidemand 11) Lazy 12) Lagfree 13) Lionheart 14) LionheartX 15) Brazilianwax 16) SavagedZen 17) Userspacce 18) úspory energie 19) Výkon Poznámka : Informace na vlastní Samsung multi-core vědomi guvernéra - Pegasusq je zde 1) OnDemand: Výchozí guvernér v téměř všech akciových jader. Jedním z hlavních cílů guvernéra OnDemand je přepnout na frekvenci max. jakmile tam je CPU zjištěna činnost s cílem zajistit schopnost systému. (Můžete toto chování změnit pomocí hladké škálování parametrů naleznete Siyah vychytávky na konci třetí místo.) Efektivně využívá CPU čas činnosti jako odpověď na otázku "jak důležitý je výkon právě teď" otázku. Takže OnDemand skočí na maximální frekvenci CPU, když je obsazeno a snižuje frekvenci postupně, když je CPU méně zatížený / apporaching nečinnosti. I když mnozí z nás považují tuto spolehlivou guvernér, nedosahuje na úspory baterie a výkon na výchozí nastavení. Jeden potenciální důvod pro guvernéra OnDemand nebyla příliš energeticky úsporný je, že guvernér rozhodne o další cílové frekvenci okamžité požadavkem při intervalu vzorkování. V okamžiku, kdy požadavek může reagovat rychle na změny zátěže, ale to obvykle neodráží skutečné vytížení procesoru využití požadavek v malém delší dobu, a to možná způsobuje často měnit mezi nejvyšší a nejnižší frekvence. 2) Ondemandx: V podstatě ondemand se pozastaví / Probuzení profily . Tento guvernér má být přátelské baterie ondemand. Když obrazovka je vypnutá, je maximální frekvence omezena na 500 MHz. I když OnDemand je výchozí guvernér v mnoha jádře a je považován za bezpečný / stabilní podpora pro OnDemand / ondemandX závisí na CPU schopnosti dělat rychlé přepínání frekvence, které jsou velmi nízké frekvence přechodů latencí. Někde jsem četl, že výkon OnDemand / ondemandx významně liší pro různé i. / o plánovače. To není pravda, pro většinu ostatních guvernérů. Osobně se domnívám, ondemand / ondemandx jde nejlépe s SIO I / O plánovač. 3) Konzervativní: pomalejší OnDemand, které váhy se pomalu, jak ušetřit baterii. Konzervativní guvernér je založen na guvernéra OnDemand. Funguje jako OnDemand guvernéra dynamicky nastavení frekvencí založených na využití procesoru. Nicméně, konzervativní guvernér zvyšuje a snižuje rychlost procesoru pozvolna. Jednoduše řečeno, to guvernér zvyšuje frekvenční krok za krokem na zatížení CPU a skočí na nejnižší frekvenci procesoru na volnoběh. Konzervativní guvernér chce dynamicky měnit frekvenci procesoru na současné využití bez skákání na frekvenci Max. Sampling_down_factor hodnota slouží jako negativní multiplikátor vzorkovací_kmitočet snížit frekvenci, plánovač vzorky využití procesoru. Například, pokud vzorkovací_kmitočet roven 20.000 a sampling_down_factor je 2, guvernér vzorky využití procesoru každých 40.000 mikrosekund. 4) Interaktivní: Může být považován za rychlejší ondemand. Takže ještě pohotovější a méně baterií. Interaktivní je určen pro latence citlivé, interaktivní zatížení. Místo odběru vzorků v každém intervalu, jako OnDemand, určuje, jak škálovat, když CPU vychází z nečinnosti. Guvernér má následující výhody: 1) více konzistentní stupňovat, protože stávající hejtmani dělat svou zatížení CPU odběr v workqueue kontextu, ale interaktivní guvernér dělá to v souvislosti s časovačem, který dává více konzistentní zatížení CPU vzorku. 2) Vyšší prioritu pro zvýšení frekvence CPU, čímž dává Zbývající úkoly CPU zvýšení výkonu, na rozdíl od stávajících guvernérů, které naplánujte rozběhu pracují nastat po svůj výkon hladověl úkoly byly dokončeny. Interaktivní Je to inteligentní OnDemand pochybností o stabilitě optimalizace. Proč?? Odběr zatížení CPU každé x ms (jako OnDemand) může vést k pod-napájení CPU na X ms, což vedlo k výpadkům snímků koktání UI atd., místo odběru procesor ve stanoveném poměru, budou interaktivní guvernér zda měřítko frekvence CPU brzy po příchodu z nečinnosti. Když CPU vychází z nečinnosti, je časovač nastaven na oheň během 1-2 klíšťat. Pokud je CPU je velmi zaneprázdněn mezi ukončením klidu a při časovém požáry, pak předpokládáme, že procesor je poddimenzované a nájezd na frekvenci Max. 5) Interactivex: Jedná se o interaktivní guvernér se probudit profilu. . Více než přátelské baterie interaktivní 6) Lulzactive: Tento nový nález z Tegrak je založena na interaktivních a chytrák guvernérů a je jedním z favoritů. Stará verze : Při zatížení je větší než nebo rovna 60%, guvernér váhy do CPU na další vyšší stupeň. Při zatížení je menší než 60%, guvernér váhy dolů CPU na nejbližší nižší kroku. Když obrazovka je vypnutá, je frekvence zablokovaná na globální změny frekvence minimum. Nová verze : další tři uživatelsky konfigurovatelných parametrů: inc_cpu_load, pump_up_step, pump_down_step. Na rozdíl od starší verze, tentokrát dává větší kontrolu pro uživatele. Můžeme stanovit prahovou hodnotu, při které regulátor rozhodne škálovat nahoru / dolů. Můžeme také nastavit řadu frekvenčních kroků, které mají být přeskočena při dotazování nahoru a dolů. Když zátěž větší než nebo rovno inc_cpu_load , guvernér váhy CPU pump_up_step stupňuje. Při zatížení je menší než inc_cpu_load, guvernér váhy CPU dolů pump_down_step schodech dolů. Příklad: Uvažujme inc_cpu_load = 70 = 2 pump_up_step pump_down_step = 1 Pokud je aktuální frekvence = 200, každý up_sampling_time nás, pokud zatížení CPU> = 70%, se cpu škálovat až 2 kroky - do 800. Pokud je aktuální frekvence = 1200, Každý down_sampling_time nás, pokud cpu zatížení <70%, se cpu zmenšen 1 krok - na 1000. 7) Lulzactiveq: Lulzactiveq je upravený lulzactive guvernér autorem XDA člen robertobsc a je upraven v Siyah jádro GS2 a GS3. Lulzactiveq usiluje o optimalizaci druhou verzi luzactive z Tegrak o) poskytuje další parametr (dec_cpu_load), aby redukovali rozumnější, a b) začlenění hotplug logiku guvernéra. Luzactiveq je vůbec první interaktivní bázi guvernér s vestavěnými hotplugging logiky (aspoň první svého druhu pro platformu Exynos). Když CPU vychází z nečinnosti smyčky a to je čas, aby se měřítko rozhodnutí, je-li zatížení> = inc_cpu_load CPU zmenšen nahoru (jako původní luzactiveq), a je-li zatížení <dec_cpu_load je CPU zmenšen. To možná eliminuje striktní jediné mezní kmitočet pro luzactiveq pro rozhodování CPU měřítka. Také stojí hotplug logika běží jako samostatné vlákno s guvernérem, aby vnější hotplugging logika není povinna kontrolovat hotplug dovnitř a ven (zapnout a vypnout) procesorová jádra v bytových základních zařízení, jako GS2 nebo GS3. Pouze multi core vědomi guvernér dává skutečný smysl pro Muti-core zařízení. Lulzactiveq a pegasusq chce udělat. 8)chytrák: Výsledek Erasmux přepisování kompletní kód interaktivního guvernéra. Hlavním cílem je optimalizovat životnost baterie, aniž by zahrnující výkon. Přesto není tak přátelské baterie jako smartassV2 od obrazovky na minimální frekvence je vyšší než frekvence používaných při screen-off. Chytrák by se skákat až do nejvyšší frekvence příliš často stejně. 9) SmartassV2: verze 2 z původního chytráku guvernér z Erasmux. Dalším favoritem pro mnoho lidí. Guvernér Cílem pro "ideální frekvence", a rozjet agresivněji k této frekvence a méně agresivní po. Používá různé ideální frekvence pro obrazovky na obrazovce a vypnout, a to awake_ideal_freq a sleep_ideal_freq. Tohoto regulátoru váhy dolů procesoru velmi rychlé (zasáhnout sleep_ideal_freq brzy), zatímco obrazovka je vypnutá a váhy až rychle awake_ideal_freq (500 MHz pro GS2 ve výchozím nastavení), pokud je na obrazovce. Neexistuje žádný horní limit pro frekvenci, zatímco obrazovka je vypnutá (na rozdíl od chytrák). Takže celý frekvenční rozsah je k dispozici guvernér k použití během obrazovka-on a screen-off stavu. Mottem tohoto regulátoru je rovnováha mezi výkonem a baterie. 10) Intellidemand: Intellidemand aka Inteligentní OnDemand od Faux je dalším guvernér, který je založen na OnDemand. Na rozdíl od toho, co někteří uživatelé se domnívají, to guvernér není náhradou za OC Daemon (s různými guvernéry pro poruchy spánku a probudit). Původní intellidemand chová odlišně v závislosti na GPU použití. Když GPU je opravdu zaneprázdněn (hry, mapy, benchmarking, atd.) intellidemand chová jako OnDemand. Když GPU "volnoběh" (nebo mírně obsazeno), intellidemand omezuje max. frekvenci kroku v závislosti na frekvencích dostupných v přístroji / kernel pro uložení baterie. Tato funkce se nazývá režimu prohlížení. Můžeme vidět nějaké "stopy" interaktivního guvernéra zde. Frekvence scale-up je rozhodnuto na základě volnoběhu čas CPU. Dolní volnoběhu čas (<20%) způsobí, že procesor pro scale-up z aktuální frekvence. Frekvenční rozsah-down se děje v krocích = 5% max. frekvence. (Tento parametr je laditelný pouze konzervativní mezi oblíbené guvernérů ) Abych to shrnul, je to inteligentní ondemand, že vstoupí do režimu prohlížení omezit max. frekvence GPU, když běží na volnoběh, a (opuštění režimu prohlížení) se chová jako OnDemand, když GPU je obsazeno; dodat výkon pro hraní her a tak. Intellidemand že nelze přeskočit na nejvyšší frekvenci, pokud obrazovka je vypnutá. 11) Lazy: Tento guvernér z Ezekeel je v podstatě ondemand s dalším parametrem min_time_state určit minimální dobu CPU zůstává na frekvenci před škálováním nahoru / dolů. Myšlenka je zde k odstranění jakýchkoli nestability způsobené rychlým přepínání frekvence by OnDemand. Lazy guvernér ankety častěji než OnDemand, ale změny frekvence až po dokončení min_time_state na skokovém převažujícího intervalu vzorkování. Lazy má také screenoff_maxfreq parametr, který při aktivaci způsobí, že guvernér vždy zvolit maximální frekvenci, zatímco obrazovka je vypnutá. 12) Lagfree: Lagfree je podobný OnDemand. Hlavním rozdílem je jeho optimalizace, aby se staly přátelské baterie. Frekvence je elegantně snížil a zvýšil na rozdíl od OnDemand, který skáče na 100% příliš často. Lagfree nemá vynechá frekvenční krok při škálování nahoru nebo dolů. Nezapomeňte, že pokud existuje požadavek na náhlý výbuch energie, můžete lagfree neuspokojuje, že jelikož má zvýšit cpu přes každý vyšší frekvencí kroku od proudu. Někteří uživatelé hlásí, že přehrávání videa pomocí lagfree koktání trochu. 13) Lionheart: Lionheart je konzervativní bázi guvernér, který je založen na Update3 zdroj Samsung. Tweaky pochází z 1) Knzo 2) Morfic. Původní myšlenka pochází z Netarchy. Podívejte se zde . . The tunables (např. prahy a vzorkovací frekvence) byly změněny tak, aby guvernér se chová více jako výkon jednoho, za cenu baterie jako měřítko je velmi agresivní k "zkušeností" Lionheart pomocí konzervativní, zkuste tyto vychytávky: vzorkovací_kmitočet: 10000 nebo 20000 nebo 50000, podle toho, co cítíte, je bezpečnější. (Přechod latence procesoru je něco pod 10ms/10, 000uS tedy pomocí 10.000 nemusí být bezpečné). up_threshold: 60 down_threshold: 30 freq_step: 5 Lionheart Hodí se termínem I / O plánovač. Pokud jde o hladkosti (bez zohlednění vybití baterie), laděný konzervativní přináší více ve srovnání s laděným OnDemand. 14) LionheartX LionheartX je založen na Lionheart, ale má pár změn na tunables a má profil na základě úsporného regulátoru chytráku. 15) Brazilianwax: Podobně jako smartassV2. Více agresivní náběh, tak vyšší výkon, menší baterie. 16) SavagedZen: Další smartassV2 založené guvernér. Dosahuje správnou rovnováhu mezi výkonem a baterie ve srovnání s brazilianwax. 17) v uživatelském prostoru: Místo určení frekvence automaticky, umožňuje frekvence uživatelsky nastavit. 18.) úsporně: Zámky max. frekvence na frekvenci min. Nelze použít jako spořič-na, nebo dokonce obrazovka-off (pokud je měřítko min frekvence je příliš nízká). 19) Výkon: Nastaví minimální frekvence jako frekvence Max. Použijte tento zatímco benchmarking! Takže, guvernéři rozdělit do 3/4 na vysoké úrovni: 1.a) OnDemand Based: Pracuje na "ramp-up na vysoké zatížení" principu. CPU zaneprázdněný lhůta je vzít v úvahu při rozhodování měřítka. Členové:. OnDemand, OndemandX, Intellidemand, Lazy, Lagfree 1.b) konzervativní na: Členové: Konzervativní, Lionheart, LionheartX 2) Interaktivní Based: Pracuje na "make měřítka rozhodnutí, když CPU pochází z nečinnosti smyčky" principu. Členové: Interaktivní, InteractiveX, Lulzactive, Luzactiveq, chytráku, SmartassV2, Brazilianwax, SavagedZen. 3) Weird Kategorie: Členové: uživatelském prostoru, úspory energie, výkonnost.

Řekněte mi, která guvernér je pro výkon a který z nich je pro životnost baterie." A. těžká otázka! lulzactive a smartassV2 pro rovnováhu mezi výkonem a baterie. U lehkých úkolů by lulzactive být lepší pro baterii. A těžké váhy úkolů by lulzactive být lepší pro výkon také. Chcete-li získat maximální výkon, použijte vylepšený OnDemand nebo konzervativní, ale nikdy si stěžují na baterie. POZNÁMKA: Není to tak jednoduché zkrotit luzactive. Pokud nevíte, jak přesně to udělat, drž se dál od něj, nebo skončí stěžují vybití baterie! Q. "Hele, málem jsem zapomněl. Jak změním guvernéry?" A. Nejlepší způsob je použít init.d skript, vaše jádro podporuje. (Echo "guvernér-name"> / sys/devices/system/cpu/cpu0/cpufreq / scaling_governor) Else použít pro regulaci napětí / / SetCPU žádné kudrlinky / Antuntu CPU mistr, atd. Voltage Control má rozhraní pro GPU oc / uc / uv a náboje změna proudu, pokud vaše jádro podporuje. Jak jsme uhodli, budou tyto aplikace, informujte nás o aktivní guvernéra taky. Q. "Jak mám vědět, který guvernér je pro mě nejlepší?" A. Záleží na tom, co budete potřebovat a každodenní použití vzor. Výkon nebo baterie. Lepší si vybrat guvernéra, který je vyvážený pro baterii / výkon. Nebo vyladit guvernéra dávají výkon v horní ruky ve srovnání s baterií. Můžeme vždy znovu nabít telefon: V autě, když do práce, nebo přes noc. Ale nemůžeme dobít výkon! Koneckonců, jsme koupili GS2 těšit, že je to naprostá síla. Q. "Tak jsem nastavit můj oblíbený guvernéra jako obrazovky na guvernéra a druhé jako screen-off guvernéra. Proč sakra je telefon nevzbudí po hlubokém spánku. Musím nutit restart telefonu stisknutím tlačítka napájení po dobu asi 10 secs. Je to spánek-of-death? " A. Ano, je. Nepoužívejte dva guvernéry jako obrazovka-on a screen-off GOVS, pokud oba mají horní limit frekvence pro obrazovky vypnutém stavu. Copak to? Příklady Wrong kombinací: (screen-on: screen-off): - ondemandX: smartassV2 Příklady pro správné kombinace: - OnDemand: smartassV2, lulzactive: smartassV2 Q. "Cítím mírné zpožděním sem a tam s guvernérem Pro ex:. Při procházení App zásuvky / vertikální rolování prohlížeč, atd. Mám ráda tento guvernéra a neříkej mi, použít jiný guvernér Mohu snížit toto zpoždění.? " A. Hmm dobře, můžete. V podstatě to, co musíme udělat, je guvernér "anketu" méně často měřítko dolů cpu. Zvýšení dolů vzorkovací čas svého regulátoru (podle toho, která odpovídá parametr), tak, že procesor zůstane déle na frekvenci, než zmenšuje. To by mělo eliminovat zpoždění. Q. "I když nemám moc UV / OV, jednou za čas,. Může být jednou za dva týdny, i zažít zmrazení / zámek / reboot jsem pomocí regulátoru X. Jak mohu vyřešit?" . No, náhodný restart / zmrazení jednou za čas, znamená to, že jsme android / Galaxy SII nadšence. Pokud půjde vše hladce jako hedvábí, co je sranda? Mohli bychom použít stock rom / kernel / guvernéra a být šťastný. Vzácný restart nebo zamrznutí je čeho se bát. Jen telefon restartovat. Q. "OK. Chci vylepšit tyto guvernéry podle mé použití vzoru, protože nejsem spokojena s výchozím chování těchto guvernérů." A. Můžete upravit guvernérů pomocí init.d skript echo vhodné hodnoty "20000" / sys / devices / system / cpu / cpufreq / lulzactive / up_sample_time Q. "Jdu k nastavení měřítka min frekvence jako 100 MHz, protože můj kernel podporuje. Doufám, že není nic špatného na tom, že." A. Počkejte! Možná budete chtít, aby zůstali daleko od používání 100MHz při screen-off na obrazovce nebo na státy ze tří důvodů 1) Zdá se, že 100 MHz je spotřeba energie větší než 200 MHz. Podle výsledků testů, 100 MHz účtovány do 1 W / GHz a 200 MHz až 0,7 W / GHz, kdy obě jádra jsou online. 2) 200 MHz je možné dokončit stejný úkol rychlejší oproti 100 MHz, a proto zasáhla hluboko nečinnosti brzy. 3) 200 MHz je "sweet spot" frekvence na SGS II. tj. frekvence použité ve výpočtech na základě optimální energii pro provoz (např.: V Milestone je 550 MHz). Takže, "energeticky efektivní" frekvence pro naši CPU je 200 MHz. Q. "Chci vědět, je, že je to něco víc mohu udělat pro zlepšení výdrže baterie. Již jsem vylepšil své nastavení regulátoru, ale ..." A. Věř mi. Nejlepší způsob, jak je omezit měřítka max. frekvence na 800 nebo 1000 MHz. Sgs2 může dělat většinu úkolů s 1000 nebo 800 jako maximum. OCing na 1600 MHz čerpá podstatně více energie než akciových 1200MHz, nebo dokonce 1400MHz. Zkuste škálování mezi 200 a 1000 MHz na jeden den a cítit ten rozdíl. Q. "Jak si můj přístroj pohotovější. Nezajímá mě moc o bat .... ehm ... já stará o výdrž baterie, ale pouze pokud jde o zamezení nežádoucího spotřebu energie. Zařízení by mělo okamžitě tančit na mých melodií. " A. Scale 500 až 1200 v průběhu obrazovky na 200-500 a během screen-off. Používání výkon vylepšil konzervativní / ondemand (x). Žádné nadměrné spotřeby energie, protože 1400 a 1600 je venku liga. Odpověď bude sladká. A nebojte se, minimálně 500 během obrazovce-na nebude odtékat moc baterie, jako jste vy myslíte!

Opět, na vědomí, že stojan hotplug je zakázáno, pokud pegasusq je aktivní. Po nastavení hodnot, jen se ujistěte, že jste ani nastavit pegasusq špatně, kde pouze jedno jádro je po celou dobu, nebo obě jádra jsou neustále online. Otevřete Tegrak druhé základní aplikace a ujistěte se, že druhé jádro zapne v případě potřeby a nesvítí, když udělal. Body poznámka Zatímco Ladění Pegasusq: - 1) Skutečný interval vzorkování není hodnota vzorkovací_kmitočet protože zatížení je hodnocen po cpu_up_rate počet-vzorky při škálování a cpu_down_rate krát počet vzorků při škálování dolů. Takže nejdou pro velké hodnoty pro vzorkovací_kmitočet. Nejste šetří baterii, ale způsobuje MAS. 2) Vždy se ujistěte, že s nimi přímo související parametry jsou správně nakonfigurovány . Například, vzorkovací_kmitočet 50000 je cpu_up_rate 10, cpu_down_rate 20 druhu zatížení odběr vzorků po 10 * 50000 = 1000000 = 1 sekundu po dobu působnosti a 20 * 50000 = 2 sekundy po dobu zmenšit. 3) Nechť hodnota down_differential vždy mezi 5 a 10 . Aspoň 5 a 15. Rozdíl mezi upthreshold a down_differential je považována za procentuální část aktuální frekvence najít frekvenci redukovat, když CPU byl na max_load_frequency. (To není vaše max_load_frequency scaling_max_frequency. To libovolné frekvence, která je něco menší než) 4) Víme, frekvenční skoky, rovnou do max. příliš často s guvernéry OnDemand bázi. Jeden případ, kdy se to může stát je, když je zjištěno, že je max_load_freq větší než up_threshold procento aktuální frekvenci. (Pokud je aktuální frekvence + (freq_step * policy.max_freq) je menší než frekvence max., bude skákat na tuto frekvenci místo). Takže je lepší jít s velmi nízkou up_threshold . 5) Odběr vzorků se faktorem je počet vzorků, které mají strávit nejvyšší frekvence CPU, než přehodnotit zátěž. Nastavení na 1 mohou být přátelské baterie, ale také způsobuje měřítko se, i když procesor byl velmi zaneprázdněn. Trade-off hodnota je 2. Vysoká sampling_down_factor se nedoporučuje. Nepotřebujeme CPU přicestoval nejvyšší frekvence navždy. 6) Nastavení freq_step = 100% dutin důvodem pro to, že existuje. Nech to být něco mezi 20% a 50% / 60% v závislosti na vaší potřebě. Všimněte si, že smooth_scaling a freq_step dělá totéž. Používejte pouze jeden z nich najednou. 7) hotplug do frekvence (hotplug_freq_1_1) by měla být větší než hotplug dolů frekvenci (hotplug_freq_2_0). Také by hotplug_down frekvence vyšší než vaše změny frekvence minimum. Jinak druhé jádro nemusí vypnout po kopy palců Hotplug runqueues hodnoty ovlivňuje druhé jádro aktivovat / deaktivovat rozhodnutí na základě ne vláken běží nebo ne procesů vedených v běhu fronty. Nechť jejich hodnoty se mezi 200 a 350. Pokud potřebujete druhý zapnout a vypnout rychle pomalu, používejte nízké hodnoty až rq a dolů RQ. 9) freq_for_responsiveness je frekvence, která pomáhá při přepočtu na frequency_next škálovat až do kmitočtu z maximálního kmitočtu. Když se to i) frequency_next zjistí, že je nižší než hodnota freq_for_responsiveness a ii), pokud by redukovali na této frekvenci budou další vzorek nezpůsobí stupnici dolů, pak frequency_next je nastavena na freq_for_responsiveness. (Tím se zabrání redukovali na nízkou frekvenci, kde další vzorek způsobí rozšíření s). Frekvence v dolní polovině vašeho kmitočtové tabulky je rozumná hodnota pro tento parametr. Chcete-li zakázat použití tohoto param, nastavte jej na změny frekvence minimum. 10) up_threshold_at_min_freq je do hranice pro frekvencích pod freq_for_responsiveness. Hodnota tohoto by měla záviset na tom, jak vysoká nebo nízká vaše freq_for_responsiveness je. Potřebujete-li uvolněný škálování do freq_for_responsiveness, použít vyšší hodnoty pro up_threshold_at_min_freq. A zlozvyk-poezie.
Je to pouze z překladače,ale každý pochopí..Jinak napište.. 
Vlákno zde na xda:
http://forum.xda-developers.com/showthread.php?t=1369817