Messages in this thread | | | Date | Sat, 16 Nov 2002 19:30:03 +0100 | From | Andi Kleen <> | Subject | Re: [CFT][PATCH] 2.5.47 Athlon/Druon, much faster copy_user function |
| |
On Sat, Nov 16, 2002 at 01:22:51PM -0500, Akira Tsukamoto wrote: > On Sat, 16 Nov 2002 11:56:52 +0100 > Andi Kleen <ak@suse.de> mentioned: > > > > You don't seem to save/restore the FPU state, so it will be likely > > corrupted after your copy runs. > > This is the main question for me that I was wondering for all week. > My first version was using fsave and frstore, so > just changing three lines will accomplish this. > Is it all I need? Any thing elase needed to consider using fpu register?
You are currently corrupting the user's FPU state.
The proper way to save it is to use kernel_fpu_begin()
> > > > Also I'm pretty sure that using movntq (= forcing destination out of > > cache) is not a good strategy for generic copy_from_user(). It may > > be a win for the copies in write ( user space -> page cache ), > > Yes, that why I included postfetch in the code because movntq does not leave > them in the L2 cache.
That looks rather wasteful - first force it out and then trying to get it in again. I have my doubts on it being a good strategy for speed.
> > but > > will hurt for all the ioctls and other things that actually need the > > data in cache afterwards. I am afraid it is not enough to do micro benchmarks > > here. > > check above?
Use special function calls for them, don't put it into generic copy_*_user
Also you should really check for small copy and not use the FPU based copy for them. Best is probably to use a relatively simply copy_*_user (no FPU tricks, just an unrolled integer core) and change the VFS and the file systems to call a special function from write(), but only when the write is big.
-Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |