Re: ¡@[*©U§£¶l¥ó*] Re: What File System supports Application XIP

From: colin (colin_at_realtek.com.tw)
Date: 09/09/04

  • Next message: Rafael J. Wysocki: "Re: swsusp on x86-64 w/ nforce3"
    To: "Paulo Marques" <pmarques@grupopie.com>
    Date:	Thu, 9 Sep 2004 17:58:44 +0800
    
    

    Hi Paulo,
    Cramfs seems to support it now.
    At the beginning, I also think it's impossible to support Application XIP in
    Cramfs.
    http://www.denx.de/twiki/publish/DULG/ConfigureLinuxForXIP.html

    Regards,
    Colin

    ----- Original Message -----
    From: "Paulo Marques" <pmarques@grupopie.com>
    To: "colin" <colin@realtek.com.tw>
    Cc: <linux-kernel@vger.kernel.org>
    Sent: Thursday, September 09, 2004 5:19 PM
    Subject: ¡@[*©U§£¶l¥ó*] Re: What File System supports Application XIP

    > colin wrote:
    > >
    > > Hi there,
    > > We are developing embedded Linux system. Performance is our
    consideration.
    > > We hope some applications can run as fast as possible,
    > > and are think if they can be put in a filesystem image, which resides in
    > > RAM, and run in XIP (eXecute In Place) manners.
    > > I know that Cramfs has supported Application XIP. Is there any other FS
    that
    > > also supports it? Ramdisk? Ramfs? Romfs?
    >
    > Obvisously cramfs can not support XIP, because the "in-place" image
    > is compressed (unless you have a processor that can execute compressed
    > code :)
    >
    > AFAIK only tmpfs supports XIP because it works on a higher level
    > without using block devices underneath. Ramdisks are simply RAM
    > block devices that behave like any other block device.
    >
    > You can have a compressed image in flash (for instance), decompress
    > everything into a tmpfs and execute from there.
    >
    > I'm not sure, however, that this will be such a performance gain.
    >
    > If you use cramfs (for instance) then the kernel will uncompress
    > and run only the pages that are needed, and they will be cached in
    > page cache so that they will be available again when needed. This
    > way you only waste the RAM you actually need, and can still drop
    > old pages if the application needs more RAM.
    >
    > Just my two cents,
    >
    > --
    > Paulo Marques - www.grupopie.com
    >
    > To err is human, but to really foul things up requires a computer.
    > Farmers' Almanac, 1978
    >

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/


  • Next message: Rafael J. Wysocki: "Re: swsusp on x86-64 w/ nforce3"

    Relevant Pages

    • Re: What File System supports Application XIP
      ... > I know that Cramfs has supported Application XIP. ... Obvisously cramfs can not support XIP, ... Ramdisks are simply RAM ... block devices that behave like any other block device. ...
      (Linux-Kernel)
    • Re: [PATCH 2.6.21] cramfs: add cramfs Linear XIP
      ... So now we leverage this filemap_xip.c in cramfs. ... This is the highlevel way to go, just please don't hack it into ... remove all the support for block devices. ... rip out the mutex serializing all reads and clean up the way xip ...
      (Linux-Kernel)
    • Re: [PATCH 2.6.21] cramfs: add cramfs Linear XIP
      ... lines that cramfs has in total. ... to the XIP changes, which I want on block devices anyway. ... So if we did fork cramfs I would submit a simple patch to cramfs for ... filesystem, cramfs-linear. ...
      (Linux-Kernel)
    • Re: [PATCH 2.6.21] cramfs: add cramfs Linear XIP
      ... Please don't add this xip support to cramfs, ... use something like the existing ext2 xip mode instead of add support ... Look at the xip extensions for ext2 for example, they don't bloat the filesystem too much. ...
      (Linux-Kernel)
    • Re: Initrd - cramfs image is not being recognized by 2.4.20 kernel
      ... My support of cramfs was complied into the kernel, ... Now I have redone the initrd image as an uncompressed ...
      (Debian-User)