Re: [9front] Understanding milli-CPUs (/dev/sysstat)

[Benjamin Riefenstahl <b.riefenstahl@turtle-trading.net>]

Hi sirjofri,

sirjofri writes:
> According to cons(3), load inside /dev/sysstat is a number in
> milli-CPUs. How is this number to interpret?
>
> Looking at stats.c they compare the number with 1000 (times the number
> of cpus).

My understanding is from Linux, but I hope this translates to Plan 9:
The load is the number of threads that are waiting in the scheduler for
time on some CPU, averaged over some time span.  So threads that wait on
some I/O in the kernel or on a synchronization primitive like
rendevous() do not count.  Only those threads are counted that will
actually use the CPU right away, once the scheduler lets them.

This means that 1 (thread) per CPU is fine, but everything above that
should better be temporary or intentional.  Otherwise you probably do
not have enough CPUs for your workload.  That's just a rule rule of
thumb, your mileage may vary as they say.

Counting the load in "millis" is probably just a way to avoid floating
point in the kernel.

> However, I have the following issue:
>
> I wrote a daily script which sends me an email via a cron job. The
> mail contains this load value from /dev/sysstat.

I see that this device is described in cons(3).  I do not see from that
documentation what time span sysstat uses.  It seems that you need to
write to the file to reset it and than read from it after some time.
But it also says that the vale is "decayed over time" which sounds like
some kind of moving average.  It does not say (unless I missed it), how
fast this decay is (i.e. again over which time span).

so long, benny