multiload: fix hang when per-thread load bandwidth is below 1 MiB/s

[karanthv]

Problem

multiload hangs forever, with every worker thread spinning at 100% CPU, when any memory-load thread measures less than 1 MiB/s during a sample window.

In LOAD_MEMORY_SAMPLE_MIBPS, each load thread publishes its bandwidth as (uint64_t)mibps into t->x.count. That field is also the handshake: main polls until x.count != 0 to know the thread finished the sample. When mibps < 1.0, the cast truncates to 0, so:

the thread sets cur_sample = nxt_sample and never reports this sample again;
main spins forever in while (ready == 0) waiting for a non-zero count.

This can happen in practice when many threads share a memory node with very low bandwidth. For example, 80 threads on a node degraded to about 60 MiB/s works out to about 0.76 MiB/s per thread. It can also be triggered with a large injection delay:

multiload -H -t 1 -m 16m -l stream-triad-nontemporal-injection-delay -d 1500000 -n 2 -v
# before: hangs after "main: sample_no=0"

Fix

Load threads now publish bytes/s instead of MiB/s in x.count, and main converts the value back to MiB/s before aggregating.x.countis 64 bits wide, so there is no overflow risk at any real bandwidth. A value of 0 would require a single pass over the load buffer to take millions of seconds, so the handshake no longer depends on bandwidth being at least 1 MiB/s.

The fix also removes the per-thread truncation error (previously up to 1 MiB/s per thread, summed across all load threads in Total(MiB/s)).

The per-thread values (ML(n) at -v -v, and PerThread= at -v) are now printed with %.3f, so bandwidth below 1 MiB/s is visible instead of rounding to 0 or 1.

Chase threads are unchanged. Theirx.countremains an iteration counter.

Testing
Injection-delay repro above: before the fix it hangs; after the fix it exits 0 and reports Total(MiB/s) of about 0.58.