FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Device-mapper Development

 
 
LinkBack Thread Tools
 
Old 08-04-2010, 10:25 AM
Dominik Brodowski
 
Default How to track down abysmal performance ata - raid1 - crypto - vg/lv - xfs

Hey,

many thanks for your feedback. It seems the crypto step is the culprit:

Reading 1.1 GB with dd, iflag=direct, bs=8k:

/dev/sd* 35.3 MB/s ( 90 %)
/dev/md* 39.1 MB/s (100 %)
/dev/mapper/md*_crypt 3.9 MB/s ( 10 %)
/dev/mapper/vg1-* 3.9 MB/s ( 10 %)

The "good" news: it also happens on my notebook, even though it has a
different setup (no raid, disk -> lv/vg -> crypt). On my notebook, I'm
more than happy to test out different kernel versions, patches etc.

/dev/sd* 17.7 MB/s (100 %)
/dev/mapper/vg1-* 16.2 MB/s ( 92 %)
/dev/mapper/*_crypt 3.1 MB/s ( 18 %)

On a different system, a friend of mine reported (with 2.6.33):

/dev/sd* 51.9 MB/s (100 %)
dm-crypt 32.9 MB/s ( 64 %)

This shows that the speed drop when using dmcrypt is not always a factor of
5 to 10... Btw, it occurs both with aes-lrw-benbi and aes-cbc-essiv:sha256 ,
and (on my notebook) the CPU is mostly idling or waiting.

Best,
Dominik

PS: Bonnie output:

Writing intelligently...done
Rewriting...done
Reading intelligently...done
start 'em...done...done...done...
Create files in sequential order...done.
Stat files in sequential order...done.
Delete files in sequential order...done.
Create files in random order...done.
Stat files in random order...done.
Delete files in random order...done.
Version 1.03d ------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
ABCABCABCABCABC 16G 60186 4 24796 4 53386 5 281.1 1
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 3176 16 +++++ +++ 4641 28 5501 20 +++++ +++ 2286 9
ABCABCABCABCABCABC,16G,,,60186,4,24796,4,,,53386,5 ,281.1,1,16,3176,16,+++++,+++,4641,28,5501,20,++++ +,+++,2286,9

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 
Old 08-04-2010, 11:24 AM
Dominik Brodowski
 
Default How to track down abysmal performance ata - raid1 - crypto - vg/lv - xfs

On Wed, Aug 04, 2010 at 07:18:03AM -0400, Christoph Hellwig wrote:
> On Wed, Aug 04, 2010 at 12:25:26PM +0200, Dominik Brodowski wrote:
> > Hey,
> >
> > many thanks for your feedback. It seems the crypto step is the culprit:
> >
> > Reading 1.1 GB with dd, iflag=direct, bs=8k:
> >
> > /dev/sd* 35.3 MB/s ( 90 %)
> > /dev/md* 39.1 MB/s (100 %)
> > /dev/mapper/md*_crypt 3.9 MB/s ( 10 %)
> > /dev/mapper/vg1-* 3.9 MB/s ( 10 %)
> >
> > The "good" news: it also happens on my notebook, even though it has a
> > different setup (no raid, disk -> lv/vg -> crypt). On my notebook, I'm
> > more than happy to test out different kernel versions, patches etc.
> >
> > /dev/sd* 17.7 MB/s (100 %)
> > /dev/mapper/vg1-* 16.2 MB/s ( 92 %)
> > /dev/mapper/*_crypt 3.1 MB/s ( 18 %)
>
> The good news is that you have it tracked down, the bad news is that
> I know very little about dm-crypt. Maybe the issue is the single
> threaded decryption in dm-crypt? Can you check how much CPU time
> the dm crypt kernel thread uses?

2 CPUs overall:
Cpu(s): 1.0%us, 5.7%sy, 0.0%ni, 44.8%id, 47.0%wa, 0.0%hi, 1.5%si, 0.0%st

Thanks & best,
Dominik

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 

Thread Tools




All times are GMT. The time now is 01:30 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org