Re: CCREE performance on R-Car H3

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Geert,

On Thu, Jul 19, 2018 at 3:43 PM, Geert Uytterhoeven
<geert@xxxxxxxxxxxxxx> wrote:
> Hi Gilad,
>
> I've noticed CCREE is used with a LUKS-formatted disk, so I did some small
> performance benchmarks.  The disk is an old 160 GiB SATA hard drive,
> connected to either Salvator-XS (R-Car H3 ES2.0) or Koelsch (R-Car M2-W).
>
> hdparm -t /dev/sda (unencrypted data): 62 MB/s (both systems)
>
> hdparm -t /dev/dm-0 (encrypted data, LUKS AES):
>
>     salvator-xs (CCREE): 15 MB/s
>     salvator-xs (SW):    62 MB/s
>     koelsch (SW):        47 MB/s
>
> I'm a bit disappointment by the results when using crypto acceleration.
> Apparently the in-kernel optimized arm64 implementation can decrypt at
> raw read speed, while CCREE can't keep up.

Interesting. What is the encryption sector size used?
If it is he default of 512 bytes, you might want to try setting the
new block_size DM-Crypt option. I believe it will have a large effect
on the result.


> Is this expected, and in line with your experiences?

Well, if you were indeed using the default 512 bytes and taking into
account that sadly the CryptoCell inside the R-Car is not wired to
utilize a coherent bus (the cache invalidation costs a fortune in
performance) it is not unexpected.

When reasoning about these things it is worth taking into account that
the design target of using CryptoCell is not to get the absolute best
raw performance as such but rather to get good performance / per cycle
/ per watt.

When the Arm AES Crypto Extension is used (I assume you are using that
and not, say, the NEON implementation) I expect the raw performance to
always be better than CryptoCell, certainly when it is not attached to
a coherent bus. However, if you check CPU utilization during the
operation (basically how much encryption is "stealing" computation
power from the CPU) and subsequent power consumption you are supposed
to see that there is a large area of work loads where it makes more
sense to utilize CryptoCell for disk encryption and use the CPU for
something else.

... in theory, at least. :-)

We've just in the middle of an office move here, but I hope things
will settle down during the ween and I'll be able to replicate your
test and see if I can advise better, but certainly using 4k encryption
section size is key, otherwise the overhead just kills everything.

Thanks!
Gilad
-- 
Gilad Ben-Yossef
Chief Coffee Drinker

values of β will give rise to dom!




[Index of Archives]     [Linux Samsung SOC]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]

  Powered by Linux