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

Huh?

[samcan (1349105)]

Didn't read the article...

So this acts as both memory and "hard drive?"

If true, would data read times be affected at all? I mean, if the operating system is simultaneously accessing a file, and using something in memory, would there be a performance hit?

Re:

[larry bagina (561269)]

the currently executing code will be moved into the processor's cache.

Re:Huh?

[42forty-two42 (532340)]

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 [kerneltrap.org].

Re:

[harrkev (623093)]

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, yo

Re:

[Curtman (556920)]

then you loose no data

I like nice tight data myself.

Re:

[DrYak (748999)]

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.

You mean, like Palm was doing for most of it early years until recently (5.4), because some patent troll had control on PDA-using-flash and a non volatile file system ?

Yup this has already been done. The only differences are :
- The old Palm OS used read/write storage, whereas according to TFA this file system is read-only.
- The old Palm devices used plain simple DRAM, that was kept powered when the rest of the device was shut down, simply because then, there wasn't such a thing as non-volatile RAM in produc

Re:

[drinkypoo (153816)]

Windows CE stores files in RAM, too. It segregates off a portion, though. I don't know if it's auto-tuning now, but it wasn't on WM2003. It's a horrible, horrible idea though, if you don't have to do it.

Re:

[MBCook (132727)]

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 em

Re:

[Microlith (54737)]

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

aha

[extirpater (132500)]

my new choice for bootloader

So we're going back to the roots

[Fry-kun (619632)]

This upgrade brings the computer closer back to the Turing Machine :)

For people unfamiliar to XIP:

[Sprite_tm (1094071)]

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.

Re:

[stoborrobots (577882)]

The thing I'm confused about is - how is this different from MMIO? Or is the new thing that we can do MMIO for programs when they're on flash?

Must be memory mapped

[GreyWolf3000 (468618)]

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:

[drinkypoo (153816)]

It could be handy on older systems, though; My IBM PC-1 had more memory on its 8 bit ISA bus than it did on the motherboard :) Just because it's on the bus doesn't necessarily mean it's slower than "main" memory.

Classic Palm OS

[argent (18001)]

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.

Read headline slowly

[unitron (5733)]

"XiP" looks entirely too much like "XP". They should have gone with something like "XNP".

Re:

[unitron (5733)]

Well, XIP as a TLA predates XP by a *long* time.

XIP, however, is not the same as XiP, although from across the room both probably look like XP.

Interesting question....

[allaunjsilverfox2 (882195)]

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:

[kasperd (592156)]

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 whethe

Re:

[pbhj (607776)]

Yes, I'm illiterate! Netcraft confirms it.

If the parent post had just used email-case (aka lowercase) throughout I wouldn't have bothered. But it seems perverse to go the trouble of using capitals at the start of your sentences, where they are largely redundant, and then use lowercase where it changes the meaning entirely.

Oh, and could you read the above back to me because I can't ;0)>

---
Yes, I'm a fan of run-on sentences.

nothing to see here

[QX-Mat (460729)]

unless you're an embedded dev, nothing to see, move along.

the slowest part of the intel cpu cycle is decode - but before your cpu processes streams of op codes for decode you have to load the executable image into ram and then run the dynamic linker. the dynamic linker needs to parse every the segment to be worthwhile, otherwise you'll hit the linker each time you load a segment that's slightly interesting (weaker the symbols/IAT, the more likely) only to find out you didn't need to causing jitter.

its one o

Re:

[vidarh (309115)]

Thats what prelinking or position independent code is for. Modern Linux distros have supported prelinking for a long time.

This comment is not very well wrote.

[suck_burners_rice (1258684)]

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.

Re:

[norminator (784674)]

The idea is that this is the new RAM (fast and Random Access), but since it's non-volatile (and cheap?), it can also be used for file storage.