Date: Thu, 14 Dec 2017 18:00:47 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Eugene Grosbein <eugen@grosbein.net> Cc: John Baldwin <jhb@FreeBSD.org>, Conrad Meyer <cem@FreeBSD.org>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r326758 - in head/sys/i386: conf include Message-ID: <20171214160047.GL2272@kib.kiev.ua> In-Reply-To: <5A329B26.9040504@grosbein.net> References: <4a9c76c9-8063-9420-b198-14487b089840@FreeBSD.org> <5A30378A.3040609@grosbein.net> <e2c426c3-41ed-2dd8-c5d4-15c60d8f7303@FreeBSD.org> <5A3261BD.5050404@grosbein.net> <20171214115149.GC2272@kib.kiev.ua> <5A3268E9.506@grosbein.net> <20171214122659.GF2272@kib.kiev.ua> <5A327597.3010300@grosbein.net> <20171214152324.GJ2272@kib.kiev.ua> <5A329B26.9040504@grosbein.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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).
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20171214160047.GL2272>