From owner-svn-src-head@freebsd.org Mon Dec 11 16:18:48 2017 Return-Path: Delivered-To: svn-src-head@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 9B1BCE96A7C; Mon, 11 Dec 2017 16:18:48 +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 421656CC2A; Mon, 11 Dec 2017 16:18:48 +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 vBBGIds3099560 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 11 Dec 2017 18:18:42 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua vBBGIds3099560 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id vBBGIdc7099559; Mon, 11 Dec 2017 18:18:39 +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 18:18:39 +0200 From: Konstantin Belousov To: rgrimes@freebsd.org 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: <20171211161839.GM2272@kib.kiev.ua> References: <20171211152219.GL2272@kib.kiev.ua> <201712111533.vBBFX8sl081789@pdx.rh.CN85.dnsmgr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201712111533.vBBFX8sl081789@pdx.rh.CN85.dnsmgr.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-head@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Dec 2017 16:18:48 -0000 On Mon, Dec 11, 2017 at 07:33:08AM -0800, Rodney W. Grimes wrote: > > On Mon, Dec 11, 2017 at 07:09:10AM -0800, Rodney W. Grimes wrote: > > > The current comment about a pcb, I thought that code was changed > > > so we only put the pointer to a pcb on the stack. > > > > pcb is on top of the stack, followed by the userspace FPU registers save > > area. I do not see any sense in existence of pcb in modern kernel, it is > > a remnant of the user area that was swappable. Currently pcb is swappable > > as well, but the value of this is much less then the overhead we pay by > > the stack space reduction. > > How about KSTACK_PAGES should be KSTAKE_BYTES/PAGESIZE, and we > need a much better formula for define of KSTACK_BYTES so that > these facts are more accurately defined? The FPU save area size depends on CPU we booted on, so if we increase (or decrease) it statically, we make a decision that is not good for one or another generation of processors. > > And a compile time assert if this ever growes to something unreasonable > that would cause other issues. So far it is an overkill, Intel did not passed the page boundary with all extensions defined. > > I fully agree with you that just bumping KSTACK_PAGES is very much > the wrong way to fix the i386 issue of certain code not running, > it is that code that should be examined for over usage of the stack. In fact there is a tunable which I added to avoid recompiling kernel if specific load requires large stack, keeping ZFS in mind. > > I can assert that the base i386 system is very usable for tons of > things without this change, I have at least 30 VM's running FreeBSD > 11.1/i386 in some very small footprints, typically 64MB, that have > zero issues. But then they are not using any of the code that > sited as problem areas. > > > FPU save area is the on of the problem which makes us increase the amd64 > > stack size, AVX or even AVX512 make the things much worse. It is unlikely > > that somebody would run 32bit kernel on machine capable of that extensions, > > i.e. Haswell or Skylake. > > Your igonoring the virutalization world, host is a skylake or haswell, guest > is i386 as it has small memory needs and no use to waste half of all pointers. If you are serious about avoiding the waste, then you would also disable unused extensions eating save area space, e.g. AVX512. AVX might be still useful (but not required) if AESNI or SHA extensions are used. > > We need to break the developers model that i386 is dead and that i386 is > not running on extremly modern hardware due to the factor of virtualization. > > Output from one of my VM's running inside bhyve: > > # uname -a > FreeBSD filestore.dnsmgr.net 11.1-RELEASE FreeBSD 11.1-RELEASE #0 r321309: Fri Jul 21 04:10:47 UTC 2017 root@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC i386 > > # dmesg | head -24 > Copyright (c) 1992-2017 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 11.1-RELEASE #0 r321309: Fri Jul 21 02:08:28 UTC 2017 > root@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 > FreeBSD clang version 4.0.0 (tags/RELEASE_400/final 297347) (based on LLVM 4.0.0) > VT(vga): resolution 640x480 > info: [drm] Initialized drm 1.1.0 20060810 > CPU: Intel(R) Core(TM) i5-3210M CPU @ 2.50GHz (2494.39-MHz K8-class CPU) This is quite old processor, IvyBridge is 6 generations old :).