From owner-svn-src-all@freebsd.org Mon Dec 11 10:52:56 2017 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0001AE8E2A8; Mon, 11 Dec 2017 10:52:55 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8854D803B8; Mon, 11 Dec 2017 10:52:55 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id vBBAqgBd077110 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 11 Dec 2017 12:52:46 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua vBBAqgBd077110 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id vBBAqgLL077109; Mon, 11 Dec 2017 12:52:42 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 11 Dec 2017 12:52:42 +0200 From: Konstantin Belousov To: Eugene Grosbein Cc: Conrad Meyer , 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: <20171211105242.GH2272@kib.kiev.ua> References: <201712110432.vBB4WbnE021090@repo.freebsd.org> <20171211091943.GF2272@kib.kiev.ua> <5A2E5D44.9030904@grosbein.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5A2E5D44.9030904@grosbein.net> User-Agent: Mutt/1.9.1 (2017-09-22) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Dec 2017 10:52:56 -0000 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.