2

Whenever a cpu is idle, it executes the cpu_idle_loop. I am curios to know about the advantages of this loop when compared to halt [x86] or wfe/wfi instruction in arm ?

Is there any power consumption advantages ?

Dexter
  • 1,299
  • 3
  • 20
  • 38
  • Possibly related [Linux and wake idle CPU with new task](http://stackoverflow.com/questions/15058781/how-does-linux-kernel-wake-idle-processor-up-when-new-task-created) and [Exynos power control](http://stackoverflow.com/questions/16003215/can-someone-explain-the-power-control-register-in-exynos-arm); at least additional information on the topic. – artless noise Jun 02 '15 at 17:18

2 Answers2

1

wfe / wfi are just instructions, which can make core into a low power mode, but that can't affect the clocks into the core etc. If a core is getting power at this time leakage will be still there, which matters in battery powered devices a lot.

In a function like cpu_idle_loop, you can control more power into the core since you know what affects what and can also flush caches and reduce power used by them etc. You can also totally cut power to the core removing or reducing leakage to the minimum possible. In a multicore system, last core going to idle can power down platform / board into a even more power preserving state.

wfe / wfi is good for avoiding core to waste power while waiting which is also good for heat not dispatched. Must have to implement mutexes / semaphores but a SOC is consisting of many elements these days and kernel can inform the hardware when most of it is not needed rather than just idling efficiently a single core.

auselen
  • 27,577
  • 7
  • 73
  • 114
  • Maybe worth noting that in the absence of a cpuidle driver with extra system-specific cleverness, the default implementation ends up calling `cpu_do_idle`, which (on processors supporting it, e.g. `cpu_v7_do_idle`) _is_ basically just a `wfi`. – Notlikethat Jun 02 '15 at 12:49
1

On top of the power advantage pointed out by other users, I would like to point out another less noticed advantage of using WFI's. Consider the case when our kernel is being run as a virtual machine on top of another Host operating system. The Host OS would have marked WFI instructions as trap. When a WFI instruction is executed by a Guest OS, control is immediately transferred (Trapped) to Host OS. This allows the host to efficiently schedule other OS's in its ready queue. If the Guest OS were using a busy IDLE loop (instead of WFI), time slice allotted to the Guest OS has to expire before the Host OS can schedule in another Guest OS, this leads to wasted CPU cycles.

Arun Valiaparambil
  • 545
  • 3
  • 7
  • Hello Arun, Its Hyper-visor who marked the WFI instructions as trap,right? Also I would like to know if WFI instructions is executed from guest OS and control is transfered to Hyper-visor running in EL2 but would control again come back to same guest OS who issued WFI? – Amit Singh Tomar Sep 03 '15 at 14:29
  • 1
    Yes hypervisor would have configured wfi/wfe to to be trapped. The os that executes wfi is added to a wait queue. Control coming back to the os is at the descretion of hypervisor scheduler. If the OS again becomes ready(due to an interrupt or event) hyp scheduler would would kick in and switch in the next os to be executed. (Pretty similar to os schedulers) – Arun Valiaparambil Sep 05 '15 at 04:56