Re: mmap() versus read()

Kenneth Albanowski (kjahds@kjahds.com)
Wed, 18 Mar 1998 10:29:49 -0500 (EST)


On Wed, 11 Mar 1998, Benjamin C.R. LaHaise wrote:

> On Wed, 11 Mar 1998, Michael Lausch wrote:
> ....
> > But the problem is when you are using Linux on embedded systems
> > without any swap (disk) at all. The programs are stored in the FLASH
> > RAM so the cost of reading a page from the executable is almost zero,
> > but using a swap area is impossible (no, we don't have 20 Meg RAM for
> > a RAM swap disk)
>
> Is this paged flash or memory mapped flash? Ideally an embedded system
> would use memory-mapped flash with a filesystem like romfs (? - does it do
> this?) that would provide it's own mmap that just maps in the page, still
> in flash, into the process on nopage. This way your executables take up
> practically no ram under normal circumstances.

Our current work has no mapping facilities of any particular use: we've
just added a callbacks to the file_ops to allow memory based block devices
and contiguous memory based filesystems (like romfs) to bypass the buffer
cache. An mmap of a file in flash does _nothing_ other then return a
pointer to the file. This is not copy-on-write, but as long as the code is
location-independant (or located), you can allocate data+bss+stack
separately, and execute the code in place.

Likewise, the block system shortcuts the buffer cache, so that reads from
the romfs are read directly from memory to the final buffer.

This all adds up to no memory overhead for executing code and using data
in ROM, though it would be counter-productive on a system with slow ROM.

The patches for this (tentatively called MAGIC_ROM_PTR) are currently part
of uClinux, but probably could be adapted to full MMU-Linux, with a little
bit of work.

> Something I didn't mention about the swap-caching of executables and such:
> it would only be enabled via a mount option, or the traditional sticky
> bit, so it shouldn't impact embedded systems.

In this context, swap never comes into it, as the ROM/flash data is never
in a position to be swapped out.

-- 
Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu