Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!seismo!rochester!ur-tut!ur-cvsvax!srs!lee
From: lee@srs.UUCP
Newsgroups: comp.unix.wizards
Subject: Re: Very Large Framestores on Sun: addr
Message-ID: <137@srs.UUCP>
Date: Wed, 11-Mar-87 11:18:20 EST
Article-I.D.: srs.137
Posted: Wed Mar 11 11:18:20 1987
Date-Received: Fri, 13-Mar-87 04:41:58 EST
References: <106600006@datacube>
Organization: S.R. Systems, Rochester NY
Lines: 38

> 
> The  problem  is  that  the valloc  actually allocates  the amount of
> memory you are requesting.  If you don't have enough swap space free,
> the valloc fails.  Thus not allowing you to get  a chance  to map the
> physical to virtual address.  
> 
> 				Bob Berger 
> 
> Datacube Inc. Systems / Software Group	4 Dearborn Rd. Peabody, Ma 01960
> VOICE:	617-535-6644;	FAX: (617) 535-5643;  TWX: (710) 347-0125

This may be of general interest, so I am posting it to the net.

Essentially all that valloc() does is this:

char *
valloc(size)
unsigned size;
{
    int pagesize;
    char *p = malloc(size + (pagesize = getpagesize()));

    while ((int)(p) % pagesize != 0)
	p++;

    return(p);
}

This means that it malloc's page aligned areas of memory, so that a subsequent
call to mmap() can remap these pages to different physical addresses.  Since
malloc() calles sbrk() and the kernel calls swapexpand() in the code which
handles sbrk(), Sun claims that you need the space on your swap device which
is as big as the area that you are going to map.  HOWEVER, the code for mmap
ACTUALLY FREES THE SWAP AREA of the pages which get mapped, so that if you
map your frame buffer a megabyte at a time, for example, you would only need
one meg of free swap area to work with.  You shouldn't use valloc to do this,
however, if you want the areas to be contiguous in the virtual address space
of your process.  Instead, you should call sbrk() yourself.