Path: utzoo!utgpu!watserv1!watmath!att!pacbell.com!ames!rex!samsung!emory!gatech!udel!brahms.udel.edu!gdtltr
From: gdtltr@chopin.udel.edu (root@research.bdi.com (Systems Research Supervisor))
Newsgroups: comp.arch
Subject: Re: Page size and linkers (was: Re: SunMMU history)
Message-ID: <16295@chopin.udel.edu>
Date: 26 Jan 91 00:04:24 GMT
References: <3981@skye.ed.ac.uk> <MOSS.91Jan21172107@ibis.cs.umass.edu> <45242@mips.mips.COM>
Organization: Brain Dead Innovations, Inc. (BDI)
Lines: 27

In article <45242@mips.mips.COM> mash@mips.COM (John Mashey) writes:
=>
=>Yes,  although as it stands, the tool only does it for code, not data;
=>for many programs, code impact on paging and TLB is much less than
=>data impacts .... or in some cases, the code impact is horrible, but
=>there's nothing in the world that can be done about it except to have
=>huge caches, and even better, fast cache refill.  (Consider the kind of
=>program that's >200MB of code, much of it in a giant single loop,
=>leading to a high I-cache miss rate.)

   I'm not an expert, so please pardon me if this is a stupid or obvious
question.
   Is any work being done in dynamically adjusting cache policies? In
other words, are there any caches out there that can detect this sort of
thing and adjust the line size to reduce refill overhead?

                                        Gary Duzan
                                        Time  Lord
                                    Third Regeneration



-- 
                            gdtltr@brahms.udel.edu
   _o_                      ----------------------                        _o_
 [|o o|]   Two CPU's are better than one; N CPU's would be real nice.   [|o o|]
  |_o_|           Disclaimer: I AM Brain Dead Innovations, Inc.          |_o_|