Paano Tahimik na Ginagawang Mas Mabilis at Mas Mahusay ng mga AutoFDO Kernel Optimization ang Android

Home » Sawa » Paano Tahimik na Ginagawang Mas Mabilis at Mas Mahusay ng mga AutoFDO Kernel Optimization ang Android

Nakakatanggap ang Android ng serye ng mga tahimik at mababang antas na pagbabago na naglalayong gawing mas maramdaman ng mga telepono... mas mabilis habang mas pinapahaba pa ang buhay ng bateryaSa halip na mga bagong tampok na magarbo, nakatuon ang Google sa kung paano gumagawa ng mga desisyon ang core ng operating system bawat millisecond sa ilalim ng hood.

Sa sentro ng pagsisikap na ito ay isang pamamaraan na tinatawag na AutoFDO, pinaikling para sa Awtomatikong Pag-optimize na Nakadirekta sa Feedback na inilapat sa Android kernelSa pamamagitan ng muling paghubog kung paano kino-compile ang kernel batay sa totoong datos ng paggamit, sinusubukan ng Google na bawasan ang nasasayang na trabaho sa CPU, bawasan ang background overhead, at bigyan ang mga kasalukuyang device ng katamtaman ngunit kapansin-pansing pagtaas sa kakayahang tumugon.

Ang aktwal na ginagawa ng AutoFDO sa Android kernel

Sa isang normal na pagbuo, kailangang gawin ng isang compiler libu-libong maliliit na desisyon tungkol sa kung paano ayusin at i-tune ang codeHinuhulaan nito kung aling mga sangay ang malamang, kung aling mga tungkulin ang dapat naka-inline, kung paano dapat ilatag ang mga tagubilin sa memorya at iba pa, higit sa lahat ay batay sa mga static na pahiwatig at pangkalahatang heuristics.

Ang isyu ay ang mga hulang ito ay hindi laging naaayon sa kung ano talaga ang nangyayari kapag ginagamit ang iyong telepono. Ang kernel, na maaaring magpaliwanag sa humigit-kumulang 40% ng kabuuang oras ng CPU sa Android, maaaring gumugol ng mga cycle sa mga bihirang gamiting code path habang ang mga madalas gamitin ay hindi na-optimize nang agresibo gaya ng maaari.

Binabago ng AutoFDO ang pamamaraang ito sa pamamagitan ng pagpapakain sa compiler mga profile na binuo mula sa mga totoong pattern ng pagpapatupadSa halip na umasa lamang sa teorya, ang proseso ng pagbuo ay ginagabayan ng kung paano aktwal na kumikilos ang code sa mga device, na nagpapahintulot sa kernel binary na mahubog batay sa pang-araw-araw na workload.

Para sa mga gumagamit, hindi ito lumalabas bilang isang bagong setting o menu. Lumilitaw ito nang bahagya bilang medyo mas mabilis na reaksyon kapag naglulunsad ng mga app o nagre-reboot ng telepono, at dahil mas kaunting oras sa CPU ang nauubos sa mga desisyon sa background na hindi direktang nakikita ng mga user.

Mula sa mga static na hula hanggang sa mga profile ng pagpapatupad sa totoong mundo

Ayon sa kaugalian, ang profile-guided optimization ay umaasa sa mga instrumented binary na nangongolekta ng data sa mga espesyal na pagpapatakbo. Gumagana iyon, ngunit maaari itong maging nakakaabala at maaaring hindi sumasalamin kung paano talaga ginagamit ng mga tao ang kanilang mga telepono araw-arawAng AutoFDO ay gumagamit ng mas magaan na landas batay sa sampling.

Gumagamit ang Google ng sampling profiler upang makuha ang Kasaysayan ng sangay at mga landas ng tagubilin ng CPU habang nagpapatakbo ang Android ng makatotohanang mga workloadIpinapakita ng mga sampol na ito kung aling mga bahagi ng kernel ang "mainit" (madalas gawin) at alin ang "malamig" (bihirang hawakan), nang hindi kinakailangang muling buuin ang lahat gamit ang mabibigat na instrumento.

Para sa partikular na kernel, ang datos ay isinasama sa isang kapaligirang laboratoryo. Nirereplay ng mga inhinyero ang mga representatibong workload na kinabibilangan ng ang 100 pinakasikat na aplikasyon sa Android mula sa compatibility test suite. Ang mix na ito ay dinisenyo upang gayahin ang totoong paggamit: pagbubukas at pagsasara ng mga app, paglipat-lipat sa pagitan ng mga ito, mga pag-sync sa background, at komunikasyon sa pagitan ng mga proseso.

