Subject: Re: sysctl HW_PAGESIZE
To: Alfred Perlstein <bright@mu.org>
From: Nathan J. Williams <nathanw@wasabisystems.com>
List: tech-perform
Date: 02/23/2002 17:59:05
> * Emmanuel Dreyfus <manu@netbsd.org> [020223 11:39] wrote:

> > Theses debug printf's show me that on each process launch, we do a
> > sysctl HW_PAGESIZE to discover the hardware page size. This is spends a
> > system call for each program startup to discover something that seems to
> > be a hardware constant.

FTR, the sysconf is being done by malloc()'s initialization code in
libc (see src/lib/libc/stdlib/malloc.c, line 421). I'd be more
interested in knowing if hardcoding it made malloc() any faster.

> > Maybe this is a stupid question, but... the page size is CPU related,
> > right? Is it true that a binary build for a given CPU will always see
> > the same page size? If it is, then we could get the page size at build
> > time instead of at run time.
> 
> Afaik several arches allow for variable page sizes, not just 4k vs 4meg
> pages either, something like 4, 8 and 16k pages I've _heard_ for ia64,

Oh, it's much worse than that. The Byzantine ia64 MMU permits page
sizes of 4k, 8k, 16k, 64k, 256k, 1M, 4M, 16M, 64M, and 256M pages (It
wouldn't seem so weird if 8k were left out of that list....).

Plenty of other architectures have a handful of different pagesizes,
but I think ia64 is nearly the worst. 

> it's possible that a system administrator (if the OS allowed it) would
> want larger pages on large memory machines or smaller pages on small
> memory machines, therefore doing at compile time isn't a really good
> idea.

More likely, I think, would be a situation where several different
binary-compatible CPUs have different fixed pagesizes... although that
has problems with things like program section alignment, which is
usually based on page size.

Ultimately, though, a single (cheap) syscall is going to be
lost in the noise of process startup; it's probably not worth fussing
over.

        - Nathan