From owner-freebsd-hackers Fri Aug 6 19:43:24 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from smtp2.tig.com.au (smtp2.tig.com.au [203.109.250.51]) by hub.freebsd.org (Postfix) with ESMTP id 4957314CC0 for ; Fri, 6 Aug 1999 19:43:16 -0700 (PDT) (envelope-from reman@tig.com.au) Received: from tig.com.au (p25-tmp7.syd.ihug.com.au [209.76.102.217]) by smtp2.tig.com.au (8.9.3/8.9.3) with ESMTP id MAA26445; Sat, 7 Aug 1999 12:42:19 +1000 Message-ID: <37AB9DED.7AA6612D@tig.com.au> Date: Sat, 07 Aug 1999 12:46:05 +1000 From: Chris X-Mailer: Mozilla 4.08 [en] (Win95; I) MIME-Version: 1.0 To: Dag-Erling Smorgrav Cc: John-Mark Gurney , freebsd-hackers@FreeBSD.ORG Subject: Re: Results of investigating optimizing calloc()... References: <001e01bedde3$d1af64c0$291c453f@kbyanc.alcnet.com> <19990804202932.50575@hydrogen.fircrest.net> <37A953EC.AB5E9F90@tig.com.au> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Dag-Erling Smorgrav wrote: > > Chris writes: > > Anyways thats all I can think of. The only way I can see that using DMA > > to refresh pages as a faster method is if the DMA controller can do it > > quicker than the CPU which I doubt is likely, also it will only be > > useful if it can do 32-bit addresses. > > Grr.. *read what I f###ing wrote* > > The issue is not speed, because this is something we do in the > background when there's nothing else to do. The issue is to avoid > thrashing the cache. for reference the PIIX4 controller which contains the 82C37 DMA controller http://developer.intel.com/design/chipsets/datashts/290562.htm Two things, 1) If the CPU isnt doing anything else then who cares if there is a L1 or L2 thrash which was half the point of my post. Because if the DMA controller is zeroing out pages and the CPU wants to access some memory not in the L1 or L2 cache, can't do it until the DMA is finished, then the mem line needs to be loaded. If the CPU can reload the cache lines (and all other cache lines that were in there previously but are needed again, and would have been there if not for the L1/L2 flush) after a stall quicker than the DMA can finish, then there is no point using DMA because of the performance hit. I'm not sure of the L1/L2 cache hit/miss ratio, perhaps there is not enough memory stalls in most programs and in this case using the DMA controller may be worth it. But for something like a DBMS which I assume may have a lot of cache misses this could be the death, especially if the DMA controller is as slow as a wet week. (ie 33Mhz vs 400+Mhz for a CPU). 2) On the other point I was making the DMA controller makes use of 24bit addresses and can transfer 128Kb at a time (looks like it now does not have to worry about boundaries) I am not sure how useful this is. Although it does make mention of addresses over 16Mb I couldnt see how to set them up. So from what I can see this method _may_ only be useful in zeroing out pages under the 16Mb boundary. see pages 68 and 158 If I am wrong about any of this, corrections please. regards, chris -- Christopher Day E-Mail reman@tig.com.au Homepage http://www.geocities.com/TimesSquare/Lair/1218 when the rain/when the children reign/keep your conscience in the dark melt the statues in the park - Fall On Me, REM To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message