Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

This is another misunderstanding/misconnection. "kernel_task" is used to report "missing" CPU time so the CPU usage accounting remains consistent even when the CPU is throttled. That does not mean either the kernel or userland have any input to the thermal throttling functions.

There's also multiple levels of protection and throttling. At the lowest level, various ICs on the board (e.g. power regulators) will turn themselves off if they overheat. Somewhere above that, firmware will definitely exert /some/ control, to cover odd situations like the machine hanging while booting. Above that, the kernel or userspace can add another layer — but like each of the layers before, that layer can only lower the limits further.

Having thermal management in userland (and nowhere else) would be legal suicide. Imagine the lawsuits from people accidentally burning their legs...



Thanks for this.

I believe you are correct, although I did think that kernel_task was there to help cool the components down, and not simply as a devide to report throttled CPU usage consistently with unthrottled.

That said, I didn't mean to say that thermal throttling only happened in userland but rather that it did happen there, even though it might also happen elsewhere.

Within the context of this thread, this is relevant since in this case the CPU was not being thermally throttled as it was running cool, but something was still throttling the amount of power going to it.

I was merely suggesting that Nextgrid's affirmation that it must have been the firmware throttling the CPU is not necessarily true. Given that there is a software component to thermal management (or at least I thought so), it's only logical to assume that there may be a software component of whatever other throttling was occurring without it necessarily being suicidal as suggested.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: