Date: Tue, 6 Jun 2006 09:18:34 +0200 From: "Attilio Rao" <attilio@freebsd.org> To: "Matthew Dillon" <dillon@apollo.backplane.com>, "Alexander Leidinger" <Alexander@leidinger.net>, "Bruce Evans" <bde@zeta.org.au>, "Suleiman Souhlal" <ssouhlal@freebsd.org>, freebsd-arch@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: [patch] Adding optimized kernel copying support - Part III Message-ID: <3bbf2fe10606060018k7d9052eck672277079144ca10@mail.gmail.com> In-Reply-To: <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> <200606060648.k566m0df046035@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
2006/6/6, Matthew Dillon <dillon@apollo.backplane.com>: > :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. I tend to agree with you beacause it would be too much work/storage savings which will loose all the improvements gave to xmm registers. The point about using xmm registers is just performance improvements. I think that having an interlock into the kernel (and so just one kernel saving-state) is the better thing for performances, even if it doesn't provide a real unconditional usage. Attilio PS: Please consider too that xmm registers seem increasing performances just if used with aligned with aligned datas (movaps, movdqa), so not in the general case. MMXs, instead, seem giving very poor improvement, in particular on evolved architectures (>= P3) -- Peace can only be achieved by understanding - A. Einstein
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3bbf2fe10606060018k7d9052eck672277079144ca10>