|
|
Subscribe / Log in / New account

Execute-in-place

Execute-in-place (XIP) support for the Linux kernel has been on the embedded systems wishlist for some time. Such systems usually have the kernel and relevant application images stored in a directly-accessible ROM or flash memory. This memory generally contains a filesystem, and is treated as a disk drive. This mechanism works, but it can be inefficient: running a program from this memory requires that said program first be copied into (usually scarce) RAM. It would be much better if this code could be executed directly out of the flash-based memory.

Carsten Otte (of IBM) has posted a set of patches adding XIP support to the 2.6 kernel. These patches, in addition, enable fast memory-to-memory block I/O for such devices, shorting out the page cache and most of the block layer. As a result, the XIP patches are useful in a number of situations, such as, as Carsten notes, for shared-memory block devices used to communicate between (virtual) systems.

The first step is to add support at the block driver level. To that end, a new method is added to the block_device_operations structure:

    int (*direct_access) (struct inode *inode, sector_t sector, 
                          unsigned long *data);

This method, if implemented, should come up with a kernel virtual address corresponding to the given sector on the block device represented by inode. That address, which must remain valid until the device is closed, is returned in *data. The return value is zero on success or a negative error code in case of problems.

The next step is a new method in the address_space_operations structure:

    struct page *(*get_xip_page)(struct address_space *space, 
                                 sector_t blockno, int create);

This method's job is to translate a specific block number within a filesystem to a page structure pointing to its directly-mapped data. It is a filesystem-specific function which will translate blockno to a sector number on the underlying device, then use that device's direct_access() method to get an address. Carsten has posted an implementation for ext2 which shows how this method can be put together.

So far, the XIP patches enable fast, memory-to-memory device access, but they do not yet implement true execute-in-place operation. The last step is to replace the usual nopage() VMA operation (filemap_nopage()) with a new version (filemap_xip_nopage()) when the underlying device and filesystem support XIP. The new nopage() method will (using get_xip_page()) handle page faults by causing a process's page tables to point directly to the on-"disk" pages, rather than reading those pages into RAM. Some other technique will be needed to run the kernel itself in an XIP mode, but anything that is invoked thereafter can be run directly from the memory device.

Put the above pieces together, and Linux has a complete execute-in-place implementation. Supporting XIP at the block level is not the only way it could be implemented; David Woodhouse pointed out that an alternative approach is to use a special-purpose filesystem. Carsten's patches, however, point out a way in which any filesystem could be made to work in an XIP mode.

Index entries for this article
KernelBlock layer
KernelExecute in place


to post comments

Execute-in-place

Posted May 12, 2005 10:33 UTC (Thu) by cotte (subscriber, #7812) [Link] (3 responses)

>So far, the XIP patches enable fast, memory-to-memory device access,
>but they do not yet implement true execute-in-place operation.
That is not true. In fact the filemap_xip_nopage function for xip in mm/filemap.c directly maps on-disk content into userspace - that's exactly what execute in place is.

Execute-in-place

Posted May 12, 2005 11:06 UTC (Thu) by cotte (subscriber, #7812) [Link] (2 responses)

...maybe I should read the article to the end before complaining ;)

Execute-in-place

Posted Apr 26, 2006 11:13 UTC (Wed) by tohoyn (guest, #37363) [Link] (1 responses)

Where is this filemap_xip_nopage? I can't find it in the patch.

Execute-in-place

Posted Apr 26, 2006 11:40 UTC (Wed) by tohoyn (guest, #37363) [Link]

I found all the patches with "Search".

Execute-in-place

Posted May 12, 2005 13:58 UTC (Thu) by karim (subscriber, #114) [Link] (5 responses)

It would be important to highlight that there isn't concensus on the availability/use of XIP within the embedded Linux community. David Woodhouse who maintains the MTD layer, for example, has said a number of times that the only ones who profit from XIP are flash manufacturers. The truth of the matter is that flash costs more than RAM and having XIP means having the binaries uncompressed in flash. The more XIP you have, the larger the flash you need. From that point of view, it's clear that having the classic compressed FS in flash and the apps running in RAM is usually the best way to go. ... not that this fact is going to stop developers from asking for this feature ...

There may be an advantage for XIP in the case of mass-produced masked-ROMs, maybe, but that probably benefits to a handfull of companies on this planet only ...

Execute-in-place

Posted May 12, 2005 19:19 UTC (Thu) by oak (guest, #2786) [Link] (1 responses)

But doesn't RAM need refresh whereas Flash doesn't?
I.e. XIP with less RAM might make your battery last longer...

Execute-in-place

Posted May 13, 2005 6:26 UTC (Fri) by phiggins (subscriber, #5605) [Link]

Depends on the type of RAM. XIP would save a lot of power if you use DRAM, but not so much with SRAM and the Magnetic RAM. I think those cost more than flash right now, though.

Execute-in-place

Posted May 15, 2005 19:57 UTC (Sun) by obobo (guest, #684) [Link]

It is typical for microcontrollers with on-die flash and RAM to have significantly more flash than RAM. Granted that today, most of these microcontrollers don't have enough memory to run Linux with or without XIP, but bigger chips will come through at some point.

Interesting point, though.

Execute-in-place

Posted May 21, 2005 20:17 UTC (Sat) by dmag (guest, #17775) [Link] (1 responses)

There is also a latency issue. XIP will boot faster. It will also run faster in the case where you have more flash than RAM.

Execute-in-place

Posted Sep 1, 2005 14:46 UTC (Thu) by jg (guest, #17537) [Link]

I see assertions, with no data, I think often by people with no experience in the area.

Certainly on the iPAQ we've lived fine without XIP, and flash is more precious that RAM. And the paging system does very well at throwing away unused pages of text that have been pulled into RAM.

So I think we need data here, rather than proof by loud assertion...
- Jim


Copyright © 2005, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds