From owner-freebsd-arch@FreeBSD.ORG Sat Dec 24 11:44:27 2011 Return-Path: Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 499DC106566B; Sat, 24 Dec 2011 11:44:27 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail03.syd.optusnet.com.au (mail03.syd.optusnet.com.au [211.29.132.184]) by mx1.freebsd.org (Postfix) with ESMTP id D24DD8FC0A; Sat, 24 Dec 2011 11:44:26 +0000 (UTC) Received: from c211-30-171-136.carlnfd1.nsw.optusnet.com.au (c211-30-171-136.carlnfd1.nsw.optusnet.com.au [211.30.171.136]) by mail03.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id pBOBiMTM024624 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 24 Dec 2011 22:44:24 +1100 Date: Sat, 24 Dec 2011 22:44:22 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Alexander Best In-Reply-To: <20111224093753.GA12377@freebsd.org> Message-ID: <20111224222040.Q2266@besplex.bde.org> References: <20111223235642.GA37495@freebsd.org> <20111224160050.T1141@besplex.bde.org> <20111224093753.GA12377@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG Subject: Re: [rfc] removing -mpreferred-stack-boundary=2 flag for i386? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Dec 2011 11:44:27 -0000 On Sat, 24 Dec 2011, Alexander Best wrote: > On Sat Dec 24 11, Bruce Evans wrote: >> On Fri, 23 Dec 2011, Alexander Best wrote: > ... >>> the gcc(1) man page states the following: >>> >>> " >>> This extra alignment does consume extra stack space, and generally >>> increases code size. Code that is sensitive to stack space usage, >>> such as embedded systems and operating system kernels, may want to >>> reduce the preferred alignment to -mpreferred-stack-boundary=2. >>> " >>> >>> the comment in sys/conf/kern.mk however sorta suggests that the default >>> alignment of 4 bytes might improve performance. >> >> The default stack alignment is 16 bytes, which unimproves performance. > > maybe the part of the comment in sys/conf/kern.mk, which mentions that a stack > alignment of 16 bytes might improve micro benchmark results should be removed. > this would prevent people (like me) from thinking, using a stack alignment of > 4 bytes is a compromise between size and efficiently. it isn't! currently a > stack alignment of 16 bytes has no advantages towards one with 4 bytes on i386. I think the comment is clear enough. It it mentions all the tradeoffs. It is only slightly cryptic in saying that these are tradeoffs and that the configuration is our best guess at the best tradeoff -- it just says "while" for both. It goes without saying that we don't use our worst guess. Anyone wanting to change this should run benchmarks and beware that micro-benchmarks are especially useless. The changed comment is not so good since it no longer mentions micro-bencharmarks or says "while". > so specifying -mpreferred-stack-boundary=2 on i386 is absolutely mandatory. Not mandatory; just an optimization. > > please see the attached patch, which also introduduces a line break in order to > describe the stack alignment issue in a paragraph of its own. There should also be an empty line for a paragraph break. % +# Explicitly prohibit the use of FPU, SSE and other SIMD operations inside the % +# kernel itself. These operations are exclusively reserved for user % +# applications. This part was actually wronger: - these operations are not really reserved, but were just not supported in the kernel - they have been supported in the kernel for some time, although anything wanting to use the compiler to generate them would have to do something to kill the options added here. Kernel code using them must inform the kernel that it is doing so, using fpu_kern*(9undoc), and this is only valid in some contexts (more or less for kernel-only threads) so we still prevent compilers from using them routinely. The makefile is not the right place to describe any of this, Bruce