- cpuidle memisahkan dasar dan mekanisme dengan menggunakan gabenor dan pemacu untuk mengurus keadaan tidur CPU.
- Pemilihan keadaan adalah berdasarkan kediaman sasaran, latensi output, sejarah ketidakaktifan dan pemasa akan datang.
- PM QoS dan keadaan penjadual tik yang mana keadaan dalam boleh digunakan tanpa melanggar keperluan latensi.
- Dalam ARM dan SoC moden yang lain, cpuidle disepadukan dengan firmware melalui PSCI, yang menjadi kunci kepada penggunaan kuasa sebenar dan hayat bateri.
Jika anda menggunakan Linux pada komputer riba, desktop atau papan induk ARM dan anda bimbang tentang bateri, haba atau mengapa CPU anda tidak tidur "sebagaimana sepatutnya", fahami bagaimana subsistem berfungsi cpuidle Ia penting. Di sebalik sesuatu yang semudah "CPU sedang melahu" terletak mekanisme yang agak canggih yang menentukan keadaan rehat yang perlu digunakan, berapa lama untuk tidur, dan berapa lama masa yang diperlukan untuk bangun.
Tambahan pula, jika anda datang dari projek seperti Asahi Linux pada Mac dengan M1/M2Adalah perkara biasa untuk keliru: kita bercakap tentang pemandu cpuidle...daripada keadaan rehat yang tidak matang atau langsung tiada, dan inilah yang menghalang sistem daripada digunakan sebagai pemacu harian. Dalam artikel ini, kami akan menguraikannya dengan tenang... Apakah sebenarnya cpuidle, bagaimana ia berfungsi secara dalaman, apakah peranan yang dimainkan oleh gabenor dan pemacu, bagaimana ia dikonfigurasikan, pilihan kernel apa yang mempengaruhinya, dan bagaimana ia disepadukan ke dalam platform ARM moden? seperti yang menggunakan PSCI atau TF-A.
Apakah subsistem cpuidle dan mengapa ia wujud?
Beberapa dekad yang lalu, "rehat" kernel adalah gelung kosongApabila tiada apa-apa untuk dilaksanakan, gelung terbiar akan dijalankan, yang pada asasnya mewujudkan gelung tak terhingga yang menunggu gangguan seterusnya. Hanya dengan tidak melaksanakan kod yang kompleks, sedikit tenaga telah dijimatkan: cache, FPU, dsb., tidak digunakan dengan banyak.
Dengan evolusi perkakasan, pemproses mula menawarkan pelbagai keadaan terbiar (keadaan-C)setiap satu dengan tahap penjimatan dan penalti yang berbeza: memasuki keadaan dalam boleh menjimatkan banyak tenaga, tetapi Ia memerlukan lebih banyak masa dan tenaga untuk masuk dan keluar Daripadanya. Jika anda masuk ke dalam keadaan yang terlalu dalam dan terbangun terlalu cepat, anda telah kalah.
Di sini dimainkan cpuidle, subsistem kernel yang dikhaskan untuk mengurus masa terbiar CPUMatlamatnya adalah untuk menentukan, pada setiap keadaan apabila CPU kehabisan tugas (hanya tugas terbiar yang tinggal), apakah keadaan tidur terbaik yang boleh digunakannya untuk menjimatkan tenaga tanpa melanggar latensi tindak balas.
Secara konseptual, cpuidle memisahkan dua bahagian: di satu sisi mekanisme (pemandu), yang tahu cara bercakap dengan perkakasan dan menyenaraikan keadaan terbiar; dan sebaliknya, politik (gabenor)yang menentukan keadaan tertentu yang akan digunakan pada bila-bila masa, berdasarkan sejarah ketidakaktifan, pemasa akan datang dan sekatan latensi.
Semua ini berlaku dalam gelung terbiar.Apabila penjadual melihat bahawa CPU tidak mempunyai lagi tugas yang boleh dijalankan, ia akan melaksanakan tugas "terbiar" khas, yang kodnya mula-mula memanggil gabenor untuk memilih keadaan dan kemudian pemacu untuk memasukkannya.

