All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marco Stornelli <marco.stornelli@gmail.com>
To: Pavel Machek <pavel@ucw.cz>
Cc: tim.bird@am.sony.com, 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: Sun, 28 Jun 2009 19:33:02 +0200	[thread overview]
Message-ID: <4A47A94E.4020808@gmail.com> (raw)
In-Reply-To: <20090628085932.GA20169@elf.ucw.cz>

Pavel Machek wrote:
>>>>> Ah now the write protection is a "needed feature", in your previous
>>>>> comment you talked about why not use ext2/3.......
>>>>>
>>>>> Marco
>>>>>
>>>> Just for your information I tried the same test with pc in a virtual machine with 32MB of RAM:
>>>>
>>>> Version 1.03e       ------Sequential Output------ --Sequential Input- --Random-
>>>>                     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
>>>> Machine   Size:chnk K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
>>>> hostname     15M:1k 14156  99 128779 100 92240 100 11669 100 166242  99 80058  82
>>>>                     ------Sequential Create------ --------Random Create--------
>>>>                     -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
>>>>               files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
>>>>                   4  2842  99 133506 104 45088 101  2787  99 79581 101 58212 102
>>>>
>>>> These data are the proof of the importance of the environment, workload and so on when we talk
>>>> about benchmark. Your consideration are really superficial.
>>> Unfortunately, your numbers are meaningless.
>> I don't think so.
>>
>>> (PCs should have cca 3GB/sec RAM transfer rates; and you demosstrated
>>> cca 166MB/sec read rate; disk is 80MB/sec, so that's too slow. If you
>>> want to prove your filesystem the filesystem is reasonably fast,
>>> compare it with ext2 on ramdisk.)
>>>
>> This is the point. I don't want compare it with ext2 from performance
>> point of view. This comparison makes no sense for me. I've done this
>> test to prove that if you change environment you can change in a
>> purposeful way the results.
> 
> Yes, IOW you demonstrated that the numbers are machine-dependend and
> really meaningless.
> 
> ext2 comparison would tell you how much pramfs sucks (or not).
> 									Pavel

Here the test with ext2 (same environment):

Version 1.03e       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine   Size:chnk K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
hostname     15M:1k 10262  83 40847  82 38574  82  9866  92 62252  98 25204  81
                    ------Sequential Create------ --------Random Create--------
                    -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                  1 19859  98 44804  61 68830 100 13566  99 157129 100 30431  98

Marco

  parent reply	other threads:[~2009-06-28 17:33 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <4a4254e2.09c5660a.109d.46f8@mx.google.com>
2009-06-24 16:49 ` [PATCH 00/14] Pramfs: Persistent and protected ram filesystem Marco
2009-06-24 17:38   ` Marco
2009-06-24 17:59     ` Pavel Machek
2009-06-25  6:30       ` Marco Stornelli
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 [this message]
2009-07-09 23:42             ` Pavel Machek
2009-06-24 17:46   ` Pavel Machek
2009-06-13 13:20 Marco
2009-06-13 13:41 ` Daniel Walker
2009-06-13 15:59 ` Jamie Lokier
2009-06-14  7:15   ` Marco
2009-06-14  7:15     ` Marco
2009-06-14 11:08     ` Artem Bityutskiy
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-25  6:44                 ` Marco Stornelli
2009-06-26 11:30                 ` Jamie Lokier
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 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
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-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

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=4A47A94E.4020808@gmail.com \
    --to=marco.stornelli@gmail.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=pavel@ucw.cz \
    --cc=tim.bird@am.sony.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.