From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 6 06:58:08 2006 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0A6D216B73B; Tue, 6 Jun 2006 06:48:13 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9576B43D45; Tue, 6 Jun 2006 06:48:12 +0000 (GMT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.13.4.20060308/8.13.4) with ESMTP id k566mB88046045; Mon, 5 Jun 2006 23:48:11 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.13.4.20060308/8.13.4/Submit) id k566m0df046035; Mon, 5 Jun 2006 23:48:00 -0700 (PDT) Date: Mon, 5 Jun 2006 23:48:00 -0700 (PDT) From: Matthew Dillon Message-Id: <200606060648.k566m0df046035@apollo.backplane.com> To: Alexander Leidinger References: <3bbf2fe10605311156p7e629283r34d22b368877582d@mail.gmail.com> <447DFA0C.20207@FreeBSD.org> <3bbf2fe10605311329h7adc1722j9088253515e0265b@mail.gmail.com> <20060601084052.D32549@delplex.bde.org> <3bbf2fe10605311632w58c2949buc072e58ac103d7d@mail.gmail.com> <20060601093016.ygeptkv80840gkww@netchild.homeip.net> Cc: Attilio Rao , freebsd-hackers@freebsd.org, Suleiman Souhlal , Bruce Evans , freebsd-arch@freebsd.org Subject: Re: [patch] Adding optimized kernel copying support - Part III X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jun 2006 06:58:08 -0000 :AFAIR the DFly FPU rework allows to use FPU/XMM instructions in their :kernel without the need to do some manual state preserving (it's done :... : :Bye, :Alexander. That actually isn't quite how it works. If the userland had active FP state then the kernel still has to save it before it can use the FP registers. The kernel does not have to restore it, however (that is, it can just let userland take a fault to restore its FP state). However, the kernel still has to mess around with CR0_TS when pushing and popping an FP context / save area. The FP state reworking in DragonFly had the following effects: * We now have a save area pointer instead of a fixed, static save area. This allows FP state to be 'stacked' without having to play weird games with a static save area. * The standard FP restoration fault is no longer limited to userland. The kernel can push its own state, switch away to another thread, switch back, and take a fault to restore it, independant of the user FP state. -- It would be possible to simplify matters and actually implement what you say... the ability to use FP registers without any manual state preserving. That is, to be able to treat the FP registers just like normal registers. It would require saving and restoring a great deal more state in the interrupt/exception frame push code and the thread switch code, though. It could be conditionalized based CR0_TS or it could just be done unconditionally. I'm not sure it would yield any improvement in performance, though. There is also the problem of the storage required to manage multiple save areas. It's something like, what, 512 bytes on the stack? Because of that DragonFly still implements an FPU interlock so the kernel doesn't stack more then one additional save area due to FAST interrupts, stacked exceptions, etc. -Matt