From owner-freebsd-bugs@FreeBSD.ORG Sat Jun 3 21:26:41 2006 Return-Path: X-Original-To: freebsd-bugs@FreeBSD.org Delivered-To: freebsd-bugs@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 91FAE16A41F; Sat, 3 Jun 2006 21:26:41 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout1.pacific.net.au (mailout1.pacific.net.au [61.8.0.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2D3C943D49; Sat, 3 Jun 2006 21:26:41 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.0.86]) by mailout1.pacific.net.au (Postfix) with ESMTP id EAD18332AC3; Sun, 4 Jun 2006 07:26:39 +1000 (EST) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailproxy1.pacific.net.au (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k53LQcJ4020559; Sun, 4 Jun 2006 07:26:38 +1000 Date: Sun, 4 Jun 2006 07:26:38 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Rostislav Krasny In-Reply-To: <200606031853.k53IrqiA015998@www.freebsd.org> Message-ID: <20060604070822.X42164@delplex.bde.org> References: <200606031853.k53IrqiA015998@www.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-bugs@FreeBSD.org, freebsd-gnats-submit@FreeBSD.org Subject: Re: kern/98460: [PATCH] fpu_clean_state() cannot be disabled for not AMD processors, those are not vulnerable to FreeBSD-SA-06:14.fpu X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jun 2006 21:26:41 -0000 On Sat, 3 Jun 2006, Rostislav Krasny wrote: >> Description: > When FreeBSD is running on any non AMD processor an fpu_clean_state() function > adds unneeded operations to a context switch. My patch makes it possible > to disable the fpu_clean_state() by rebuilding a kernel with > "options CPU_FXSAVE_NO_LEAK". > > Colin Percival has nothing against my idea in general: Hrmph. My review implied that this should be done (not be me :-) before committing anything. The configuration should be dynamic and automatic, so that it doesn't take changes to zillions of configuration files to implement and document an option that almost no one will know to set. I think there is a simple feature test for the AMD misfeature. On i386's, this should be combined with the cpu_fxsr test so that only a single test is needed at runtime. On amd64's, the test would be 1 unnecessary compare-and-branch. I think it is not useful to have a configuration option to avoid this compare-and-branch. The overhead for fpu_clean_state() is a about 28 cycles. Has anyone actually noticed the extra context switching time for this? It is quite small compared with other overheads. E.g., the one for using the ACPI-[non]fast timecounter was about 2000 cycles at 2GHz. Even this was only noticeable under some loads. Bruce