1 |
Am 13.03.2012 19:18, schrieb Michael Mol: |
2 |
> On Tue, Mar 13, 2012 at 2:06 PM, Florian Philipp <lists@×××××××××××.net> wrote: |
3 |
>> Am 13.03.2012 18:45, schrieb Frank Steinmetzger: |
4 |
>>> On Tue, Mar 13, 2012 at 05:11:47PM +0100, Florian Philipp wrote: |
5 |
>>> |
6 |
>>>>> Since I am planning to encrypt only home/ under LVM control, what kind |
7 |
>>>>> of overhead should I expect? |
8 |
>>>> |
9 |
>>>> What do you mean with overhead? CPU utilization? In that case the |
10 |
>>>> overhead is minimal, especially when you run a 64-bit kernel with the |
11 |
>>>> optimized AES kernel module. |
12 |
>>> |
13 |
>>> Speaking of that... |
14 |
>>> I always wondered what the exact difference was between AES and AES i586. I |
15 |
>>> can gather myself that it's about optimisation for a specific architecture. |
16 |
>>> But which one would be best for my i686 Core 2 Duo? |
17 |
>> |
18 |
>> From what I can see in the kernel sources, there is a generic AES |
19 |
>> implementation using nothing but portable C code and then there is |
20 |
>> "aes-i586" assembler code with "aes_glue" C code. |
21 |
> |
22 |
> |
23 |
>> So I assume the i586 |
24 |
>> version is better for you --- unless GCC suddenly got a lot better at |
25 |
>> optimizing code. |
26 |
> |
27 |
> Since when, exactly? GCC isn't the best compiler at optimization, but |
28 |
> I fully expect current versions to produce better code for x86-64 than |
29 |
> hand-tuned i586. Wider registers, more registers, crypto acceleration |
30 |
> instructions and SIMD instructions are all very nice to have. I don't |
31 |
> know the specifics of AES, though, or what kind of crypto algorithm it |
32 |
> is, so it's entirely possible that one can't effectively parallelize |
33 |
> it except in some relatively unique circumstances. |
34 |
> |
35 |
|
36 |
One sec. We are talking about an Core2 Duo running in 32bit mode, right? |
37 |
That's what the i686 reference in the question meant --- or at least, |
38 |
that's what I assumed. |
39 |
|
40 |
If we talk about 32bit mode, none of what you describe is available. |
41 |
Those additional registers and instructions are not accessible with i686 |
42 |
instructions. A Core 2 also has no AES instructions. |
43 |
|
44 |
Of course, GCC could make use of what it knows about the CPU, like |
45 |
number of parallel pipelines, pipeline depth, cache size, instructions |
46 |
added in i686 and so on. But even then I doubt it can outperform |
47 |
hand-tuned assembler, even if it is for a slightly older instruction set. |
48 |
|
49 |
If instead we are talking about an Core 2 Duo running in x86_64 mode, we |
50 |
should be talking about the aes-x86_64 module instead of the aes-i586 |
51 |
module and that makes use of the complete instruction set of the Core 2, |
52 |
including SSE2. |
53 |
|
54 |
Regards, |
55 |
Florian Philipp |