Date: Mon, 5 Jun 2006 23:48:00 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Alexander Leidinger <Alexander@Leidinger.net> Cc: Attilio Rao <asmrookie@gmail.com>, freebsd-hackers@freebsd.org, Suleiman Souhlal <ssouhlal@freebsd.org>, Bruce Evans <bde@zeta.org.au>, freebsd-arch@freebsd.org Subject: Re: [patch] Adding optimized kernel copying support - Part III Message-ID: <200606060648.k566m0df046035@apollo.backplane.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
: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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200606060648.k566m0df046035>