CPU logik, tugas terbiar dan apa maksudnya terbiar
Subsistem bagi cpuidle sentiasa berfungsi dari segi CPU logikIaitu, entiti yang dilihat oleh penjadual: ia boleh menjadi teras fizikal, thread perkakasan (hyper-thread) atau kombinasi, bergantung pada seni bina dan pelaksanaannya.
Dari sudut pandangan kernel, CPU logik adalah "terbiar" apabila Tiada tugas boleh laku yang berkaitan dengannya kecuali tugas terbiarPenjadual mengurus proses dan thread sebagai "tugas", dan ini boleh berada dalam keadaan yang berbeza; apabila tugas boleh dijalankan, ia akan ditugaskan kepada CPU. Jika CPU hanya dibiarkan dengan tugas boleh dijalankan yang terbiar, kernel akan menganggapnya tidak aktif.
Tugas terbiar melaksanakan panggilan gelung terbiarGelung ini, dalam setiap lelaran, memanggil gabenor cpuidle untuk memutuskan keadaan tidur dan kemudian memanggil pemacu cpuidle untuk meminta perkakasan memasuki keadaan tersebut. Jika tiada keadaan tidur yang tersedia, tidak cukup masa sebelum peristiwa seterusnya, atau kekangan latensi terlalu ketat, CPU sama ada melaksanakan gelung yang agak tidak berguna atau menggunakan arahan menunggu yang paling asas (seperti `wait`). hlt atau serupa).
Dalam pemproses berbilang teras atau yang mempunyai SMT, Keputusan terbiar mempengaruhi hierarki unitPermintaan tidur peringkat thread boleh menyebabkan terasnya memasuki keadaan yang lebih dalam jika semua thread terbiar, dan seterusnya, sekumpulan teras boleh tidur jika semua ahlinya membenarkannya. CPU perlu memodelkannya melalui... keadaan yang mewakili gabungan tahap hierarki, dengan latensi dan kediaman yang mencerminkan keadaan sedalam mungkin.
Apabila keadaan yang diwakili oleh objek jenis diminta struct cpuidle_statePemacu boleh membenarkan perkakasan untuk masuk sedalam yang dibenarkan oleh reka bentuk. Oleh itu, Latensi keluar dan residensi sasaran mesti diselaraskan dengan kombinasi keadaan terburuk sebenar dalam hierarki (teras, kluster, pakej, dll.).
Gabenor CPUIDLE: bagaimana mereka memutuskan negeri mana yang hendak digunakan
The gabenor cpuidle ialah modul dasar Proses-proses ini berjalan setiap kali CPU memasuki gelung melahu. Tujuannya adalah untuk menggunakan maklumat yang ada bagi memilih keadaan melahu yang menjimatkan tenaga paling banyak tanpa melanggar kekangan latensi.
Setiap gabenor ditakrifkan sebagai struktur struct cpuidle_governordengan panggilan balik enable, disable, select y reflect, medan keutamaan (rating) dan nama. Setelah berdaftar dengan cpuidle_register_governor(), boleh dipilih secara automatik oleh kernel (berdasarkan penarafan, konfigurasi lalai atau parameter cpuidle.governor=) atau secara manual daripada ruang pengguna melalui sysfs.
Apabila gabenor diaktifkan untuk CPU melalui panggilan baliknya enable(), menerima struct cpuidle_device yang mewakili CPU itu dan a struct cpuidle_driver dengan senarai negeri yang tersedia (struct cpuidle_stateYa enable() Ia gagal; kernel menggunakan kod terbiar lalai. khusus seni bina dan bukannya cpuidle untuk CPU tersebut.
Hati gabenor adalah panggilan balik select()yang menerima peranti cpuidle, pemacu dan penunjuk kepada boolean stop_tickPanggilan balik ini mengembalikan indeks keadaan yang dipilih dalam tatasusunan keadaan, atau kod ralat negatif. Selain itu, ia boleh memutuskan sama ada untuk menghentikan penjadual tick pada CPU tersebut (mengosongkan boolean atau tidak).
Apabila CPU terjaga, gabenor menerima panggilan untuk reflect() dengan maklumat tentang keadaan yang dipilih dan berapa lama masa henti sebenarnya berlangsung. Ini membolehkan anda memperhalusi ramalan mereka berdasarkan data sejarahIa juga dikehendaki untuk menghormati sekatan latensi PM QoS: oleh cpuidle_governor_latency_req() memperoleh had latensi berkesan dan tidak boleh memilih keadaan yang exit_latency melebihi nilai tersebut.
Gabenor utama: tangga, haltpoll, menu dan teo
Dalam Linux terdapat beberapa gabenor cpuidle, setiap satunya dengan strategi dan khalayak sasarannya sendiri. Empat yang utama ialah tangga, haltpoll, menu dan teo, dan yang mana satu dipilih secara lalai bergantung sebahagian besarnya pada sama ada kernel tidak berdetik (mampu menghentikan penjadual tik) atau tidak.
tangga Ia direka bentuk untuk sistem dengan tanda berkala aktif. Ia menggunakan pendekatan mudah yang hampir secara eksklusif berdasarkan sejarah tempoh terbiarIa naik turun "tangga" keadaan, mempromosikan dirinya ke keadaan yang lebih dalam apabila ia memerhatikan ketidakaktifan yang cukup lama dan berundur apabila kebangkitan datang terlalu cepat.
berhenti mengundi Ia merupakan gabenor khusus untuk mesin maya. Daripada memasuki keadaan terbiar perkakasan yang mendalam, Ia sangat bergantung pada tinjauan pendapat. (gelung tunggu) untuk mengurangkan kependaman ketara dalam persekitaran di mana keadaan rehat fizikal mungkin tidak banyak menyumbang atau tidak dimodelkan dengan baik oleh hipervisor.
menu y teo Ini adalah gabenor yang digunakan dalam sistem tanpa gesekan (CONFIG_NO_HZ_IDLE o CONFIG_NO_HZ_FULLKedua-duanya menggabungkan Sejarah tempoh terbiar dengan maklumat tentang pemasa seterusnyadan mereka cuba menjimatkan tenaga tanpa menghabiskan lebih banyak masa mengira keputusan daripada yang dijimatkan dengan membuatnya.
Gabenor menu adalah mengenai secara eksplisit meramalkan berapa lama CPU akan terbiarSebahagian daripada masa sehingga pemasa seterusnya sebagai had atas dan menggunakan faktor pembetulan berdasarkan sejarah ketidakaktifan terkini untuk menganggarkan tempoh "biasa". Dengan nilai anggaran itu, rujuk jadual keadaan untuk memilih keadaan terdalam yang sesuai dengan kediaman sasarannya.
Gabenor teo (Berorientasikan Pemasa-Acara) Ia menangani masalah dengan cara yang berbeza: daripada cuba meramalkan masa henti yang tepat, mengukur data sejarah dalam "tong" atau selang yang berkaitan dengan setiap keadaanSetiap bin sepadan dengan julat masa di mana keadaan itu biasanya optimum. TEO mengekalkan metrik bagi hits (kebangkitan di mana tempoh sebenar sepadan dengan kediaman sasaran) dan memintas (kebangkitan akibat peristiwa yang tidak dijangka yang mengganggu ramalan) dan, dengan itu, secara langsung membuat kesimpulan Negeri tertentu yang manakah paling mungkin betul?.
Hanya apabila ia memberi manfaat kepadanya, TEO menyemak masa sehingga pemasa seterusnya untuk mengelakkan daripada memasuki keadaan yang sasaran residensi adalah lebih besar daripada tempoh sebenar yang tersediaTambahan pula, reka bentuknya cuba mengurangkan kos keputusan: dalam senario dengan masa terbiar yang sangat singkat, adalah lebih baik untuk memilih keadaan cetek dengan cepat daripada menghabiskan lebih banyak tenaga berfikir daripada yang dijimatkan.
pemacu cpuidle: jambatan antara kernel dan perkakasan
Ketika para gabenor sibuk dengan politik, Pemacu cpuidle melaksanakan mekanisme input/output keadaan sebenarSetiap pemacu mewakili senarai keadaan yang disokong oleh pemproses (atau oleh satu set CPU) melalui a struct cpuidle_driver yang mengandungi susunan struct cpuidle_state.
Setiap struct cpuidle_state mentakrifkan, antara bidang lain, kediaman sasaran (target_residency dalam mikrosaat), latensi output maksimum (exit_latency), bendera seperti CPUIDLE_FLAG_POLLING dan, yang sangat penting, panggilan balik enter() yang merupakan bahagian yang melakukan bahagian yang halus: melaksanakan arahan atau panggilan yang diperlukan untuk meminta perkakasan memasuki keadaan tersebut.
Entri dalam tatasusunan keadaan mesti disusun mengikut target_residency menaikOleh itu, indeks 0 biasanya sepadan dengan keadaan paling cetek (dan paling murah untuk digunakan), dan indeks berikutnya dikaitkan dengan keadaan yang semakin dalam. Gabenor menganggap susunan ini untuk pengiraan mereka.
Panggilan balik enter() menerima peranti, pemacu dan indeks keadaan cpuidle untuk digunakanUntuk kes jenis penggantungan gantung-ke-terbiar, ia digunakan sebaliknya enter_s2idle()yang mesti mematuhi sekatan yang lebih ketat: ia tidak boleh mengaktifkan semula gangguan atau memanipulasi peranti pemasaan semasa pelaksanaannya, sesuatu yang enter() Ya, ia boleh dilakukan bergantung pada platform.
Selain menerangkan keadaan, pemacu mesti merekodkan CPU mana yang berada di bawah kawalannya: setiap CPU mempunyai struct cpuidle_device, yang biasanya berdaftar dengan cpuidle_register_device()Jika tiada keadaan "bergandingan" (yang memerlukan koordinasi antara berbilang CPU), daftar dilakukan dengan cpuidle_register_driver()Jika ada, ia digunakan cpuidle_register()yang juga bertanggungjawab untuk mendaftarkan peranti.
Platform moden cuba mengurangkan bilangan pemacu tertentu: contohnya, ARM biasanya menggunakan pemacu generik yang mewakilkan kepada antara muka standard seperti PSCI (Antara Muka Penyelarasan Keadaan Kuasa)Dan dalam RISC-V sesuatu yang serupa melalui SBI (Supervisor Binary Interface). Walaupun begitu, pemacu seperti ini masih wujud dalam x86. intel_idle (dengan jadual keadaan "dibakar" ke dalam pemacu) dan acpi_idle (yang memperoleh keadaan daripada jadual ACPI).
Keadaan tidak aktif: parameter, sistem dan metrik
Setiap keadaan rehat yang didedahkan oleh CPU kepada gabenor dicirikan oleh beberapa parameter utama. Dua yang paling penting ialah kediaman sasaran (target_residency) dan kependaman keluaran (exit_latency), kedua-duanya dalam mikrosaat.
La target_residency Dalam praktiknya, ia menandakan kedalaman negeri yang bertenaga.Ini adalah masa minimum perkakasan mesti kekal dalam keadaan tersebut (termasuk kos kemasukan) untuk menjadi berbaloi berbanding keadaan yang lebih cetek. Jika sistem terjaga sebelum mencapai masa kediaman tersebut, ia mungkin telah membelanjakan lebih banyak tenaga memasuki keadaan tersebut daripada yang telah dijimatkan.
La exit_latency Ia menetapkan masa terburuk yang berlaku antara CPU meminta untuk keluar dari keadaan tersebut dan benar-benar melaksanakan arahan berguna seterusnya.Ia juga termasuk kes di mana peristiwa bangun tiba ketika perkakasan masih memasuki keadaan, kerana secara amnya peralihan dalaman mesti diselesaikan sebelum ia boleh keluar dengan cara yang teratur.
Di samping itu, terdapat bendera yang menggambarkan sifat-sifat tambahan negeri: contohnya, CPUIDLE_FLAG_POLLING menunjukkan bahawa "keadaan" ini sebenarnya bukanlah rehat perkakasantetapi gelung tinjauan pendapat yang digunakan sebagai mekanisme khas untuk mengelakkan daripada menyentuh keadaan sebenar apabila mudah (contohnya, dalam persekitaran maya atau penyahpepijatan tertentu).
Kernel mendedahkan maklumat yang sangat terperinci tentang keadaan terbiar CPU melalui sysfs, dalam /sys/devices/system/cpu/cpu<N>/cpuidle/Terdapat direktori di sana. state0, state1dsb., satu untuk setiap input tatasusunan pemacu, dan dalam setiap satu kita boleh temui atribut seperti name, desc, latency, residency, usage, time, power, above, below y rejected.
Sifat-sifat ini membolehkan kita melihat berapa kali setiap negeri telah diminta (usage), berapa banyak jumlah masa yang telah diluangkan untuknya mengikut kernel (time)dan sejauh mana pilihan itu baik atau buruk (above y below Mereka mengira kes di mana tempoh terbiar sebenar jelas terlalu pendek atau terlalu panjang berbanding dengan kediaman sasaran). rejected Ia mengira masa permintaan ditolak, biasanya kerana gangguan berlaku tepat pada masa peralihan.
Terdapat satu sifat yang sangat berguna, disableIni membolehkan anda mengaktifkan atau menyahaktifkan keadaan khusus tersebut untuk CPU daripada ruang pengguna (dengan menaip 1 atau 0). Jika dinyahdayakan untuk CPU, gabenor tidak akan mempertimbangkannya semasa memilih; jika anda ingin mengalih keluar sepenuhnya keadaan sistem, anda mesti lumpuhkannya pada semua CPU. Atribut default_status menunjukkan sama ada keadaan diaktifkan atau tidak secara lalai.
Penjadual tik dan sistem tanpa tik
Yang terkenal tanda penjadual Ia merupakan pemasa berkala (100, 250 atau 1000 Hz, bergantung pada CONFIG_HZ) yang digunakan oleh kernel, antara lain, untuk memperuntukkan masa CPU antara tugasan, kaunter kemas kini dan mencetuskan tamat tempoh pemasa.
Dari sudut pandangan cpuidle, tanda berkala adalah gangguan: semasa ia aktif pada CPU terbiar, CPU itu boleh tidur lebih lama daripada tempoh tickTambahan pula, setiap kebangkitan setiap tik melibatkan masuk dan keluar dari keadaan rehat, membazirkan tenaga jika seseorang dipilih terlalu dalam.
Mengikut definisi, pada CPU yang hanya menjalankan gelung terbiar Tidak semestinya perlu menyimpan tanda semak itu Untuk perkongsian CPU: tiada lagi tugasan yang boleh dijalankan. Oleh itu, Linux boleh dikonfigurasikan sebagai tanpa geli dalam keadaan terbiar (CONFIG_NO_HZ_IDLE) atau dalam mod "penuh" apabila hanya terdapat satu tugas terpencil pada CPU (CONFIG_NO_HZ_FULL), menyahaktifkan tanda semak di bawah syarat-syarat tersebut.
Keputusan untuk menghentikan tanda semak atau tidak dibuat oleh gabenor menggunakan parameter stop_tick daripada panggilan balik anda select()Jika anda menjangkakan gangguan (pemasa atau sebaliknya) dalam jangka pendek (dalam tempoh yang akan menjadi tempoh tick), Tiada gunanya menyahaktifkan tanda semak itu.Masa akan dihabiskan untuk memprogramnya semula, dan tempoh downtime mungkin akan dihabiskan dalam keadaan yang terlalu dangkal jika ternyata tiada siapa yang membangunkan CPU.
Sebaliknya, jika gabenor percaya CPU akan terbiar lebih lama daripada tanda semak dan keadaan yang dipilih adalah dalam, Sebaiknya hentikan perkara ini supaya tidak merosakkan simpananBeberapa konfigurasi kernel (parameter nohz=off atau lumpuhkan CONFIG_NO_HZ_IDLE) paksa tanda semak untuk tidak pernah berhenti, yang mana dalam kes ini sistem tidak tanpa tanda semak dan gabenor lalai biasanya tangga dan bukannya menu atau teo.
PM QoS: Cara mengawal latensi rehat
Rangka kerja Kualiti Perkhidmatan Pengurusan Kuasa (PM QoS) Ia membolehkan pemacu dan proses ruang pengguna untuk menyatakan sekatan ke atas tingkah laku tenaga sistem, terutamanya pada latensi input/output bagi keadaan tidur.
Untuk cpuidle terdapat dua jenis sekatan utama: had latensi CPU global dan sekatan Latensi sambung semula CPU (pm_qos_resume_latency_us)Secara dalaman, permintaan disimpan dalam senarai keutamaan dan nilai berkesan, dalam kes ini, adalah minimum bagi semua yang diminta.
Dari ruang pengguna, had global boleh diubah suai dengan membuka /dev/cpu_dma_latency dan menulis dalam deskriptor itu integer 32-bit dengan kependaman maksimum yang boleh diterima dalam mikrosaat. Setiap deskriptor terbuka mewakili permintaan bebasApabila ia ditutup, permintaan itu hilang dan sistem mengira semula nilai berkesan dengan yang lain.
Untuk sekatan CPU, terdapat fail power/pm_qos_resume_latency_us en /sys/devices/system/cpu/cpu<N>/Menulis nilai di sana akan mengubah permintaan yang berkaitan dengan CPU khusus tersebut (dikongsi oleh seluruh ruang pengguna, jadi adalah dinasihatkan untuk menilai siapa yang mengaksesnya). Pemacu kernel juga boleh mendaftarkan permintaan mereka sendiri melalui API PM QoS dalaman.
Gabenor cpuidle mesti, dalam setiap pemilihan negeri, hormati minimum antara latensi global berkesan dan CPU yang terjejasMereka tidak boleh memilih negeri yang exit_latency melebihi had tersebut. Ini amat penting dalam kes perisian dengan keperluan masa nyata yang lembut, seperti audio atau video, yang mana penyambungan semula yang terlalu perlahan daripada keadaan dalam boleh menyebabkan underrun atau gangguan.
Terdapat juga QoS lain, cpu_wakeup_latencyyang mempengaruhi pilihan keadaan terbiar semasa mod gantung-ke-terbiar (s2idle) sistem. Pengendaliannya, dari ruang pengguna, adalah serupa dengan cpu_dma_latency dan ia juga dinyatakan dalam mikrosaat.
kawalan cpuidle melalui parameter kernel
Linux membolehkan anda melaraskan tingkah laku pemacu cpuidle dan idle daripada baris arahan kernel. Parameter yang paling drastik ialah cpuidle.off=1Ini melumpuhkan sepenuhnya subsistem: gelung terbiar masih wujud, tetapi gabenor dan pemacu cpuidle tidak lagi digunakan, dan sebaliknya mekanisme "lalai" seni bina digunakan, yang biasanya lebih mudah dan kurang cekap.
Parameter cpuidle.governor=<nombre> Ia membolehkan anda memaksa gabenor untuk menggunakan, contohnya cpuidle.governor=menu o cpuidle.governor=teo, bukannya yang akan dipilih secara automatik. Ini berguna untuk bereksperimen dengan penggunaan kuasa dan kependaman pada perkakasan yang sama tanpa mengkompil semula kernel.
Dalam seni bina x86, terdapat juga parameter khusus yang berkaitan dengan cara mod melahu dimasukkan. Contohnya, idle=halt y idle=poll Mereka melumpuhkan pemacu. intel_idle y acpi_idlememaksa sistem menggunakan arahan hlt atau gelung tinjauan tulen untuk rehat, masing-masing. Ini memudahkan tingkah laku tetapi dengan mengorbankan kecekapan: idle=pollKhususnya, ia boleh menghalang penggunaan keadaan-P yang memerlukan CPU untuk melahu, memburukkan lagi penggunaan kuasa dan prestasi benang tunggal.
Parameter idle=nomwait melarang penggunaan arahan MWAIT untuk memasuki keadaan tidur, memaksa acpi_idle untuk menggunakan hlt dan menyahaktifkan intel_idle Dalam pemproses Intel, hanya ACPI yang menguruskan keadaan. Tambahan pula, pemacu intel_idle y processor (yang terakhir termasuk) acpi_idle) menerima pilihan seperti intel_idle.max_cstate=<n> y processor.max_cstate=<n> untuk menyempitkan senarai keadaan yang tersedia dalam pemacu dan membuang semua keadaan yang lebih dalam daripada indeks yang ditentukan.
Dalam kes intel_idle.max_cstate=0Ini bersamaan dengan melumpuhkan pemacu Intel secara khusus dan membenarkan pemacu ACPI mengambil alih, sementara processor.max_cstate=0 ditafsirkan sebagai processor.max_cstate=1Ini adalah pilihan yang berguna untuk untuk mendiagnosis masalah kestabilan, latensi yang tidak normal atau penggunaan kuasa yang luar biasa, dengan kos mengehadkan keupayaan sistem untuk menjimatkan tenaga semasa melahu.
Integrasi dengan platform ARM, PSCI dan siap sedia
Pada platform ARM moden (seperti banyak SoC daripada TI, NXP, Rockchip, Apple melalui Asahi, dll.), cpuidle biasanya disepadukan dengan firmware peringkat rendah melalui PSCIdan biasa berlaku dalam peranti IoT dengan pengurusan perkhidmatan IoT pintarPemacu ARM generik untuk cpuidle ialah pemacu yang berkomunikasi dengan PSCI menggunakan panggilan SMC (Secure Monitor Call) dan mewakilkan peralihan keadaan sebenar kepada TF-A (Arm Trusted Firmware) atau firmware lain yang setara.
Satu contoh tipikal ialah SoC seperti AM62x, di mana keadaan siap sedia dilaksanakan sebagai keadaan CPUIdle berdasarkan arahan WFI (Wait For Interrupt)Dari sudut pandangan pengguna, sistem masuk dan keluar dari keadaan siap sedia secara berterusan, berkali-kali sesaat, tanpa memerlukan interaksi: ini ialah keadaan siap sedia "cahaya" lalai, dengan masa masuk dan keluar dalam susunan mikrosaat.
Laluan pelaksanaan apabila sistem memasuki mod melahu pada platform ini adalah lebih kurang: Gelung terbiar mengesan bahawa tiada tugasan, dan gabenor memilih keadaan yang sepadan (contohnya, satu yang dipanggil stby)Pemacu ARM generik memanggil PSCI melalui lapisan drivers/firmware/psci.c, dan di sisi TF-A, pengendali dipanggil cpu_standby() ditakrifkan dalam struktur plat_psci_opsDi situlah ia benar-benar berlaku. WFI.
Apabila gangguan tiba, pemproses secara automatik keluar dari WFI, TF-A mengembalikan kawalan kepada kernel, dan CPU meneruskan pelaksanaan dari tempat ia berhenti. Semua ini diatur secara telus, dengan syarat pokok peranti menerangkan keadaan terbiar dengan tepat (nod idle-states, rujukan daripada setiap CPU dan sifat seperti entry-latency-us, exit-latency-us y min-residency-us).
Siaga CPU ringan ini tidak boleh dikelirukan dengan mod tidur nyenyak seluruh sistemdi mana keseluruhan blok kuasa dimatikan, peranti persisian dikonfigurasikan semula dan masa input/output berada dalam julat milisaat atau saat. Keadaan CPUidle lebih berorientasikan ke arah uruskan rehat jangka pendek secara mikroMod tidur nyenyak, sebaliknya, memerlukan penyelarasan tambahan PM masa jalan, penggantungan/penyambungan semula pemacu dan selalunya sokongan khusus dalam pemuat but atau firmware.
Sebaik sahaja kernel telah mendayakan cpuidle dan pemacu yang berfungsi (contohnya, pemacu generik ARM + PSCI yang diterangkan dengan betul dalam DT), Pengguna tidak perlu "mengaktifkan" apa-apa.Gabenor mengendalikannya secara automatik. Walau bagaimanapun, anda boleh merujuk statistik dalam /sys, tukar gabenor semasa dalam /sys/devices/system/cpu/cpuidle/current_governor atau melaraskan sifat-sifat keadaan yang didedahkan oleh pemandu.
Pada platform yang agak baharu atau dalam proses pemindahan seperti Asahi Linux, banyak masalah bateri, haba atau kekurangan "tidur" berfungsi dikaitkan dengan bahawa integrasi lengkap cpuidle dengan perkakasan belum wujud (atau belum matang)Masalahnya ialah: keadaan yang diterangkan dengan baik tiada dalam alat pembangunan, tiada firmware yang melaksanakan keadaan yang munasabah, atau pemacu masih dalam pembangunan. Sehingga keadaan itu stabil, adalah perkara biasa untuk hanya menggunakan keadaan Wi-Fi yang sangat asas atau, lebih buruk lagi, untuk melumpuhkan CPU IDLE sama sekali dan kekal dalam keadaan tidur yang agak asas.
Akhirnya, memahami bagaimana cpuidle memodelkan CPU logik, bagaimana gabenor membuat keputusan dengan Kediaman sasaran, latensi dan PM QoSMemahami cara pemacu bersambung dengan ACPI, PSCI atau firmware proprietari, dan bagaimana penjadual tick menetapkan tempoh melahu, membolehkan anda melihat dari sudut pandangan baharu mengapa komputer riba anda tahan lebih lama (atau lebih pendek) pada hayat bateri, mengapa kernel "tanpa tick" biasanya menggunakan kurang kuasa, dan mengapa dalam port tertentu kepada perkakasan eksotik Tidur dan melahu, secara literalnya, adalah perbezaan antara sistem ujian dan pemandu harian yang boleh digunakan..
Penulis yang bersemangat tentang dunia bait dan teknologi secara umum. Saya suka berkongsi pengetahuan saya melalui penulisan, dan itulah yang akan saya lakukan dalam blog ini, menunjukkan kepada anda semua perkara yang paling menarik tentang alat, perisian, perkakasan, trend teknologi dan banyak lagi. Matlamat saya adalah untuk membantu anda mengemudi dunia digital dengan cara yang mudah dan menghiburkan.