Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site kobold.UUCP Path: utzoo!linus!security!genrad!grkermit!masscomp!kobold!tjt From: tjt@kobold.UUCP Newsgroups: net.arch,net.micro.68k,net.micro.16k Subject: Re: 16k vs 68k vs 432 Message-ID: <252@kobold.UUCP> Date: Thu, 12-Jan-84 14:26:13 EST Article-I.D.: kobold.252 Posted: Thu Jan 12 14:26:13 1984 Date-Received: Sat, 14-Jan-84 02:46:37 EST References: <524@nsc.UUCP>, <220@dual.UUCP> <3451@utzoo.UUCP>, <247@kobold.UUCP> <3463@utzoo.UUCP> Organization: Masscomp, Westford, MA Lines: 29 The time and space overhead of treating N "real" pages as a single "logical" page should indeed be insignificant if N is small (say 2 or 4). Once N gets as large as 8 I think the overheads may become noticable although I do not have measurements to back this up. However, the amount of page table space required to map a 4M image with 512 byte pages is 8K entries which is 32Kbytes if each entry requires 4 bytes. This represents about 3% of a 1M physical memory system used for storing page tables. A system with 4K byte pages would only require 1K entries or 4K bytes or about .4% of the same physical memory. Of course, a system with 4K byte pages will waste additional space due to fragmentation. Because of these opposing tradeoffs, there is an optimum page size for given segment size which grows roughly as the square root of the segment size (assuming uniformly distributed segment sizes). It turns out that for segments ranging from 0-~64K bytes and 4 byte page table entries the optimal page size is 512 bytes. For segments from 0-.25M the optimal page size is 1K bytes, for 0-1M segments 2K bytes and for 0-4M segments the optimal page size is 4K bytes. Although there are lots of unix programs in the 100-200K byte range (on the vax, csh, vi, emacs) there aren't many larger (however, there is always franz and macsyma). On the other hand, the extra 2% of memory you would recover by using a larger page size is probably not going to seriously affect the performancs of one of these huge programs running on a 1M system anyway. -- Tom Teixeira, Massachusetts Computer Corporation. Westford MA ...!{ihnp4,harpo,decvax}!masscomp!tjt (617) 692-6200 x275