svn commit: r326758 - in head/sys/i386: conf include

[Eugene Grosbein]

On 14.12.2017 18:51, Konstantin Belousov wrote:

>> I think thats's NFS code who is guilty. You can see example of amd64 (sic!) kstack exhaustion
>> due to 40+ frames deep call chain here:
>>
>> https://lists.freebsd.org/pipermail/freebsd-stable/2017-July/087429.html
> 
> Yes, NFS crosses network/VFS and often VM boundaries, so each subsystem
> adds its usual stack use footprint to the overall picture.  NFS reconnect
> is especially hard in this regard, and in case the direct dispatch is
> triggered (in this case over loopback) machine has no chance.
> 
> The backtrace you cited just reinforces the point that the i386 commit
> is wrong. It breaks the workload we aims as the main FreeBSD target,
> which is generic-purpose Unix workstation or server. The commit tries
> to make defaults fit for specific appliance load of router with IPSEC
> or ZFS on i386, which require extensive tuning on i386 anyway. Worse,
> as you prove above, the commit in fact does not fix the issues, it only
> papers over them and move easily triggered faults from one configuration
> to another.

Modern FreeBSD usage as workstation/server should not exclude IPv6, SCTP, WiFi,
and even ZFS nor IPSEC for i386. GENERIC kernel should not panic due to low volume
network activity with default settings.

Perhaps, it's time to make KVA_PAGES loader tunnable too?
And/or increase its default for i386 upto some value corresponding to stable management
of kern.threads.max_threads_per_proc=1500 (by default) with kstack_pages=4 ?

Maybe, KVA_PAGES=384 (1.5GB for 1500 threads)?