Re: CCREE performance on R-Car H3 + crash

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

 



Hi Gilad,

CC linux-crypto for the crash log.

On Sun, Jul 22, 2018 at 7:28 AM Gilad Ben-Yossef <gilad@xxxxxxxxxxxxx> wrote:
> On Thu, Jul 19, 2018 at 3:43 PM, Geert Uytterhoeven
> <geert@xxxxxxxxxxxxxx> wrote:
> > 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?

crypt_config.sector_size is 512.

> 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.

Where do I specifiy that option? I couldn't find it.
Is that compatible with the encrypted media that's already in use?

> > 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. :-)

Sure, you have to consider raw performance vs. CPU utilization vs. power
consumption. Need more ways to tweak the kernel :-)

$ cryptsetup benchmark
# Tests are approximate using memory only (no storage IO).
PBKDF2-sha1       478364 iterations per second for 256-bit key
PBKDF2-sha256     927943 iterations per second for 256-bit key
PBKDF2-sha512     360583 iterations per second for 256-bit key
PBKDF2-ripemd160  266677 iterations per second for 256-bit key
PBKDF2-whirlpool  115787 iterations per second for 256-bit key
#  Algorithm | Key |  Encryption |  Decryption
     aes-cbc   128b    46.0 MiB/s    46.7 MiB/s
 serpent-cbc   128b           N/A           N/A
 twofish-cbc   128b           N/A           N/A
     aes-cbc   256b    46.5 MiB/s    46.4 MiB/s
 serpent-cbc   256b           N/A           N/A
 twofish-cbc   256b           N/A           N/A
Segmentation fault

Oops.

ccree e6601000.crypto: Unsupported data size 65536.
Unable to handle kernel paging request at virtual address ffffffbf5c3c3c20
Mem abort info:
  ESR = 0x96000005
  Exception class = DABT (current EL), IL = 32 bits
  SET = 0, FnV = 0
  EA = 0, S1PTW = 0
Data abort info:
  ISV = 0, ISS = 0x00000005
  CM = 0, WnR = 0
swapper pgtable: 4k pages, 39-bit VAs, pgdp = 000000000ed05706
[ffffffbf5c3c3c20] pgd=0000000000000000, pud=0000000000000000
Internal error: Oops: 96000005 [#1] SMP
Modules linked in:
CPU: 4 PID: 986 Comm: cryptsetup Not tainted
4.18.0-rc5-salvator-x-00429-ge5b9d1fce24c0b6c-dirty #118
Hardware name: Renesas Salvator-X 2nd version board based on r8a7795 ES2.0+ (DT)
pstate: 20400005 (nzCv daif +PAN -UAO)
pc : ksize+0x28/0x48
lr : kzfree+0x1c/0x44
sp : ffffff800bab3a40
x29: ffffff800bab3a40 x28: 00000000ffffffea
x27: 0000000000000000 x26: 0000000000010000
x25: ffffffc6f72e0480 x24: 0000000000000010
x23: ffffffc6fa227810 x22: 0000000000000000
x21: ffffff800900e000 x20: ffffffc6f48a5a80
x19: 5a5a5a5a5a5a5a5a x18: 000000000000000a
x17: 0000000000000000 x16: 0000000000000000
x15: 000000000000bc43 x14: ffffff8089c9aadf
x13: ffffffffffffffff x12: 0000000000000030
x11: 00000000fffffffe x10: ffffff8009c9aae8
x9 : 0000000005f5e0ff x8 : 0000000000000000
x7 : ffffff800814c948 x6 : 0000000000000001
x5 : 0000000000000000 x4 : 0000000000000000
x3 : 0000000000000000 x2 : 38716e04a5aa3600
x1 : ffffffbf00000000 x0 : ffffffbf5c3c3c18
Process cryptsetup (pid: 986, stack limit = 0x00000000c7b0be1c)
Call trace:
 ksize+0x28/0x48
 cc_cipher_process+0x3d4/0x7cc
 cc_cipher_encrypt+0x18/0x20
 skcipher_recvmsg+0x2e0/0x344
 sock_recvmsg+0x1c/0x24
 sock_read_iter+0x88/0xd8
 __vfs_read+0x108/0x138
 vfs_read+0x8c/0x120
 ksys_read+0x5c/0xbc
 __arm64_sys_read+0x14/0x1c
 el0_svc_common+0x98/0xe8
 el0_svc_handler+0x1c/0x24
 el0_svc+0x8/0xc
Code: 9b017c00 d2dff7e1 f2ffffe1 aa010000 (f9400401)
---[ end trace 546b68143e9ab0cd ]---

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds



[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