All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marco Stornelli <marco.stornelli@gmail.com>
To: "Luck, Tony" <tony.luck@intel.com>
Cc: Pavel Machek <pavel@ucw.cz>,
	Linux Kernel <linux-kernel@vger.kernel.org>,
	Linux Embedded <linux-embedded@vger.kernel.org>,
	Linux FS Devel <linux-fsdevel@vger.kernel.org>,
	Tim Bird <tim.bird@am.sony.com>
Subject: Re: [PATCH 01/17] pramfs: documentation
Date: Mon, 10 Jan 2011 19:17:33 +0100	[thread overview]
Message-ID: <4D2B4D3D.2030903@gmail.com> (raw)
In-Reply-To: <987664A83D2D224EAE907B061CE93D5301940801B2@orsmsx505.amr.corp.intel.com>

Il 10/01/2011 18:35, Luck, Tony ha scritto:
>> You'd be better running ext2 over special block device,
>> it is quite simple.
> 
> Marco,
> 
> You might want to spend some more time answering this question
> (it is a particularly good one).  What are the reasons to use
> pramfs, rather than a ext2 over a mem<->block driver.  You covered
> some in your part 0 patch (like ext2 wastes time getting optimal
> block placement for rotating media). But it might be a good idea
> to go back over them here.  From my (lightweight) reading of your
> code, it looks like the biggest benefit is avoiding duplicating
> the data in the pramfs memory region and the VM page cache ...
> which is a big deal for your target audience of hand held devices
> where memory is a somewhat scarce resource. But you probably
> have other goodness in there too.
> 
> -Tony
> 

I can add that you can "place" the fs wherever you want, ext2 not
without to build something "special" as Pavel said. Sincerely I don't
know what other add. I think documentation, web site information and
benchmark say all. You have got a fs that it's simple, it doesn't
consume a lot of resources (you can do a fine tuning via N and bpi
options for the metadata space for example), better in performance in
this "environment", with the memory protection feature when
available....other? I could write a piece of code that it turn on your
coffee machine at morning, what do you think? :)

Marco

  reply	other threads:[~2011-01-10 18:17 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-06 12:01 [PATCH 01/17] pramfs: documentation Marco Stornelli
2011-01-07 18:42 ` Tony Luck
2011-01-07 20:30   ` Marco Stornelli
2011-01-07 21:59     ` Tony Luck
2011-01-08  8:16       ` Marco Stornelli
2011-01-10  8:08         ` Pavel Machek
2011-01-10  8:14           ` Marco Stornelli
2011-01-10  8:14             ` Marco Stornelli
2011-01-10 17:35           ` Luck, Tony
2011-01-10 18:17             ` Marco Stornelli [this message]
2011-01-11 15:42         ` Roberto A. Foglietta
  -- strict thread matches above, loose matches on Subject: below --
2012-06-10  9:13 Marco Stornelli

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4D2B4D3D.2030903@gmail.com \
    --to=marco.stornelli@gmail.com \
    --cc=linux-embedded@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pavel@ucw.cz \
    --cc=tim.bird@am.sony.com \
    --cc=tony.luck@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.