Subject: Re: mmap'ing framebuffer memory in MI drivers...
To: Jason Thorpe <firstname.lastname@example.org>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
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
>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
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.