Folks,
this is the intro to a small series of patches that introduce execute
in place into the I/O stack. File I/O to memory-backed block
devices is performed directly, bypassing the page cache and io
schedulers. On s390, we use this for block devices based on shared
memory between multiple virtual machines. This is also useful on
embedded systems where the block device is located on a flash chip.
This work is a result of a prior discussion with Andrew Morton
about my first implementation which basically was a filesystem
derived from ext2.
As I'd like to aim for integration into -mm and vanilla later on,
I'd like to encourage everyone to give it a read and provide
feedback. All patches apply against git-head as of today.
cheers,
Carsten
On Wed, 2005-05-11 at 16:29 +0200, Carsten Otte wrote:
> . This is also useful on embedded systems where the block device is
> located on a flash chip.
On Wed, 2005-05-11 at 17:33 +0200, Carsten Otte wrote:
> Indeed that seems reasonable. There is no exact reason to have
> this built into a kernel on a platform that does not have a bdev
> for this.
The sanest way to use flash chips is not to pretend that they're a block
device at all; rather to use a file system directly on top of them.
But although you _talk_ about block devices, your code does look like it
should be usable even by flash file systems. I'll try to come up with a
test case using it on flash.
--
dwmw2
David Woodhouse wrote:
>On Wed, 2005-05-11 at 16:29 +0200, Carsten Otte wrote:
>
>
>>. This is also useful on embedded systems where the block device is
>>located on a flash chip.
>>
>>
>
>On Wed, 2005-05-11 at 17:33 +0200, Carsten Otte wrote:
>
>
>>Indeed that seems reasonable. There is no exact reason to have
>>this built into a kernel on a platform that does not have a bdev
>>for this.
>>
>>
>
>The sanest way to use flash chips is not to pretend that they're a block
>device at all; rather to use a file system directly on top of them.
>
>But although you _talk_ about block devices, your code does look like it
>should be usable even by flash file systems. I'll try to come up with a
>test case using it on flash.
>
>
>
Yes and no. For execute in place to work proper, you need an
allignment of data to page boundaries "on disk" (or on flash)
just like you have when mmap()ing to userland.
Before choosing second extended, I also looked at some
flash/rom filesystems. But I was unable to identify one that
alligns the data proper (and does not compress things or
such). The ext family with block size == PAGE_SIZE does
fullfill that requirement once the "block device" starts on page
boundary.
On the other hand I believe that a filesystem specificaly
designed for flash can provide less metadata overhead then
second extended. Would also be interresting in our use-case
on s390.
On Wed, 11 May 2005 18:35:28 +0200, Carsten Otte wrote:
> >
> Yes and no. For execute in place to work proper, you need an
> allignment of data to page boundaries "on disk" (or on flash)
> just like you have when mmap()ing to userland.
> Before choosing second extended, I also looked at some
> flash/rom filesystems. But I was unable to identify one that
> alligns the data proper (and does not compress things or
> such). The ext family with block size == PAGE_SIZE does
> fullfill that requirement once the "block device" starts on page
> boundary.
> On the other hand I believe that a filesystem specificaly
> designed for flash can provide less metadata overhead then
> second extended. Would also be interresting in our use-case
> on s390.
In principle, both the block device abstraction and the mtd
abstraction fit your bill. But jffs2 doesn't, so no in-kernel fs
could make use of a xip-aware mtd abstraction.
Patching jffs2 for xip looks like a major effort, at best, and utterly
insane at worst. I'd prefer not to go down that path.
J?rn
--
Optimizations always bust things, because all optimizations are, in
the long haul, a form of cheating, and cheaters eventually get caught.
-- Larry Wall
J?rn Engel wrote:
> In principle, both the block device abstraction and the mtd
>
>abstraction fit your bill. But jffs2 doesn't, so no in-kernel fs
>could make use of a xip-aware mtd abstraction.
>
>
True. In fact I thought about an mtd device driver for our dcss
segments instead of a block device driver. A filesystem on top
of mtd that implements get_xip_page does the very same job.
But after I decided to build on the ext family, I discarded that
idea because ext does use the block device interface.
On Thu, 2005-05-12 at 10:57 +0200, Jörn Engel wrote:
> In principle, both the block device abstraction and the mtd
> abstraction fit your bill. But jffs2 doesn't, so no in-kernel fs
> could make use of a xip-aware mtd abstraction.
>
> Patching jffs2 for xip looks like a major effort, at best, and utterly
> insane at worst. I'd prefer not to go down that path.
You and me both. The time has definitely come to recognise that JFFS2
needs replacing ;)
--
dwmw2