From owner-freebsd-current Sun May 19 05:47:14 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id FAA22580 for current-outgoing; Sun, 19 May 1996 05:47:14 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id FAA22575 for ; Sun, 19 May 1996 05:47:09 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id WAA13042; Sun, 19 May 1996 22:46:14 +1000 Date: Sun, 19 May 1996 22:46:14 +1000 From: Bruce Evans Message-Id: <199605191246.WAA13042@godzilla.zeta.org.au> To: asami@cs.berkeley.edu, bde@zeta.org.au Subject: Re: some more on fast bcopy Cc: ccd@stampede.cs.berkeley.edu, current@freebsd.org Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > * 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