All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hans Reiser <reiser@namesys.com>
To: Jens Axboe <axboe@suse.de>
Cc: Edward Shishkin <edward@namesys.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Reiserfs mail-list <Reiserfs-List@namesys.com>
Subject: Re: random minor benchmark: Re: Copy 20 tarfiles: ext2 vs (reiser4, unixfile) vs (reiser4,cryptcompress)
Date: Thu, 26 Jan 2006 23:30:57 -0800	[thread overview]
Message-ID: <43D9CC31.9030209@namesys.com> (raw)
In-Reply-To: <20060126153343.GH4311@suse.de>

Jens Axboe wrote:

>On Wed, Jan 25 2006, Hans Reiser wrote:
>  
>
>>Notice how CPU speed (and number of cpus) completely determines
>>compression performance.
>>
>>cryptcompress refers to the reiser4 compression plugin, (unix file)
>>refers to the reiser4 non-compressing plugin.
>>
>>Edward Shishkin wrote:
>>
>>    
>>
>>>Here are the tests that vs asked for:
>>>Creation (dd) of 20 tarfiles (the original 200M file is in ramfs)
>>>Kernel: 2.6.15-mm4 + current git snapshot of reiser4
>>>
>>>------------------------------------------
>>>
>>>Laputa workstation
>>>Uni Intel Pentium 4 (2.26 GHz) 512M RAM
>>>
>>>ext2:
>>>real 2m, 15s
>>>sys 0m, 14s
>>>
>>>reiser4(unix file)
>>>real 2m, 7s
>>>sys  0m, 23s
>>>
>>>reiser4(cryptcompress, lzo1, 64K)
>>>real 2m, 13s
>>>sys 0m, 11s
>>>      
>>>
>
>Just curious - does your crypt plugin reside in user space?
>
>  
>
No, kernel.  It would have to  encrypt+compress with every write to be
in user space, we encrypt+compress only at flush time, and that is a key
optimization (encryption is disabled at the moment due to needing a
little API work, but....) for file sets that are cachable.

  parent reply	other threads:[~2006-01-27  7:30 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <43D7C6BE.1010804@namesys.com>
2006-01-25 18:59 ` random minor benchmark: Re: Copy 20 tarfiles: ext2 vs (reiser4, unixfile) vs (reiser4,cryptcompress) Hans Reiser
2006-01-26 15:33   ` Jens Axboe
2006-01-26 18:17     ` Edward Shishkin
2006-01-26 18:56       ` Jens Axboe
2006-01-26 20:41         ` Edward Shishkin
2006-01-27  7:43           ` Hans Reiser
2006-01-27  8:09             ` Jens Axboe
2006-01-27  8:06           ` Jens Axboe
2006-01-27  8:14             ` Hans Reiser
2006-01-27  8:21               ` Jens Axboe
2006-01-27  8:41                 ` Hans Reiser
2006-01-28 16:53         ` Alexander Zarochentsev
2006-01-27  7:30     ` Hans Reiser [this message]
2006-01-26 17:46   ` Danny Milosavljevic
2006-01-26 18:41     ` Edward Shishkin
2006-02-17 19:12       ` Danny Milosavljevic
2006-02-20 13:11         ` Clemens Eisserer
2006-02-20 17:09           ` Hans Reiser

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=43D9CC31.9030209@namesys.com \
    --to=reiser@namesys.com \
    --cc=Reiserfs-List@namesys.com \
    --cc=axboe@suse.de \
    --cc=edward@namesys.com \
    --cc=linux-kernel@vger.kernel.org \
    /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.