Kapag nakolekta na, ang mga hilaw na bakas ay dumadaan sa isang proseso ng pagsasama-sama at paglilinisAng data mula sa maraming run at device ay pinagsasama, kino-convert sa karaniwang format ng LLVM AutoFDO profile, at sinasala upang ang mga kaugnay na simbolo at function lamang ang matira. Ang mga cold function ay kadalasang inaalis sa profile upang bumalik ang mga ito sa mga kumbensyonal na heuristic ng compiler sa halip na baguhin ang optimization.

Ang napiling profile na ito ang gagabay sa isang bagong pagbuo ng kernel. Gamit ang tumpak na impormasyon kung aling mga path ng code ang pinakamahalaga, mas agresibong maisasama ng compiler ang mga kritikal na routine, maisaayos ang hot code upang maging cache-friendly, at maalis ang pagbibigay-diin sa mga bihirang gamiting branch. Ang resulta ay isang kernel na mas mahusay na naaayon sa mga workload na aktwal na nakikita ng mga Android phone.

Gaano kaya kabilis at kahusay ang magagawa ng Android?

Ang mga naunang numero mula sa mga panloob na pagsubok ng Google ay katamtaman ngunit nasasalat. Dahil inilapat ang AutoFDO sa kernel, ang oras ng pag-boot ng device ay bumubuti nang humigit-kumulang 2.1%Hindi niyan gagawing mabilis ang isang mabagal na telepono, pero mababawasan nito ang kaunting paghihintay sa tuwing magre-restart ka.

Ang mga benepisyo ay bahagyang mas kapansin-pansin kapag binubuksan ang mga app mula sa isang "malamig" na estado — ibig sabihin, kapag wala pa ang mga ito sa memorya. Dito, ang AutoFDO ay naghahatid ng humigit-kumulang 4.3% na pagbawas sa mga oras ng paglulunsad ng malamig, partikular na nakakatulong para sa mas mabibigat na app na umaasa sa mga native na component at mga serbisyo ng kernel.

Sa ilalim ng mga malinaw na sukatang iyon, binanggit din ng Google ang mga pagpapabuti sa mga lugar na hindi gaanong nakikita ngunit mahalaga pa rin: mas maayos na pag-iiskedyul ng background, mas kaunting CPU spikes para sa mga karaniwang gawain sa kernel, at sa pangkalahatan ay mas maayos na paghawak ng mga operasyon sa antas ng system. Ang lahat ng ito ay nakakatulong sa pakiramdam na ang isang device ay mas tumutugon, kahit na mahirap matukoy ang isang malaking pagbabago.

Dahil kayang kumonsumo ng malaking bahagi ng kabuuang kapasidad ng CPU ang kernel, kahit ang mga single-digit na porsyentong nadagdag ay maisasalin sa mga libreng mapagkukunan na maaaring gamitin ng mga app at UI ng systemKasabay nito, ang pagbabawas ng mga hindi kinakailangang trabaho sa CPU ay tiyak na makakatulong sa kahusayan ng kuryente, kaya nakakaramdam ng kaunting ginhawa ang baterya nang walang anumang pagbabago sa hardware.

Maingat na iposisyon ng Google ang mga benepisyong ito bilang unti-unti. Hindi dapat asahan ng mga user ang isang pagbabago sa gabi-gabi, kundi isang patuloy na pagpipino sa kung paano nararamdaman at kumikilos ang Android sa paglipas ng panahon, lalo na kapag maraming ganitong pag-optimize ang magkakasama sa iba't ibang release.

Pagpapanatili ng katatagan habang binabago kung paano binuo ang kernel

Ang isang paulit-ulit na alalahanin sa anumang profile-guided optimization ay kung ito ba ay nanganganib paglabag sa inaasahang pag-uugali o pagpapakilala ng mga banayad na bugSa kaso ng AutoFDO, binibigyang-diin ng Google na binabago ng pamamaraan kung paano inuuna at inilalatag ng compiler ang code, hindi ang lohika mismo ng kernel.

