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

[Konstantin Belousov]

On Thu, Dec 14, 2017 at 10:39:18PM +0700, Eugene Grosbein wrote:
> On 14.12.2017 22:23, Konstantin Belousov wrote:
> 
> >>> Sigh. This would make i386 even less usable for everybody, perhaps
> >>> except you. Because default 3G of UVA is too small for some common tasks
> >>> (thanks clang, but also e.g. pypy), and you reduce the user address
> >>> space even more.
> >>
> >> Those who need 3GB of UVA within single process should not use 32 bit system in first place, should they?
> > 
> > Why do you even consider it acceptable to break the configuration just
> > because you are not interested in the workload ?
> 
> I do not consider it is acceptable. I'm trying to find compromise.
If you do not find the proposed change acceptable, why do you propose
it at all ?

> 
> > 3G cumulative VA does not translate into 3G of usable addresses: the bss
> > is reserved, the address space is fragmented due to need of growing
> > stack to not conflict with mmaped regions. As result, applications get
> > slightly less than 2G usable without tricks, and to apply the tricks
> > apps must know details of the AS layout, i.e. breaking the portability.
> > 
> > 386 arch configuration is not perfect but it provides the main intended
> > service of general-purpose workstation, with some limitation caused by
> > 32bit of address space being somewhat low for modern code. Appliance
> > flavoring of the default 386 config is unacceptable.  Keep your tweaks
> > local.
> 
> Do you think that kstack overflow of general-purpose workstation using NFS
> or IPv6 or WiFi with SCTP is OK? I do not.

Kernel stack overflow is not 'OK', but two things are equally troublesome:
- papering over the problem of large structures allocated on stack by
  increasing the stack size;
- ignoring the explanation why the stack increase is problematic by itself
  and generating thread consisting of 50+ content-less messages claiming
  that 'it fixes the problem for me'.

The proper route to fix the issues was already explained more than
several times, and you (and I, and other people) participated in the
ongoing efforts there. If it is so much important to you, wave the flag
and herd the action, by asking relevant people to help with fixes, be it
writing the patches, providing reviews or just finding the place where
the stack is abused. It requires identification and time to think and
develop specific changes for each place, and cannot happen in one day.
But it also would not break KVA-starved architectures and provide fixes
relevant to even KVA-ample machines, as you other example shown.

For the case of extreme use, there is still the tunable (and ZFS on i386
is extreme).