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

[Konstantin Belousov]

On Mon, Dec 11, 2017 at 05:26:12PM +0700, Eugene Grosbein wrote:
> On 11.12.2017 16:19, Konstantin Belousov wrote:
> > On Mon, Dec 11, 2017 at 04:32:37AM +0000, Conrad Meyer wrote:
> >> Author: cem
> >> Date: Mon Dec 11 04:32:37 2017
> >> New Revision: 326758
> >> URL: https://svnweb.freebsd.org/changeset/base/326758
> >>
> >> Log:
> >>   i386: Bump KSTACK_PAGES default to match amd64
> > i386 is not amd64, the change is wrong.
> > 
> > i386 has the word size two times smaller than amd64, which makes typical
> > frame smaller by 30-40% over same code on amd64. Also i386 has much
> > smaller available KVA size (tens of MB) and KVA fragmentation is both
> > more severe and more fatal due to this. I expect that your change will
> > make any non-trivial load which creates enough threads to either fail
> > randomly or deadlock.
> > 
> > If somebody tries to fit large load onto i386 machine, he must know what to
> > do and how to configure the kernel to adapt to the load (which does not
> > require the recompilation).
> 
> Its very easy to get kernel stack overflow with 11-STABLE/i386
> without any significant load due to abuse of kernel stack in many kernel subsystems
> as shown in the https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219476
> 
> Contrary, "enough threads" seems to be very non-trivial number of threads
> and pretty unusual load pattern for i386 as I run several such systems
> with kern.kstack_pages=4 for quite long time and have no problems.
> No random fails, no deadlocks. And with 2 pages only 11-STABLE/i386 is just unusable
> if one utilizes SCTP, IPv6, some WiFi connectivity, IPSEC or even very small ZFS pool.
> 
> I still wonder if there is really such load pattern that creates "enough threads"
> for i386 to make 4-pages stack troublesome.
Yes, there is such load pattern, it is when you do create threads. Your
load, as described, is static. Peter' stress2 includes some tests which
will highlight the change.

I am quite impressed by your ability to make generalization from single data
point.  Moving issues around because you care about your load, and do not
care about other usage patterns, is certainly the way to go.