lkml.org 
[lkml]   [2010]   [Mar]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: RAID + LUKS + LVM performance
On 03/12/2010 01:06 PM, Matthias Schniedermeyer wrote:

> Using one of the Westmere Core i5-6XX, which support AES-NI, should get
> you better performance (if supported by krcyptd), altough you loose 2
> cores as onyl have 2. But i don't know what kind of performance
> improvement (if any) AES-NI provides.
> Or you wait a few weeks and buy on Core I7-980X with 6 core and AES-NI.

dm-crypt uses whatever is implemented in cryptoAPI, AES-NI of course works
when you have proper modules loaded.

The main reason why dm-crypt is single-threaded is that all these new
crypto accelerators uses asynchronous crypto API, so if hw allows
parallel operation it can use it already.
(dm-crypt submits all sectors in bio as separate asynchronous crypto requests).

But note: single threaded per volume - if you have LVM with multiple
encrypted LVs - every LV have its own thread.

If we build another multi-core(thread) processing in dm-crypt, it can
help on multi-core CPU but complicate things otherwise.
(I tried simple implementation and abandoned it, I would prefer
if cryptoAPI can do some parallel processing itself here.
That question was discussed several times on dm-crypt mailing list.)

Anyway, only two real-world examples, where one thread
in dm-crypt can cause real problems with speed

- dm-crypt over fast RAID(5)
- dm-crypt over fast SSD.

And many users of these configurations have now AES-NI acceleration.

Milan
--
mbroz@redhat.com


\
 
 \ /
  Last update: 2010-03-12 14:15    [W:0.089 / U:1.468 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site