berger@datacube.UUCP (03/06/87)
Sun tech support can't help me, maybe someone on the net can!
I want to map a very large chunk of physical memory (32 Meg of video
frame-store) into my user process's virtual address space.
We have a Sun 3/75 connected to an external VME chassis with a bus
repeater capable of repeating a full A32 / D32 bus to the external
VME chassis.
In this chassis we have a very large frame store that takes up 32 Meg
of physical memory.
We have been told that the only way to map the physical memory of the
frame-store into a user program is to first do a valloc which I
presume reserves pages in the MMU for a chunk of memory, and then an
mmap which maps the physical memory into the reserved virtual memory
chunk. This is how frame-store's are usually mapped in on the sun.
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.
They say that this will be changed in version 4.0 of Sun OS....
There must be a more sane way to tell the operating system / MMU
hardware to do an explicit mapping today! What good is having A32
VME bus addressing if you can't talk to large chunks of physical
memory? I consider this a major failing if its true that a Sun can
not do this.
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
UUCP: ihnp4!datacube!berger
{seismo,cbosgd,cuae2,mit-eddie}!mirror!datacube!bergerrbj@icst-cmr.arpa (Root Boy Jim) (03/10/87)
Sun tech support can't help me, maybe someone on the net can! Guy, what do you have to say about this and my answer? I want to map a very large chunk of physical memory (32 Meg of video frame-store) into my user process's virtual address space. We wanted to map about 12-16 Meg of dual ported memory. Sunix (what didn't you call it that instead of the boring SunOS?) doesn't know about it, but our data gathering program does. We have a Sun 3/75 connected to an external VME chassis with a bus repeater capable of repeating a full A32 / D32 bus to the external VME chassis. We have a 3/160 with the same. In this chassis we have a very large frame store that takes up 32 Meg of physical memory. We have been told that the only way to map the physical memory of the frame-store into a user program is to first do a valloc which I presume reserves pages in the MMU for a chunk of memory, and then an mmap which maps the physical memory into the reserved virtual memory chunk. This is how frame-store's are usually mapped in on the sun. This is what we did as well. 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. Hmmm. I see several problems here. First, after mmap'ing valloc'ed memory the Sunix must reclaim the memory it originally allocated. Second, if you *could* get past that stage, you might wind up arguing with the hardware. The machine either wouldn't boot or the console had numerous streaks when we attempted to use certain physical (vme32d32) addresses. See below for details. They say that this will be changed in version 4.0 of Sun OS.... Good. I see no reason to ?alloc memory in order to remap it. There must be a more sane way to tell the operating system / MMU hardware to do an explicit mapping today! What good is having A32 VME bus addressing if you can't talk to large chunks of physical memory? I consider this a major failing if its true that a Sun can not do this. You could try allocating it
lee@srs.UUCP (03/11/87)
> > 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.
shannon@sun.UUCP (03/13/87)
Note that you can only have one swap hole per process, and that it can not be expanded. Bill Shannon