Date: Sun, 4 Jun 2006 07:26:38 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Rostislav Krasny <rosti.bsd@FreeBSD.org> 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 Message-ID: <20060604070822.X42164@delplex.bde.org> In-Reply-To: <200606031853.k53IrqiA015998@www.freebsd.org> References: <200606031853.k53IrqiA015998@www.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060604070822.X42164>