Date: Mon, 11 Dec 2017 11:19:43 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Conrad Meyer <cem@FreeBSD.org> Cc: 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: <20171211091943.GF2272@kib.kiev.ua> In-Reply-To: <201712110432.vBB4WbnE021090@repo.freebsd.org> References: <201712110432.vBB4WbnE021090@repo.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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). > > Logically, extend r286288 to cover all threads, by default. > > The world has largely moved on from i386. Most FreeBSD users and developers > test on amd64 hardware. For better or worse, we have written a non-trivial > amount of kernel code that relies on stacks larger than 8 kB, and it "just > works" on amd64, so there has been little incentive to shrink it. > > amd64 had its KSTACK_PAGES bumped to 4 back in Peter's initial AMD64 commit, > r114349, in 2003. Since that time, i386 has limped along on a stack half > the size. We've even observed the stack overflows years ago, but neglected > to fix the issue; see the 20121223 and 20150728 entries in UPDATING. > > If anyone is concerned with this change, I suggest they configure their > AMD64 kernels with KSTACK_PAGES 2 and fix the fallout there first. Eugene > has identified a list of high stack usage functions in the first PR below. This suggestion is completely bogus. > > PR: 219476, 224218 > Reported by: eugen@, Shreesh Holla <hshreesh AT yahoo.com> > Relnotes: maybe > Sponsored by: Dell EMC Isilon > > Modified: > head/sys/i386/conf/NOTES > head/sys/i386/include/param.h > > Modified: head/sys/i386/conf/NOTES > ============================================================================== > --- head/sys/i386/conf/NOTES Mon Dec 11 02:44:15 2017 (r326757) > +++ head/sys/i386/conf/NOTES Mon Dec 11 04:32:37 2017 (r326758) > @@ -968,7 +968,7 @@ device ndis > # KSTACK_PAGES is the number of memory pages to assign to the kernel > # stack of each thread. > > -options KSTACK_PAGES=3 > +options KSTACK_PAGES=5 > > # Enable detailed accounting by the PV entry allocator. > > > Modified: head/sys/i386/include/param.h > ============================================================================== > --- head/sys/i386/include/param.h Mon Dec 11 02:44:15 2017 (r326757) > +++ head/sys/i386/include/param.h Mon Dec 11 04:32:37 2017 (r326758) > @@ -113,7 +113,7 @@ > #define IOPAGES 2 /* pages of i/o permission bitmap */ > > #ifndef KSTACK_PAGES > -#define KSTACK_PAGES 2 /* Includes pcb! */ > +#define KSTACK_PAGES 4 /* Includes pcb! */ > #endif > #define KSTACK_GUARD_PAGES 1 /* pages of kstack guard; 0 disables */ > #if KSTACK_PAGES < 4
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20171211091943.GF2272>