On 28 January 2015 at 06:50, arisawa <arisawa@ar.aichi-u.ac.jp> wrote:

> Eric’s users are all gentleman, all careful people and all skillful
> programmers.
> If your system is served for university students, you will have different
> thought.
>

You might also be running services on it, and it's reasonable that it
should manage its resources.
It's best to refuse a new load if it won't fit, but that requires a fairly
careful system design and works
best in closed systems. In a capability system you'd have to present a
capability to create a process,
and it's easy to ration them. Inside Plan 9, one could have a nested
resource allocation scheme
for the main things without too much trouble. Memory is a little different
because you either under-use
(by reserving space) or over-commit, as usually happens with file-system
quotas.

With memory, I had some success with a hybrid scheme, still not intended
for multi-user,
but it could be extended to do that. The system accounts in advance for
probable demands of
things like fork/exec and segment growth (including stack growth). If that
preallocation is then not
used (eg, because of copy-on-write fork before exec) it is gradually
written off. When that fails,
the system looks at the most recently created process groups (note groups)
and kills them.
It differs from the OOM because it doesn't assume that the biggest thing is
actually the problem.
Instead it looks back through the most recently-started applications since
that corresponded to my usage.
It's quite common to have long-running components that
soak up lots of memory (eg, a cache process or fossil) and they often
aren't the ones that caused
the problem. Instead I assume something will have started recently that was
ill-advised. It would be better
to track allocation history across process groups and use that instead but
I needed something simple,
and it was reasonably effective.

For resources such as process (slots), network connections, etc I think a