Ang pamamaraan ay inilarawan bilang "konserbatibo bilang default". Nangangahulugan ito na ang mga function na hindi mahusay na kinakatawan sa data ng high-fidelity profile ay iniwan sa mga karaniwang estratehiya sa pag-optimize sa halip na agresibong baguhin ang hugis. Ang mga malamig o bihirang isagawang landas ay kumikilos na parang nasa tradisyonal na pagbuo, na nagbabawas sa posibilidad ng mga regresyon sa mga hindi malinaw na sitwasyon.

Bago tanggapin ang mga profile, sumasailalim ang mga ito sa maraming pagsusuri. Sinusuri ng mga inhinyero ang nilalaman ng profile — mga hot function, bilang ng sample, at kabuuang laki — at inihahambing ito sa mga nakaraang bersyon. Pagkatapos ay binubuo ang isang bagong kernel image, at Ang mga benchmark ay isinasagawa upang matiyak na ang mga natamo sa pagganap ay pare-pareho at ang latency o throughput ay hindi inaasahang lalala sa mga pangunahing workload.

Hindi ito ang unang paggamit ng Google ng AutoFDO. Malawakang ginamit na ang pamamaraang ito para sa mga pangunahing library ng Android, mga bahagi ng ChromeOS, at maging ang panloob na imprastraktura ng serverAng naunang karanasan ay nagsisilbing lambat ng kaligtasan, na nagmumungkahi na ang istilo ng pag-optimize mismo ay hinog na, kahit na ang paglalapat nito sa Android kernel ay medyo bago pa lamang.

Ang resulta ay ang integrasyon ng kernel ng AutoFDO ay idinisenyo upang mapanatili ang katatagan ng paggana habang nakakamit pa rin ang karagdagang kahusayanPara sa mga end user, ang pagbabago ay nilalayong maging hindi nakikita sa mga tuntunin ng pagiging maaasahan, ngunit tahimik na kapaki-pakinabang sa mga tuntunin ng pagganap.

Paano nire-refresh at inilulunsad ang mga profile sa paglipas ng panahon

Ang isang static na profile ay mabilis na mawawalan ng bisa Ang Android, mga app, at mga pattern ng paggamit ay nagbabagoUpang mapanatiling epektibo ang AutoFDO, itinuturing ng Google ang pagbuo ng profile bilang isang patuloy na proseso sa halip na isang minsanang gawain lamang.

Ang mga profile para sa Generic Kernel Image (GKI) ay muling binubuo bago ang bawat bagong paglabas ng LTS kernelAng mga na-update na workload batay sa mga kasalukuyang bersyon ng nangungunang 100 app ay nire-replay, ang data ay muling sinasample, at ang mga profile ay muling binubuo at pinapatunayan. Ang rolling pipeline na ito ay nakakatulong na matiyak na sinusubaybayan ng mga mas bagong kernel build kung paano talaga ginagamit ng mga tao ang Android sa puntong iyon.

Kapansin-pansin, binanggit ng Google na ang Ang mga workload na nabuo sa laboratoryo ay nagpapakita ng humigit-kumulang 85% na pagkakatulad sa mga pattern ng pagpapatupad na nakuha mula sa mga panloob na fleet ng device. Ang antas ng pagsasanib na iyon ay nagmumungkahi na ang na-synthesize na diskarte ay sapat na malapit sa totoong pag-uugali sa mundo upang maging kapaki-pakinabang para sa paggabay sa pag-optimize, habang mas madali pa ring kontrolin at i-update.

Dahil sinusunod ng mga profile na ito ang karaniwang format ng LLVM AutoFDO, direktang nakakonekta ang mga ito sa mga umiiral na kagamitan sa pagsusuri tulad ng llvm-profdataMaaaring siyasatin ng mga pangkat ng inhinyero ang mga hot function, suriin ang mga pattern ng tawag, at beripikahin kung ang pagsisikap sa pag-optimize ay ginugugol kung saan talaga ito mahalaga.

Sa maraming pag-ulit, ang paulit-ulit na siklo ng pag-profile at muling pagtatayo na ito ay ginagawang isang mekanismo ng patuloy na pag-tune para sa kernel, sa halip na isang tweak lang na naka-lock sa iisang bersyon ng Android.

AutoFDO sa buong Android stack at mga tool

Ang paglipat sa AutoFDO sa kernel ay nakabatay sa gawaing nangyayari na sa ibang lugar sa Android stack sa loob ng ilang panahon. Ang suporta sa AutoFDO ay inilalagay sa sistema ng pagbuo ng Android na ginagamit ng AOSP, lalo na para sa mga native module na umaasa sa mga blueprint-style na build definition.

