getloadavg(3) can give a number > 1.0 even with 1 CPU.

In a system with 2 cores, if you get 2.0, that means you have one task being scheduled all the time on each CPU (assuming there is no CPU affinity magic in place), which the optimal capacity, i.e 100%.

If you get 4.0, you have 2 tasks per CPU, so the system is overloaded taking twice the amount of load it can handle. For the semantics of the Device Capabilities API is probably fair to say it is 100%. It is just that getloadavg(3) gives you more information about how overloaded the system is.

What the current implementation is doing is getting the CPU Ratio, which is an instant snapshot of the CPU usage. This is not really useful because if you are unlucky, you might get 100% in the first call and 2% in a call performed immediately after the first. The user of the API would have to do a lot of sampling in order to get some useful information.

This article here [1] has a good explanation about this, including a algorithm very similar to what is implemented on this patch. I would go for the getloadavg(3) solution, rounding it to 1.0 when is greater that 1.0 and taking the number of CPUs into account. It will work on Mac, Linux, Tizen and probably Android, not to mention the simplicity (will reduce this code to one line).

[1] http://juliano.info/en/Blog:Memory_Leak/Understanding_the_Linux_load_average