Lower default 'maxfiles' to stay under default 'maxvnodes'

[olce]

Summary

Having 'kern.maxvnodes' higher than 'kern.maxfiles' mitigates a scenario
where some processes can eat up all vnodes in the system, causing
a deadlock, as long as the kernel itself does not create too many vnodes
without creating some file descriptor in some process' FD table. A very
small percentage (~0.6%) of excess vnodes at infinity, coupled with
a large difference near the origin (~50k), should cover basic cases more
than enough. Note however that this measure can be defeated, e.g., by
using nullfs mounts with non-trivial file hierarchies.

This change divides by 2 the previous 'maxfiles' value, which we suspect
will not be a problem in practice, as 'maxfiles' was before this change
already 130k for a 4GB machine, 524k for 16GB and 1M for 32GB (this
computation is purely linear).

[olce]

An alternative to D50125.

[kib]

The objections to the previous review are equally applicable to this one.

If you need to pace a misbehaving app, apply individual limits as a workaround, or fix the code.

Again, my position with all tweaks to the limits is that it is for local system administration, not for the system policy. Ideally, we should have defaults to be infinite and return ENOMEM if resource cannot be acquired. maxvnodes is just sizing the cache, it is not about policy.

[olce]

In D50311#1147819, @kib wrote:

If you need to pace a misbehaving app, apply individual limits as a workaround, or fix the code.

I've already answered this in D50125, we have a system problem here.

Again, my position with all tweaks to the limits is that it is for local system administration, not for the system policy. Ideally, we should have defaults to be infinite and return ENOMEM if resource cannot be acquired. maxvnodes is just sizing the cache, it is not about policy.

I agree, but we don't live in an ideal world. Pending a rework of these mechanisms, this mitigation, however imperfect it is, is still better than nothing.

[olce]

Chosen alternative is D50314.