Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 07 Aug 1999 12:46:05 +1000
From:      Chris <reman@tig.com.au>
To:        Dag-Erling Smorgrav <des@flood.ping.uio.no>
Cc:        John-Mark Gurney <gurney_j@resnet.uoregon.edu>, freebsd-hackers@FreeBSD.ORG
Subject:   Re: Results of investigating optimizing calloc()...
Message-ID:  <37AB9DED.7AA6612D@tig.com.au>
References:  <001e01bedde3$d1af64c0$291c453f@kbyanc.alcnet.com> <xzpemhjpzac.fsf@flood.ping.uio.no> <19990804202932.50575@hydrogen.fircrest.net> <37A953EC.AB5E9F90@tig.com.au> <xzpk8rar32m.fsf@flood.ping.uio.no>

next in thread | previous in thread | raw e-mail | index | archive | help
Dag-Erling Smorgrav wrote:
> 
> Chris <reman@tig.com.au> 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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?37AB9DED.7AA6612D>