Bug 461847

Summary: lvm+luks eats cpu
Product: [Fedora] Fedora Reporter: Need Real Name <lsof>
Component: lvm2Assignee: Zdenek Kabelac <zkabelac>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: agk, bmarzins, bmr, dwysocha, lsof, mbroz, prockai, zkabelac
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-11-24 13:03:34 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Need Real Name 2008-09-10 21:54:08 UTC
fedora rawhide install onto an msi wind u100, encrypted filesystem.

During a write to disk of an iso from a network drive using rsync I obtain a terrible transfer speed. Rsync says 2.5 megs a second. top shows a kcrypto eating cpu (>30%), i/o wait is low (<5%).

Comment 1 Milan Broz 2008-09-10 22:19:37 UTC
Sure - processor must encrypt all io. What's wrong with that?

Try some local big file copy - do you see better speed?
And rsync to unencrypted filesystem - what part os system causes this slowdown - network, encrypted fs, rsync, some combination?

Comment 2 Need Real Name 2008-09-11 20:00:20 UTC
> What's wrong with that?

The overhead of the encryption is so high that it is substantially limiting the speed of a copy from a network drive.

rsync was used only to determine the speed, i.e. this was not a checksum heavy operation.

Comment 3 Milan Broz 2008-09-11 20:14:48 UTC
Try another cipher.
If it is AES, be sure you use optimized kernel module. 

I cannot help here... the problem is then in speed of encryption process in kerenl crypto lib, maybe the processor need specific optimization (that's Atom right?)

Comment 4 Need Real Name 2008-09-11 20:22:37 UTC
Yep an Atom. MSI Wind U100.

What's the default cipher? I used that. Can I switch it live (i.e. is the cipher per block or file, or is it per partition?)

Comment 5 Zdenek Kabelac 2008-09-15 10:22:21 UTC
Could you please try to boot  with   nosmp  kernel boot parameter - to avoid usage of the second CPU - do you see any improvent in the transfer speed?

Comment 6 Need Real Name 2008-10-05 11:12:15 UTC
$ dd if=/dev/zero of=TEST bs=1k count=500k   # 524 megs

With smp: 60s, 8.6 MB/s
Without smp: 74s, 7.0 MB/s

Which is odd, because these are both significantly above the slow transfer speed I reported.

Before, I got the feeling that the ondemand governor wasn't allowing full use of the cpu. This time /proc/cpuinfo shows 1600 mhz (is this how to check?) so I guess the cpu isn't being kept scaled down any more.

Comment 7 Milan Broz 2008-11-24 13:03:34 UTC
I think that run full encrypted systems on such configuration together with using network transfer must have high performance penalty.
Also Atom CPU probably need some special optimizations in kernel.

Anyway it is not lvm2 nor cryptsetup bug.