Bug 461847
Summary: | lvm+luks eats cpu | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Need Real Name <lsof> |
Component: | lvm2 | Assignee: | Zdenek Kabelac <zkabelac> |
Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | rawhide | CC: | 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
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? > 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.
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?) 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?) 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? $ 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. 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. |