home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!wupost!sdd.hp.com!mips!mash
- From: mash@mips.com (John Mashey)
- Newsgroups: comp.sys.sgi
- Subject: Re: finding page size?
- Date: 18 Aug 1992 18:45:01 GMT
- Organization: MIPS Computer Systems, Inc.
- Lines: 42
- Message-ID: <l92h9dINNeqj@spim.mips.com>
- References: <1992Aug18.072025.11920@CSD-NewsHost.Stanford.EDU> <onughl0@zuni.esd.sgi.com>
- NNTP-Posting-Host: winchester.mips.com
-
- In article <onughl0@zuni.esd.sgi.com> olson@anchor.esd.sgi.com (Dave Olson) writes:
- >In <1992Aug18.072025.11920@CSD-NewsHost.Stanford.EDU> philip@ziggy.stanford.edu (Philip Machanick) writes:
- >
- >| I need to dynamically look up the page size (I know it is 4K now, but prefer
- >| not to build such assumptions in).
- >| Is this a good constant to use (i.e. supported)?
-
- >Yes, and no. r4k systems can have multiple page sizes, and one
- >of these days we will use that feature. Besides, it may not
- >be terribly portable. See 'man getpagesize'. ....
-
- To amplify this a little more, and perhaps stir up some discussion
- about what people should be doing later:
- a) As Dave says, R4000s support multiple page sizes, and you certainly
- don't want to build 4K into your programs.
- b) This means, not only might different programs have different
- sized pages ... but different parts of the same program might
- have different-sized pages ... and in fact, there are ways of
- using the R4000 TLB where the page size of a given chunk of
- virtual memory changes around during execution....
-
- Hence, this leads to the question: if you are using the result of getpagesize,
- what are you expecting it to tell you, and how are you using it?
- This might provide some guidance about what getpagesize ought to do
- in an OS that really uses multiple sizes at the same time.
- Note that getpagesize explicitly says its return is not necesarily
- the size of underlying hardware pages....
-
- In a multiple-page size environment, there are at least the following
- potential values that might make sense:
- a) 4K: the minimum possible size of allocation.
- b) 8K: 2 of those, since the R4000's TLB conveniently pairs pages,
- and there might be some advantage under some schemes in allocating 8K chunks.
- c) XK, where X is the *largest* size that the OS is willing to put in the TLB,
- i.e., so that asking for this much space could be a good hint to the OS to
- allocate this much much physical memory in one chunk and be able to map it
- with a single TLB entry.
- --
- -john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc>
- UUCP: mash@mips.com [soon to be mash@sgi.com, but not quite moved yet].
- DDD: 408-524-7015, or 524-8253
- USPS: (soon) Silicon Graphics, 2011 N. Shoreline Blvd, Mountain View, CA 94043
-