Slashdot Mirror
XiP Filesystem Primps For Linux 2.6.28
nerdyH writes "The Linux-Embedded discussion list has been abuzz the last two days over a flash filesystem designed to support binary code execution (sometimes called XIP, or "execute-in-place"). When combined with forthcoming "Phase Change Memory" products from Intel/ST JV Numonyx, the "Advanced XiP Filesystem" (AXFS) could radically change Linux systems of all kinds, replacing Flash, hard drives, and even DRAM with a single chunk of low-cost, non-volatile memory that can both store files and serve as a platform for program execution."
This filesystem is meant for embedded devices with Flash storage that presents itself as a portion of physical memory - essentially, it helps the kernel avoid the overhead of copying from Flash to RAM when you can just run it out of Flash.
XiP has been supported in other filesystems, this is more like a small improvement - nothing to get excited about. Moreover, you won't see it in use in any desktops - this filesystem is read-only; more like an archive format understood by the kernel.
More useful discussion can be found at kerneltrap.
I think that the concept is that you have a processor with a boat-load of some type of RAM-look-alike (presumably non-volatile). This RAM is used as a RAM-drive (well, if the RAM is non-volatile, then you loose no data). Imagine a linux-based PDA that does not have the usual RAM/FLASH combination, but instead has a few gig of RAM that keeps its memory when powered off. So, you use the same memory for both "main memory" applications (loading programs, stack, heap, etc.) and also holds a file system.
So, you run your favorite application, which gets loaded into main memory from the file system.
Wait... your file system is also main memory. So, your favorite application is now in memory twice -- once in the file system, and once in "main" executable memory. That seems like a waste. This project aims to use the "file system copy" as the executable. Pretty smart, but possibly difficult to get right.
"-1 Troll" is the apparently the same as "-1 I disagree with you."
The idea is for embedded systems that don't have a hard drive. Right now, at least with a normal file system, you have to take the data from flash and copy it into RAM. Even if the flash is mapped into memory, you still have to do this.
Execute in Place means letting the processor read the code directly from the flash (when available) so you don't have to make the (rather pointless) copy in RAM. It obviously wouldn't work in some circumstances (self-modifying code being the obvious one) but it would save embedded system guys on RAM requirements.
Some things already support execute in place. The article says that CramFS supports a version, but it seems as if this version may be able to work on smaller chunks of memory (a page) at a time than the CramFS version (which seems to only work on a full file at a time?).
Of course, all this only works well if your flash is fast enough at reading. If it is relatively fast (compared to your CPU) so you're only waiting a few cycles (perhaps a small overhead compared to RAM) it would be useful. If it was very slow to read (100s more cycles than normal memory) it wouldn't do you much good.
I hope LWN writes an article about this. I'd love to know more.
Comment forecast: Bits of genius surrounded by a sea of mediocrity.
The idea of XiP is that if you have a piece of storage that's directly accessible as memory to the CPU (e.g. a piece of old-school ROM, NOR-flash, battery-backed RAM, or phase-change memory), the CPU can just execute a program directly from there instead of first copying it to RAM and executing it there. Storing programs in this memory so they can be executed is something that normal filesystems can't do per default, and that's why this is something interesting: You'll still need RAM for the data parts of the program, but the programs and libraries themselves can remain on disk without taking up precious RAM.
The flash medium must be memory mapped for this to work. This means that nand flash is out without sitting behind some other logic to bridge the nand controller to the memory bus. Nand flash won't lend itself too well to this sort of behavior, though, since when code 'jumps' outside a page boundary there will be a bus stall until the next page gets read. Also, 'real programmers' modify the code during execution :P
Slashdot: Where people pretend to be twice as smart as they really are by behaving like children.
AXFS is read-only. The usage case tends to go as follows:
- Build a compressed filesystem
- Run a test case, interacting with the filesystem to generate page hits on your binaries.
- Take the profile the filesystem generates and rebuild the filesystem.
Precisely. CramFS works by setting the entirety of a file XIP if its sticky bit is set. AXFS runs based off a profile generated by the kernel when page faults are caused. Individual pages are then left uncompressed and executed directly from flash.
It's block rather than record oriented, but this seems similar to how classic Palm OS worked. In the Handspring Visor, which had directly addressable flash memory, this was used to execute code directly out of flash.