On Fri, May 12, 2023 at 9:59 AM Jack <[email protected]> wrote: > > On 2023.05.12 12:23, Mark Knecht wrote: > [snip .....] > > One interesting point is that the first Gentoo page I found to > > look at the emerge man page shows LOAD as the value provided > > to the --load-average option, but nowhere does it specify anything > > other than it's a floating point value: > I suspect the specification of floating point implies that it CAN take > digits after the decimal point, but not that they are required, > although that should be easy enough to test. > > > > https://dev.gentoo.org/~zmedico/portage/doc/man/emerge.1.html > > > > For clarification reading other sites, my understanding is that a > > load average value of 1 in the top application is meant to > > represent 1 CPU core operating at 100%. Assuming that's > > true, then on Peter's 24 core machine, with LOAD=40, he's > > telling emerge it's ok to use more cores than his machine has. > > > > Is that consistent with your (or others) understanding? > Close, but not quite. (See > https://en.wikipedia.org/wiki/Load_(computing) for more details.) I > think your understanding will match any observations, but I see the > definition as different. I understand the load (instantaneous, not > average) is the number of processed in the "r" state, i.e., running or > waiting for a CPU slice. That excludes any process explicitly sleeping > or waiting for IO. Since it can change so quickly, the point load is > not very useful, so it is more commonly presented as a value averaged > over a period of time. Top shows 1, 5, and 15 minute averages. > > Again, --load-average tells emerge whether it can start a new > job/package, but has no control over how high the load will get based > on the already started jobs. If emerge starts new jobs when the load > is over that specified by --load-average, that does smell like a bug in > emerge. > > > > > I think the mistake is one of those easy to make ones where > > the human things 40% (hence 40) and the machine things > > 40% (hence 0.4) > > > > Cheers, > > Mark > >
OK, I find that all reasonable. One point about the Wikipedia description for anyone following who may not actually read it is that the average is accomplished with an exponential moving average and therefore is not, by definition, linear over time. As a little experiment that anyone can run I'll include a little AI generated batch file people can use to actually see more of what's going on in top, htop and btop. Note on my system the CPU affinity didn't work and I don't care to debug it. However this loops continuously until you hit ctrl-C. If you watch CPU load you'll see it climb quickly at first and then more slowly until you get up to 1.0. It will go a little higher (1.03 in my case) which is likely the CPU load from the programs monitoring the system and other background junk. None the less, 1 core running continuously generates as load of 1 after some period of time. As with all code on the Internet I take no responsibility for any damage caused my this code and neither does Google's Bard. #!/bin/bash # This batch program loops until you hit Ctrl-C. # Get the current processor affinity. affinity=$(cat /proc/self/cpuset) # Set the processor affinity to a single core. echo $affinity | sudo tee /proc/self/cpuset while true; do # Do nothing. : done # Reset the processor affinity to the default. echo "" | sudo tee /proc/self/cpuset
