Hi,
Lukand wrote:
I thought to generate less heat and use less power.
In theory, putting multiple "hlt" instructions might cause the CPU to enter the "HLT state" (after interrupting the previous "hlt") a fraction of a nanosecond sooner. However, if the previous "hlt" was on one cache line and the next "hlt" is on the next cache line, then you'll probably have the extra expense (and power consumption) involved in fetching an additional cache line, so it'd be much worse.
However....
In practice, entering and leaving the "HLT state" costs power (and time) too. If one IRQ occurs almost immediate after another, then the CPU does the first IRQ then switches to the "HLT state" then switches out of the "HLT state" almost immediately; and this will make performance (IRQ latency) much worse while also making power consumption worse. For this reason, multiple "hlt" instructions would probably make things worse (even when they're all in the same cache line). To avoid this problem; it might be better to do a loop of "nop" instructions until a certain amount of time (e.g. 1 us) has passed since the last IRQ, before using "hlt".
However...
Some CPUs (most newer CPUs) optimise "nop" so that it doesn't take any time (e.g. so it gets discarded after/during decoding and isn't actually executed in the normal sense). For these CPUs you'll probably want to use a "pause" instruction in the loop instead. Also, for CPUs with hyper-threading (or whatever AMD is going to call their version of it) you will want "pause" anyway, and might want to unroll the "pause loop" a little (so that the overhead of the loop itself doesn't effect the performance of the other logical CPU in the core as much).
Note that the optimum amount to unroll a loop (for all the loops mentioned) depends on multiple factors (e.g. if the CPU has a "loop detector" and what size it is), and would be different for different CPUs.
However...
For a real OS it's very likely that an IRQ handler will cause a task switch. For example, you might have a task waiting for a time-out; or waiting to receive data from the network, or from a file (from a storage device controller), or from a keyboard or mouse; where an IRQ means that the task can stop waiting. This mostly ruins all of the above.
Also; for multi-CPU systems, an IRQ received by one CPU might cause a task to unblock on a different CPU. In this situation; if the other CPU is using HLT then you need to send an IPI ("inter-processor interrupt") to it to wake it up. To avoid the need to send a (relatively expensive) IPI you mostly want to use "monitor" and "mwait" (if the CPU supports these instructions) instead of "hlt"; so that the other CPU wakes up when you write to some kind of "list of ready to run tasks".
Finally; it's very likely that the CPU has multiple other options for controlling power consumption (e.g. clock throttling, various "deeper sleep states", etc) that complicates everything even more.
Cheers,
Brendan