Date: Thu, 1 Jun 2006 14:27:13 +0200 From: "Attilio Rao" <asmrookie@gmail.com> To: "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: <3bbf2fe10606010527p5072dc2cmbbcbab039261f870@mail.gmail.com> In-Reply-To: <3bbf2fe10606010525g7893408asdca7ada37e0dab41@mail.gmail.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> <3bbf2fe10606010525g7893408asdca7ada37e0dab41@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
2006/6/1, Alexander Leidinger <Alexander@leidinger.net>: > 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 > automatically on demand). So one could use XMM instructions in RAID 5 > or crypto parts of the code to test if it is a performance benefit. Do > I understand the above part right that with this patch this is also > the case for us in the UP case, but not in the SMP case? Since it seems to be a mis-understanding about this I will try to explain better. The patch can be saw as a 3-step issue*: 1) Implementing a robust and working method to preserve FPU/MMX/XMM usage into the kernel 2) Modifing copyin/copyout/memcpy in order to use xmm registers (in a first moment I thought to bzero/bcopy too but, since they're used for short amount of datas, xmm usage is deprecated due to heavyness of context saving). 3) Giving a reliable and better version of memcpy (that I called i686_memcpy). 1 is achieved successfully and it is the same in UP and SMP arches. It's imported from Dragonfly and I tested on my boxes very carefully and for a long time. It never give me problems. 2 seems good too, even if it needs more stress-testing I think. It is the same on UP and SMP and needs no changes. 3 is what I was speaking about having different versions for UP and SMP. It needs more testing even if the code seems correct to me. It's important to understand that it is an example on how new architecture for FPU saving/restore can be used (you can see at it as a reference for further coding I guess). Maybe FPU_PICKUP/FPU_DROP could be modified and exported in order to be used in different parts of the kernel... So I hope it's clearer now. Attilio * I refer, for this discussion, exclusively to FreeBSD-i386 -- 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?3bbf2fe10606010527p5072dc2cmbbcbab039261f870>