Bug 18302 - [BUG] bad performance and system stalls when using dm-crypt
Summary: [BUG] bad performance and system stalls when using dm-crypt
Status: RESOLVED OBSOLETE
Alias: None
Product: File System
Classification: Unclassified
Component: ext3 (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: fs_ext3@kernel-bugs.osdl.org
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-09-12 11:00 UTC by david b
Modified: 2012-08-13 16:31 UTC (History)
1 user (show)

See Also:
Kernel Version: 2.6.35.4
Subsystem:
Regression: No
Bisected commit-id:


Attachments

Description david b 2010-09-12 11:00:28 UTC
Please see http://thread.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt/4558 for the full mailing list thread that is related to my bug report here :) 

Summary: 
'Right, I see the issue as the following: requesting a lot of writes
and then a number of read operations from different processes leads to
a *poor* outcome.
I say this because if I do "dd /dev/zero of=/tmp/DELETEME"
after a short time the entire system stalls and it really is *very*
difficult to end the dd, which is writing to the disk :)'



---> The first post in the thread I sent to the dm-crypt list :)

I am not sure if this really is a bug or just expected behaviour with
ext3 in ordered mode with luks / dm-crypt adding some extra latency
...

----
I am experiencing really bad performance and a fair amount of system
stalls using dm-crypt(luks)  on debian lenny with  with an ext3
ordered mode  /

"
Version:        1
Cipher name:    aes
Cipher mode:    cbc-essiv:sha256
Hash spec:      sha1
"
/dev/mapper/foo-root on / type ext3 (rw,relatime,errors=remount-ro)
Swap is also within the luks partition.

The kernel version is 2.6.35.4.

A simple test is just to dd if=/dev/zero of=DELETEME for a short time
and the system will stall rather a lot - it is not a complete lock up
- just the entire system is unresponsive for large periods at a time
(from around 30seconds - to 2 minutes). This may be related to
http://thread.gmane.org/gmane.linux.kernel.mm/51444 .


The system is a 6 core amd phenom with 4gb of ram - the hard drive is
a WD 1TB sata 3 drive hooked up to a (sata 3 controller)
00:11.0 SATA controller: ATI Technologies Inc SB700/SB800 SATA
Controller [IDE mode] (rev 40)


00:11.0 SATA controller: ATI Technologies Inc SB700/SB800 SATA
Controller [IDE mode] (rev 40) (prog-if 01 [AHCI 1.0])
       Subsystem: ASUSTeK Computer Inc. Device 8443
       Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR+ FastB2B- DisINTx+
       Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
       Latency: 64, Cache Line Size: 64 bytes
       Interrupt: pin A routed to IRQ 42
       Region 0: I/O ports at c000 [size=8]
       Region 1: I/O ports at b000 [size=4]
       Region 2: I/O ports at a000 [size=8]
       Region 3: I/O ports at 9000 [size=4]
       Region 4: I/O ports at 8000 [size=16]
       Region 5: Memory at fe8ffc00 (32-bit, non-prefetchable) [size=1K]
       Capabilities: [50] Message Signalled Interrupts: Mask- 64bit+
Queue=0/2 Enable+
               Address: 00000000fee3f00c  Data: 4161
       Capabilities: [70] SATA HBA <?>
       Capabilities: [a4] PCIe advanced features <?>
       Kernel driver in use: ahci
       Kernel modules: ahci

------
Comment 1 david b 2010-10-24 15:48:56 UTC
...
For example:
doing something stupid like this 

dd if=/dev/zero of=TEMP count=15553600 &
dd if=/dev/zero of=TEMP2 count=15553600 &
ls -lahR / &
will --> end up with the following output :/

fsync time: 25.8393
pread time: 0.0010
fsync time: 20.6251
pread time: 0.0007
fsync time: 31.0960
pread time: 5.3767
fsync time: 28.0393
pread time: 16.1137
fsync time: 19.2237
pread time: 12.9312
fsync time: 25.0550
pread time: 6.7220
fsync time: 9.8830
pread time: 0.0009

Note You need to log in before you can comment on or make changes to this bug.