Path: utzoo!attcan!uunet!know!cs.utexas.edu!tut.cis.ohio-state.edu!quanta.eng.ohio-state.edu!kcgl1.eng.ohio-state.edu!JONESD
From: JONESD@kcgl1.eng.ohio-state.edu (David Jones)
Newsgroups: comp.arch
Subject: Re: VAX RISC
Message-ID: <6092@quanta.eng.ohio-state.edu>
Date: 2 Nov 90 16:46:15 GMT
References: <10948@pt.cs.cmu.edu> <1990Nov1.180252.8427@zoo.toronto.edu>
Sender: news@quanta.eng.ohio-state.edu
Organization: Ohio State University
Lines: 21
Nntp-Posting-Host: kcgl1.eng.ohio-state.edu

Everyone who is posting on this topic is assuming that a 512 byte page size
is simply not viable on a RISC machine.  Bearing in mind that the memory
allocation size is not the paging I/O size, what is the actual performance
hit incurred by using a smaller page?

A small page means page tables are larger and a larger translation buffer is
needed to cover the same address space. How much effectiveness does the
translation buffer actually lose because of this?

For a given memory reference pattern, the smaller page size probably means
more page faults are incurred (especially if they are demand zero faults).
A properly tuned OS doesn't spend much time in the page fault code, so what is
the actual impact of the small page size?


David L. Jones               |      Phone:    (614) 292-6929
Ohio State Unviversity       |      Internet:
1971 Neil Ave. Rm. 406       |               jonesd@kcgl1.eng.ohio-state.edu
Columbus, OH 43210           |               jones-d@eng.ohio-state.edu

Disclaimer: A repudiation of a claim.