public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Tim Bird <tim.bird@am.sony.com>
To: Pavel Machek <pavel@ucw.cz>
Cc: Marco Stornelli <marco.stornelli@gmail.com>,
	Jamie Lokier <jamie@shareable.org>,
	Linux Embedded <linux-embedded@vger.kernel.org>,
	Linux Kernel <linux-kernel@vger.kernel.org>,
	Linux FS Devel <linux-fsdevel@vger.kernel.org>,
	Daniel Walker <dwalker@soe.ucsc.edu>
Subject: Re: [PATCH 00/14] Pramfs: Persistent and protected ram filesystem
Date: Mon, 22 Jun 2009 10:31:28 -0700	[thread overview]
Message-ID: <4A3FBFF0.40006@am.sony.com> (raw)
In-Reply-To: <20090622172003.GB21149@elf.ucw.cz>

Pavel Machek wrote:
>>> How do you handle hard-links, then?
>> Indeed hard-links are not supported :) Due to the design of this fs
>> there are some limitations explained in the documentation as not
>> hard-link, only private memory mapping and so on. However this
>> limitations don't limit the fs itself because you must consider the
>> special goal of this fs.
> 
> I did not see that in the changelog. If it is not general purpose
> filesystem, it is lot less interesting.

PRAMFS is not a general purpose filesystem. Please read
the introductory post to this thread, or look at
http://pramfs.sourceforge.net/ for more information.

Since the purpose of PRAMFS is to provide a filesystem
that is persistent across kernel instantions, it is not
designed for high speed.  Robustness in the face of
kernel crashes or bugs is the highest priority, so
PRAMFS has significant overhead to make the window
of writability to the filesystem RAM as small as possible.

This is not a file system one would do kernel compiles on.
This is where someone would keep a small amount of sensitive
data, or crash logs that one needed to preserve over kernel
invocations.

> 
>>>> >From performance point of view:
>>>>
>>>> Sometimes ago I uploaded here (http://elinux.org/Pram_Fs) some benchmark
>>>> results to compare the performance with and without XIP in a real
>>>> embedded environment with bonnie++. You could use it as reference point.
>>> Well, so XIP helps. ext2 can do XIP too, IIRC. Is your performance
>>> better than ext2?
>>>
>>> Wait... those numbers you pointed me... claim to be as slow as
>>> 13MB/sec. That's very very bad. My harddrive is faster than that.
>> As I said I did the test in a real embedded environment so to have
>> comparable result you should use the same environmente with the same
>> tools, with the same workload and so on.
> 
> Even on real embedded hardware you should get better than 13MB/sec
> writing to _RAM_. I guess something is seriously wrong with pramfs.

See above.

=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Corporation of America
=============================


  reply	other threads:[~2009-06-22 17:32 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-13 13:20 [PATCH 00/14] Pramfs: Persistent and protected ram filesystem Marco
2009-06-13 13:41 ` Daniel Walker
2009-06-13 15:59 ` Jamie Lokier
2009-06-14  7:15   ` Marco
2009-06-14 11:08     ` Artem Bityutskiy
2009-06-15 15:51       ` Bryan Henderson
2009-06-15 17:42         ` Marco
2009-06-14 11:46     ` Jamie Lokier
2009-06-14 16:04       ` Marco
2009-06-16 15:07         ` Jamie Lokier
2009-06-16 19:15           ` Marco
2009-06-24 17:41             ` Jamie Lokier
2009-06-25  6:44               ` Marco Stornelli
2009-06-26 11:30                 ` Jamie Lokier
2009-06-26 16:56                   ` Marco
2009-06-24 14:21                     ` Pavel Machek
2009-06-21  6:40     ` Pavel Machek
2009-06-21 17:34       ` Marco
2009-06-21 20:52         ` Pavel Machek
2009-06-22  6:33           ` Marco Stornelli
2009-06-22 17:20             ` Pavel Machek
2009-06-22 17:31               ` Tim Bird [this message]
2009-06-22 17:37                 ` Pavel Machek
2009-06-22 18:07                   ` Marco
2009-06-22 20:40                     ` Henrique de Moraes Holschuh
2009-06-22 20:40                     ` Pavel Machek
2009-06-22 21:50                       ` Tim Bird
2009-06-22 21:57                         ` Pavel Machek
2009-06-22 22:38                           ` Pavel Machek
2009-06-22 23:26                             ` Chris Friesen
2009-06-23  1:42                               ` David VomLehn
2009-06-23 18:07                           ` Marco
2009-06-23 18:29                             ` Pavel Machek
2009-06-24 17:47                               ` Jamie Lokier
2009-06-25  6:32                                 ` Marco Stornelli
2009-06-22 18:55                   ` Tim Bird
2009-06-22 21:02                     ` Pavel Machek
2009-06-22 22:02                       ` Tim Bird
2009-06-22 18:08                 ` Marco
2009-06-15 17:15 ` Tim Bird
2009-06-15 17:44   ` Marco
2009-06-15 17:58     ` Tim Bird
2009-06-17 18:32 ` Chris Friesen
2009-06-18  6:35   ` Marco Stornelli
     [not found] <4a4254e2.09c5660a.109d.46f8@mx.google.com>
2009-06-24 16:49 ` Marco
2009-06-24 17:38   ` Marco
2009-06-24 17:59     ` Pavel Machek
2009-06-25  6:30       ` Marco Stornelli
2009-06-28  8:59         ` Pavel Machek
2009-06-28 16:44           ` Marco Stornelli
2009-06-28 17:33           ` Marco Stornelli
2009-07-09 23:42             ` Pavel Machek
2009-06-24 17:46   ` Pavel Machek

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=4A3FBFF0.40006@am.sony.com \
    --to=tim.bird@am.sony.com \
    --cc=dwalker@soe.ucsc.edu \
    --cc=jamie@shareable.org \
    --cc=linux-embedded@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marco.stornelli@gmail.com \
    --cc=pavel@ucw.cz \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox