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."

Comments

Re:Huh?

[42forty-two42]

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.

Re:Huh?

[harrkev]

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.

Re:Huh?

[MBCook]

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.

For people unfamiliar to XIP:

[Sprite_tm]

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.

Must be memory mapped

[GreyWolf3000]

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

Re:Huh?

[Microlith]

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.

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?).

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.

Classic Palm OS

[argent]

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.

Interesting question....

[allaunjsilverfox2]

As processor caches increase, could you use this to run the kernel from the processor caches? Intel based processor caches will soon exceed 6mb. Just a idea.

Re:Interesting question....

[kasperd]

As processor caches increase, could you use this to run the kernel from the processor caches?

That idea doesn't really have anything to do with XiP support in the file system. You could run the kernel directly from flash as well. And since that is probably simpler, I'd be surprised if that isn't already done. As for running everything from the CPU cache, that is not controlled by the kernel but rather by the CPU itself. And it will try to use the cache for the mostly used parts of memory regardless of whether it is kernel code or not. Of course since the CPU caches are constrained by the number of gates used as well as the number of nanoseconds used to make a decision, they obviously can't always use the caches optimally, but caching all of the kernel wouldn't be optimal either, since there are some rarely used code paths in the kernel.

Re:Huh?

[Curtman]

then you loose no data

I like nice tight data myself.

This comment is not very well wrote.

[suck_burners_rice]

That would be really cool because it is currently a waste that programs need to take up twice as much "memory" as their actual size: Once for the amount it takes up on the hard drive (or flash or whatever) and once for the copy loaded into memory when you run the damn thing. It would be very, extremely cool if memory didn't wear out like flash currently does after so many writes and whatnot, and if it were plentiful and cheap, and execute-in-place and whatnot. This would actually be a bit more in line with how Joe Sixpacks view their computers. They'll have a billion gigs of free hard drive space and 640 bytes of available RAM (that's enough for anyone, isn't it?) and then a program says, "Out of memory" and they go, "Duh, what the hell? I got a billion gigs of free space!" Or another Joe Luser has a hard drive so full of pr0n that there's about three bits of available space (not even a whole byte) but he has ten gigs of RAM. So the damn thing says, "Device full" or whatever Windoze says when there ain't no more space, and he goes, "Duh, but I got ten gigs of memory!" If it were all one big huge string of memory like the way it was envisioned with Turing machines, then although computers wouldn't make one bit of sense more to these Sixpacks fellows than they do now, at least the terminology will be correct with respect to the whole memory thing.