Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!rpi!crdgw1!crdos1!davidsen From: davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) Newsgroups: comp.arch Subject: Re: SunMMU history Message-ID: <3143@crdos1.crd.ge.COM> Date: 22 Jan 91 14:30:47 GMT References: <1991Jan19.133914.23871@bellcore.bellcore.com> <756@taniwha.UUCP> Reply-To: davidsen@crdos1.crd.ge.com (bill davidsen) Organization: GE Corp R&D Center, Schenectady NY Lines: 19 In article <756@taniwha.UUCP> paul@taniwha.UUCP (Paul Campbell) writes: | Another issue that hasn't really been talked about here has to do with disk | bandwidth, esp. on some of the slower transfer-rate disks (that can't do | 1:1 interleaved transfers). With 8k pages you have to move 8k/page fault | so latency from disk can be much higher. These days it's not such a big | deal since most disks can do 1:1 but even a couple of years ago a system | configured with 'big' ie 8k pages could perform much worse than a 4k or | 2k system I think it's a fair statement that the optimal page size is a function of disk access time, throughput, and physical memory size. In a system with small memory a small page size may result in better memory usage, within limits. Obviously subject to CPU and MMU capability considerations as well. -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) "I'll come home in one of two ways, the big parade or in a body bag. I prefer the former but I'll take the latter" -Sgt Marco Rodrigez