[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Introducing non-RAM managed page ("device page")
On Tue, 15 Sep 2009, Masao Uebayashi wrote:
> There are cases where we need to manage addresses of non-RAM devices by MMU.
> One example is XIP, which makes kernel able to execute programs directly from
> memory-mapped NOR FlashROM instead of copying file into RAM. Others are newer
> video devices (which I'm not familar with).
> UVM allocates a managed page's state (struct vm_page) for each page-sized RAM,
> because its main purpose is "page cache" - cache of on-disk page-sized data.
> OTOH, "device pages" is always volatile. They're not cache.
I'm curious why you want to get the VM subsystem involved in this process.
The VM subsystem manages the virtualization of main memory, hence the
name. It manages the relationship between non-volatile memory (disk) and
its temporary cache (RAM). If you're not backing those non-RAM pages with
disk then the VM system does not seem to be the appropriate place to do
We've handled mmap()ing device memory forever without getting VM involved.
Not to imply that the current device mmap() interface could not be
improved. What features of the VM subsystem do you think is needed to map
device pages into processes?
Main Index |
Thread Index |