From owner-cvs-all Thu Mar 20 16:42:41 2003 Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B651437B401; Thu, 20 Mar 2003 16:42:37 -0800 (PST) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5FF9643F3F; Thu, 20 Mar 2003 16:42:36 -0800 (PST) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.12.8/8.12.8) with ESMTP id h2L0gZRv005002 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 20 Mar 2003 19:42:35 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id h2L0gUN04484; Thu, 20 Mar 2003 19:42:30 -0500 (EST) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15994.24566.411903.248919@grasshopper.cs.duke.edu> Date: Thu, 20 Mar 2003 19:42:30 -0500 (EST) To: Peter Grehan Cc: Jake Burkholder , src-committers@freebsd.org, cvs-src@freebsd.org, cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/powerpc/powerpc fpu.c genassym.c swtch.S trap.c In-Reply-To: <3E7A43E1.DA0D75F0@freebsd.org> References: <200303201028.h2KASKU9090258@repoman.freebsd.org> <20030320110240.A3985@grasshopper.cs.duke.edu> <20030320144838.O76446@locore.ca> <15994.7655.668902.294563@grasshopper.cs.duke.edu> <3E7A43E1.DA0D75F0@freebsd.org> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Peter Grehan writes: > > Yes. At least on the alpha, gcc uses the floating point > > registers/instructions extensively. So even a process which isn't > > intentionally using floating point will likely take a FEN trap. > Using a very simplistic approach of always saving/restoring the fp regs on each context switch, it turns out not to be not really worth it for UP alpha. It shaves 2-3 seconds of a make -j4 kernel build (781sec vs 778sec), but bloats the context switch time by a much more measurable amount in most cases: ------------------------------------------------------------------------- Host OS 2p/0K 2p/16K 2p/64K 8p/16K 8p/64K 16p/16K 16p/64K ctxsw ctxsw ctxsw ctxsw ctxsw ctxsw ctxsw --------- ------------- ------ ------ ------ ------ ------ ------- ------- thunder.s FreeBSD 5.0-C 5.8900 7.1300 17.0 14.0 63.2 21.3 84.2 thunder.s FreeBSD 5.0-C 4.5200 6.9400 19.3 14.0 49.9 20.8 65.4 (first entry is non-lazy, second entry is lazy) > Although I've not seen it, this does appear to be the case with PPC as well, > judging by a recent NetBSD thread: > > http://mail-index.netbsd.org/port-powerpc/2003/03/17/0001.html > Wow, it would be great to fix gcc to not be so friendly with the fp registers. That seems to be the best idea. Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message