From: rmk@rmkhome.UUCP (Rick Kelly)
Organization: The Man With Ten Cats
Date: Wed, 16 Dec 1992 04:40:30 GMT
Reply-To: rmk@rmkhome.UUCP (Rick Kelly)

In article <1992Dec14.231244.22459@klaava.Helsinki.FI> torvalds@klaava.Helsinki.FI (Linus Torvalds) writes:
>In article <17543@umd5.umd.edu> mark@roissy.umd.edu (Mark Sienkiewicz) writes:
>>In article <1992Dec11.150512.21282@texhrc.uucp> someone@Texaco.com (Larry D. Pyeatt) writes:
>>>I recently saw an IBM clone with 32M RAM and 256K cache running OS2.  We
>>>ran several benchmarks and it was blazingly fast whenever the program was
>>>loaded in the lower 16M.  However, when the program was loaded in the 
>>>uncacheable upper 16M, performance dropped to about 25% of what it was.
>>>This had nothing to do with DMA.  We finally took out the upper 16M and
>>>the machine now provides better average performance than when it had 32M.
>
>First off, I can verify that this is true at least with some
>motherboards: I've had reports of similar things happening, and when I
>upgraded to 20MB I saw it myself.  The performance drop was more than an
>order of magintude in the worst case (ie when a process got only pages
>in the 16MB+ area, it slowed down *a lot*: dhrystone went from 12 secs
>to two minutes). 
>
>The problem seems to be caching: the 16MB+ area doesn't get cached at
>all for some reason.  I've had reports of it being cahce-size dependent,
>and that some motherboards need more than 64kB cache to handle the upper
>memory areas.  I'm waiting for my 256kB cache to find out. 

Just remember to increase the cache TAG ram at the same time.  The average
PC with 64k cache only has enough TAG for 16 megs.

>>This reminds me of something the CDC mainframes used to do:  They had
>>X amount of fast memory, Y amount of slow memory and Z amount of disk swap
>>space.  They would only execute programs out of fast memory.  When fast
>>memory started to fill up, they would swap out jobs/processes to slow
>>memory.
>>
>>Likewise, when the slow memory filled up, jobs that had been hanging around
>>in slow memory were swapped to disk, leaving more space for jobs being
>>swapped out of fast memory.
>>
>>It seems that Linux and 386BSD people would be in an ideal spot to try this
>>idea.  Yeah, it's using strange software to get around inferior hardware,
>>but that is what swapping to disk is too.  (Otherwise, we would all have
>>128 meg of ram instead of a swap area. :)
>>
>>So has anybody tried this?  Any comments on feasibility?
>
>I haven't tried anything like that, and frankly, I don't want to.  The
>PC architecture has it's problems as it is, and I don't really want to
>add more cludges to the system just to get that extra bit of
>performance.  I might have to change my attitude if it turns out that
>the new cache won't help, but we'll see. 
>
>As to feasability: why not? The natural thing to do would be to use them
>as buffer cache, but on an AT architecure that also loses (DMA... 
>Arggh).  It's not pretty though, and it would be terribly inconvenient
>to try out (do an additional memory test to check which areas are
>slower? The idle task could do it.  Hmm). 
>
>		Linus


-- 

Rick Kelly	rmk@rmkhome.UUCP	unixland!rmkhome!rmk	rmk@frog.UUCP