[OpenIndiana-discuss] Initial install of 2020.10 on Z840 for production use

[Reginald Beardsley]

 ROFL! I just noticed I didn't speciy a count. It had written 5.5 TB at over 200 MB/s and would have continued until I filled all 6.7 TB of space.

I assume *nothing* about computers. I assert that the difference between a senior and junior person is the junior person makes assumptions that the senior person has learned not to make. No computer is like any other unless great effort has gone into making certain that they are.

I'm not familiar with the Solaris tunable parameters as I've never needed to look at them. The degradation of interactive response is still a big concern. However, it may not be possible to fix that in the Unix fork-exec model.

Long ago I set up a MicroVAX II so it would run batch jobs without adverse impact on interactive users. We ran it for months at 100% CPU utilization, but when an interactive user logged in it behaved as if the machine was idle. It took a lot of reading the Great Grey Wall of VMS manuals to figure out how to do that, but it was well worth it. Prior to that other grad students would start jobs that made the machine unusable for interactive use for days. The rough limit on our batch jobs was 70-100 hrs of CPU time. Because interactive use requires so few resources other than memory, the effect of reserving memory for interactive users had not discernable effect on batch throughput. WS_EXTENT, WS_QUOTA, etc were my best friends. I reserved enough space for a login that the editor did not get swapped to disk. Without very complex bookkeeping that is not possible without using a transient process space model instead of fork-exec.

For many years controlling resident memory was the feature I thought Unix needed most, but I eventually realized how difficult that would be to implement. I *think* it could be done at session level, but I haven't considered the problem in a *very* long time. And Unix is not the same as it was when I did.

Reg