Subject: Re: mmap'ing framebuffer memory in MI drivers...
To: Jason Thorpe <thorpej@nas.nasa.gov>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
List: tech-kern
Date: 03/05/1999 16:13:01
>Well, more like devices aren't really "wired" memory.  The pmap is allowed
>to forget those mappings at any time, as it sees fit.

the _mappings_ are not wired, but we can safely assume the _pages are
wired_.


>Say, for example, a process which has mapped the frame buffers is _swapped_
>out.  The Alpha pmap will then free all of its page tables.  You need to be
>able to reestablish the mapping for individual pages later, when that process
>runs again.

Sure. Then when the process faults on the framebuffer pages, the VM
system calls the framebuffer's d_mmap entrypoint, and the framebuffer
calls our shiny "New,Improved" knob to stuff back a single "large
page" mapping the entire framebuffer.

If the "New Improved" hook allows te d_mmap to return a paddr_t with a
hint bits saying, `oh, btw, use a large page', then this Just Works--
provided all the `use large page' bits for any given mapping share
fate w.rt. being `forgotten'.

At least, itd work on a mips: i dont know about page-table-walking
TLBs where you implement `large' pages by setting a bit in an
intermediate-level pagetable to indicate that all ptes in that table
are for large pages.

Needs more thought, I guess. But the wins (in reduced TLB thrashing)
are known to be worth it.