you have made an awfully lot of assumptions about our systems and our programs...

Um. No. I haven't. As someone who spent an awful long time trying to satisfy a set of misbegotten requirements--that I'd identified as such very early on, but was not in a position to counter the bs--I can assure you, to the tune of €15 million development effort by some every clever people; it ... doesn't ... work! .

Take your example--"long running processes that put sustained load on your systems". If at the very instant that you choose to query the current cpu load average; a tcp packet arrives; or an asynchronous IO completes; or a process forks; or a process malloc()s an amount of memory that exceeds that process' current virtual memory footprint; or an interrupt (soft or hard) occurs; or any of a zillion other events happen on what was a clock-tick earlier a totally quiescent system; then you will recive back a (near) 100% reading. Because when a thread is ready to run, it will run at 100% cpu until it hits a reason to block.

So, your system that may have been running at 1% or 2% load average for minutes (or hours or days) will, for that brief instance that you do your query, appear to be running flat out. And you are going to base long term decisions opon that?

NB:Anything lasting more than a microsecond is "long term" in the context of modern cpus running at 2+ GHz.

Translation: Even a system, apparently running at 3% load average; is actually running at 100% for a few clock cycles, and then 0% for a few more; and then 100% for a few more; and then 0% for a few more. And so on ad nauseum.

What ever system defined mechanism you use (eg. GetSystemTimes()), has already performed some essentially arbitrary calculation to produce a figure that is somewhere between 0% and 100%. And in the time it takes (even C code) to

1. issue the call;
2. transfer through from ring 3 to ring 0;
3. query the appropriate privileged cpu registers;
4. wait for processor cache to be flushed;
5. access the static memory location(s) holding the previous state;
6. Wait (if required) for the data cache to flush and the cache line to be re-populated;
7. retrieve the raw value;
8. perform its own averaging calculation;
9. update the static state;
10. stack teh calculated value to be returned;
11. transition through the call gates from ring 0 to ring 3;

Now your code has its "instantaneous" cpu load average value... but it is already many thousands, if not millions, of clock cycles out-of-date.

Nothing, repeat, nothing you can do with this value will in any way reflect reality. Because reality already moved on at every clock cycle between you issuing the request, and receiving the reply.

You might as well, for all the difference in accuracy it will make, base your scheduling/priority/throttling mechanism upon

my $load = int( rand 1000 ) / 10;.

Yes. What you receive, by the time you receive it, really is that arbitrary.