Date: Sun, 19 May 1996 22:46:14 +1000 From: Bruce Evans <bde@zeta.org.au> To: asami@cs.berkeley.edu, bde@zeta.org.au Cc: ccd@stampede.cs.berkeley.edu, current@freebsd.org Subject: Re: some more on fast bcopy Message-ID: <199605191246.WAA13042@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
> * I missed that. It would probably be cleanest to save it via %edx in > * both cases. >Both cases? Where is the other place that I need to save it? (Sorry >for being so dumb.) The place that now uses `smsw'. > * I'm running with a fast bzero (8 fstl's in a loop) too. It is much simpler > * than fastmove since it doesn't need to worry about context switches. bcopy > * need not worry either (except for bugs). This improves the speed of a kernel build by a whole 0.125% (from about 400 seconds to about 400-0.5 seconds (+= more than 0.5 seconds :-). The system time is reduced from about 20 seconds to about 20-0.5 seconds (+- not much more than 0.5 seconds :-)). >Ok, so I guess I can modify bcopy to use this and it would work too, >right? Although I'm not sure how much that will help (I don't think >there are really big data movements from kernel space to kernel space, >are there?).... Copying pages is the largest single overhead for fork-exec, at least for small pages. pmap_copy_page() uses memcpy() if __GNUC__ > 1 so it won't benefit immediately from improvements in bcopy() (gcc generates a dumb inline version involving movsl. In my kernel, 34 out of 284 .o's use gcc's builtins for memcpy(), strcpy(), strlen() or something.) >Another place that it may help (and may fool lmbench and the likes :) >is libc, do I need to the complicated FP state save/restore in there >too? Or can that be a simple fnsave/frstor? Simple. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199605191246.WAA13042>