Para sa maraming performance-sensitive library at binary sa loob ng AOSP, ang mga profile ay nakolekta na mula sa mga totoong telepono at tablet. Ang mga ito ang mga handa nang profile ng AutoFDO ay makikita sa tabi ng pinagmulan at maaaring paganahin sa pamamagitan lamang ng pag-toggle sa mga kaukulang build flag, para ang mga gumagawa ng device na sumusubaybay sa AOSP ay malapit na magmamana ng mga optimization nang may kaunting dagdag na trabaho.

Ang profiling framework ng Android ay maaaring mangalap ng data sa maraming arkitektura ng CPU, kabilang ang x86, x86_64, ARM at ARM64Hangga't ang workload ay representatibo, ang isang profile na nilikha sa isang arkitektura ay maaaring iakma sa isa pa, na nagpapadali sa pag-deploy sa iba't ibang lineup ng device.

Ang mga developer na nangangailangan ng mas pinasadyang mga pag-optimize — halimbawa, kapag nagdaragdag ng sarili nilang mga katutubong bahagi o nagbabago ng mga umiiral na — ay hinihikayat na mangolekta ng mga profile nang direkta mula sa mga device sa pag-develop o pagsubokAng mga kagamitang gaya ng simpleperf at mga kaugnay na kagamitan ay nakakatulong sa pagkuha ng mga kinakailangang sample nang hindi lubhang nakakaabala sa normal na operasyon.

Sa madaling salita, ang AutoFDO ay hindi lamang isang kernel trick. Ito ay akma sa isang mas malawak na estratehiya kung saan Ang mga pinakamahalagang piraso ng Android ay patuloy na kino-compile nang may gabay mula sa totoong datos ng paggamit, sa halip na umasa lamang sa mga istatikong pagpapalagay tungkol sa pagganap.

Saan at kailan darating ang mga pagpapahusay na ito sa kernel

Ipapakilala ng Google ang mga AutoFDO-driven na kernel build muna sa... mga sangay ng pangmatagalang suporta (LTS) ng Android kernel, partikular na ang android16-6.12 at android15-6.6. Ang mga sangay na ito ay nagsisilbing baseline para sa maraming tagagawa, na siyang nagpapatong-patong ng sarili nilang mga pagbabago at pagsasaayos na partikular sa device.

Nagbalangkas din ang kompanya ng mga plano na palawigin ang paggamit ng AutoFDO sa mga bersyon ng GKI sa hinaharap tulad ng android17-6.18Habang dumarating ang mga bagong device kasama ng mga kernel na ito — at habang nakakatanggap ang mga kasalukuyang telepono ng mga update na humihila sa mga mas bagong base ng LTS — mas maraming user ang dapat magsimulang makinabang mula sa pinong pag-uugali.

Sa hinaharap, sinusuri ng Google ang mga paraan upang palawakin ang saklaw ng AutoFDO na lampas sa pangunahing vmlinux binaryKasama rito ang pagdadala ng mga profile-guided optimization sa mga GKI module at, kalaunan, mga vendor module na ginawa gamit ang Driver Development Kit. Papayagan nito ang mga hardware partner na ilapat ang parehong mga diskarte sa pag-profile sa kanilang sariling mga driver, na magpapalaganap ng mga benepisyo nang mas malalim sa ecosystem.

Ang pangmatagalang pananaw ay ang mga AutoFDO-powered build ay makakaapekto sa lumalaking bahagi ng kernel at mga module nito, mula sa pangunahing code ng pag-iiskedyul hanggang sa mga bahaging partikular sa deviceHabang lumalaki ang bilang na iyon, ang pinagsama-samang epekto sa pagtugon at kahusayan ay maaaring maging mas malinaw, kahit na ang bawat indibidwal na pagbabago ay banayad lamang.

Ang lahat ng ito ay nagreresulta sa isang tahimik ngunit makabuluhang pagbabago sa kung paano inaayos ang Android sa pinakamababang antas. Sa pamamagitan ng pagpapahintulot sa mga totoong pattern ng pagpapatupad na gumabay sa compiler, nilalayon ng Google ang mga teleponong mas mabilis ang pakiramdam, mas kaunting pag-aaksaya ng mga cycle ng CPU at gumagawa ng... bahagyang mas mahusay na paggamit ng bawat milliamp-hour ng baterya — lahat nang hindi na kailangang magpalit ng device o magsaliksik sa mga setting ang mga user.