Re: CCREE performance on R-Car H3 + crash
On Mon, Jul 23, 2018 at 12:55 PM, Geert Uytterhoeven wrote: > Hi Gilad, > > CC linux-crypto for the crash log. > > On Sun, Jul 22, 2018 at 7:28 AM Gilad Ben-Yossef wrote: >> On Thu, Jul 19, 2018 at 3:43 PM, Geert Uytterhoeven >> 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. It seems my memory of the config option name failed me, I was referring to the the sector_size and iv_large_sectors options of dm-crypt. > Is that compatible with the encrypted media that's already in use? No, if you created the media with 512 sector size than obviously trying to mount with a different sector size will not work. There is a discussion right now in the MD mailing list about changes to DM-Crypt so that you don't have to change the sector size and still work with larger buffers if the HW supports auto increment the sector number in the IV, as CryptoCell indeed knows how to do in a newer revision of the HW than the one that is found in the R-Car, but that won't help us here, alas. Thanks, Gilad -- Gilad Ben-Yossef Chief Coffee Drinker values of β will give rise to dom!
Re: CCREE performance on R-Car H3 + crash
On Tue, Jul 24, 2018 at 10:51 AM, Geert Uytterhoeven wrote: > Hi Gilad, > > On Tue, Jul 24, 2018 at 9:32 AM Gilad Ben-Yossef wrote: ... >> I've tried booting your tree and see the same behavior - "Unsupported >> data size" error message but no crash. >> >> I'm running on an Savator-X R-Car H3 ES1.0 board. >> >> Not really sure how to proceed. >> >> Maybe you can send me your exact .config file? > > I cannot reproduce the crash using renesas_defconfig + > CONFIG_CRYPTO_DEV_CCREE=y > + CONFIG_CRYPTO_USER_API_SKCIPHER=y. > > I can reproduce it on Salvator-X with R-Car H3 ES1.0 and Salvator-XS with > R-Car H3 ES2.0 using the attached config. > OK, found what the problem was (SLAB vs. SLUB is what makes the problem manifest as a crash, I think). Just sent fixes to the crypto mailing list. I've spared the Renesas list since it's not really related to it but CCed you. I'd be delighted if you can give it a test. Thank you very much for reporting and assistance! Gilad -- Gilad Ben-Yossef Chief Coffee Drinker values of β will give rise to dom!
Re: CCREE performance on R-Car H3 + crash
Hi Gilad,
On Tue, Jul 24, 2018 at 9:32 AM Gilad Ben-Yossef wrote:
> On Mon, Jul 23, 2018 at 5:35 PM, Geert Uytterhoeven
> wrote:
> > On Mon, Jul 23, 2018 at 4:25 PM Gilad Ben-Yossef
> > wrote:
> >> On Mon, Jul 23, 2018 at 1:31 PM, Gilad Ben-Yossef
> >> wrote:
> >> > On Mon, Jul 23, 2018 at 12:55 PM, Geert Uytterhoeven
> >> > wrote:
> >> >> CC linux-crypto for the crash log.
> >> >>
> >> >> On Sun, Jul 22, 2018 at 7:28 AM Gilad Ben-Yossef
> >> >> wrote:
> >> >>> On Thu, Jul 19, 2018 at 3:43 PM, Geert Uytterhoeven
> >> >>> wrote:
> >> >>> > I've noticed CCREE is used with a LUKS-formatted disk, so I did some
> >> >>> > small
> >> > ...
> >> >>
> >> >> $ 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 128b46.0 MiB/s46.7 MiB/s
> >> >> serpent-cbc 128b N/A N/A
> >> >> twofish-cbc 128b N/A N/A
> >> >> aes-cbc 256b46.5 MiB/s46.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
> >> >> ffbf5c3c3c20
> >> >
> >> > Oy. Thank you for reporting this. I'll take a look at what is going on
> >> > ASAP.
> >>
> >> hmm... well, the plot thickens.
> >>
> >> I was able to recreate the "Unsupported data size 65536" message and
> >> now trying to understand
> >> why the check that causes it is there but - I wasn't able to get a
> >> crash, nor do I understand why
> >> this condition would result in a crash (it ends up returning -EINVAL)...
> >> :-(
> >>
> >> I am surely using a different tree though - I'm based on the
> >> cryptodev/master tree with cherry picking of just R-Car ccree clocks
> >> and enabling.
> >>
> >> I was thinking maybe it's a fix that is already in upstream cryptodev
> >> tree but not in your tree but didn't manage to identify any obvious
> >> suspects
> >>
> >> What tree are you based off?
> >
> > My tree is based on renesas-drivers-2018-07-17-v4.18-rc5 from
> > https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git/
> >
> > Do you want me to try something different?
>
> I've tried booting your tree and see the same behavior - "Unsupported
> data size" error message but no crash.
>
> I'm running on an Savator-X R-Car H3 ES1.0 board.
>
> Not really sure how to proceed.
>
> Maybe you can send me your exact .config file?
I cannot reproduce the crash using renesas_defconfig + CONFIG_CRYPTO_DEV_CCREE=y
+ CONFIG_CRYPTO_USER_API_SKCIPHER=y.
I can reproduce it on Salvator-X with R-Car H3 ES1.0 and Salvator-XS with
R-Car H3 ES2.0 using the attached config.
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
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
config-salvator-x.gz
Description: application/gzip
Re: CCREE performance on R-Car H3 + crash
On Mon, Jul 23, 2018 at 5:35 PM, Geert Uytterhoeven wrote: > Hi Gilad, > > On Mon, Jul 23, 2018 at 4:25 PM Gilad Ben-Yossef wrote: >> On Mon, Jul 23, 2018 at 1:31 PM, Gilad Ben-Yossef >> wrote: >> > On Mon, Jul 23, 2018 at 12:55 PM, Geert Uytterhoeven >> > wrote: >> >> CC linux-crypto for the crash log. >> >> >> >> On Sun, Jul 22, 2018 at 7:28 AM Gilad Ben-Yossef >> >> wrote: >> >>> On Thu, Jul 19, 2018 at 3:43 PM, Geert Uytterhoeven >> >>> wrote: >> >>> > I've noticed CCREE is used with a LUKS-formatted disk, so I did some >> >>> > small >> > ... >> >> >> >> $ 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 128b46.0 MiB/s46.7 MiB/s >> >> serpent-cbc 128b N/A N/A >> >> twofish-cbc 128b N/A N/A >> >> aes-cbc 256b46.5 MiB/s46.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 ffbf5c3c3c20 >> > >> > Oy. Thank you for reporting this. I'll take a look at what is going on >> > ASAP. >> >> hmm... well, the plot thickens. >> >> I was able to recreate the "Unsupported data size 65536" message and >> now trying to understand >> why the check that causes it is there but - I wasn't able to get a >> crash, nor do I understand why >> this condition would result in a crash (it ends up returning -EINVAL)... :-( >> >> I am surely using a different tree though - I'm based on the >> cryptodev/master tree with cherry picking of just R-Car ccree clocks >> and enabling. >> >> I was thinking maybe it's a fix that is already in upstream cryptodev >> tree but not in your tree but didn't manage to identify any obvious >> suspects >> >> What tree are you based off? > > My tree is based on renesas-drivers-2018-07-17-v4.18-rc5 from > https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git/ > > Do you want me to try something different? I've tried booting your tree and see the same behavior - "Unsupported data size" error message but no crash. I'm running on an Savator-X R-Car H3 ES1.0 board. Not really sure how to proceed. Maybe you can send me your exact .config file? Thanks, Gilad -- Gilad Ben-Yossef Chief Coffee Drinker values of β will give rise to dom!
Re: CCREE performance on R-Car H3 + crash
Hi Gilad,
On Mon, Jul 23, 2018 at 4:25 PM Gilad Ben-Yossef wrote:
> On Mon, Jul 23, 2018 at 1:31 PM, Gilad Ben-Yossef wrote:
> > On Mon, Jul 23, 2018 at 12:55 PM, Geert Uytterhoeven
> > wrote:
> >> CC linux-crypto for the crash log.
> >>
> >> On Sun, Jul 22, 2018 at 7:28 AM Gilad Ben-Yossef
> >> wrote:
> >>> On Thu, Jul 19, 2018 at 3:43 PM, Geert Uytterhoeven
> >>> wrote:
> >>> > I've noticed CCREE is used with a LUKS-formatted disk, so I did some
> >>> > small
> > ...
> >>
> >> $ 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 128b46.0 MiB/s46.7 MiB/s
> >> serpent-cbc 128b N/A N/A
> >> twofish-cbc 128b N/A N/A
> >> aes-cbc 256b46.5 MiB/s46.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 ffbf5c3c3c20
> >
> > Oy. Thank you for reporting this. I'll take a look at what is going on ASAP.
>
> hmm... well, the plot thickens.
>
> I was able to recreate the "Unsupported data size 65536" message and
> now trying to understand
> why the check that causes it is there but - I wasn't able to get a
> crash, nor do I understand why
> this condition would result in a crash (it ends up returning -EINVAL)... :-(
>
> I am surely using a different tree though - I'm based on the
> cryptodev/master tree with cherry picking of just R-Car ccree clocks
> and enabling.
>
> I was thinking maybe it's a fix that is already in upstream cryptodev
> tree but not in your tree but didn't manage to identify any obvious
> suspects
>
> What tree are you based off?
My tree is based on renesas-drivers-2018-07-17-v4.18-rc5 from
https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git/
Do you want me to try something different?
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
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
Re: CCREE performance on R-Car H3 + crash
On Mon, Jul 23, 2018 at 1:31 PM, Gilad Ben-Yossef wrote: > On Mon, Jul 23, 2018 at 12:55 PM, Geert Uytterhoeven > wrote: >> Hi Gilad, >> >> CC linux-crypto for the crash log. >> >> On Sun, Jul 22, 2018 at 7:28 AM Gilad Ben-Yossef wrote: >>> On Thu, Jul 19, 2018 at 3:43 PM, Geert Uytterhoeven >>> wrote: >>> > I've noticed CCREE is used with a LUKS-formatted disk, so I did some small > ... >> >> $ 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 128b46.0 MiB/s46.7 MiB/s >> serpent-cbc 128b N/A N/A >> twofish-cbc 128b N/A N/A >> aes-cbc 256b46.5 MiB/s46.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 ffbf5c3c3c20 >> > > Oy. Thank you for reporting this. I'll take a look at what is going on ASAP. hmm... well, the plot thickens. I was able to recreate the "Unsupported data size 65536" message and now trying to understand why the check that causes it is there but - I wasn't able to get a crash, nor do I understand why this condition would result in a crash (it ends up returning -EINVAL)... :-( I am surely using a different tree though - I'm based on the cryptodev/master tree with cherry picking of just R-Car ccree clocks and enabling. I was thinking maybe it's a fix that is already in upstream cryptodev tree but not in your tree but didn't manage to identify any obvious suspects What tree are you based off? Thanks, Gilad -- Gilad Ben-Yossef Chief Coffee Drinker values of β will give rise to dom!
Re: CCREE performance on R-Car H3 + crash
On Mon, Jul 23, 2018 at 12:55 PM, Geert Uytterhoeven wrote: > Hi Gilad, > > CC linux-crypto for the crash log. > > On Sun, Jul 22, 2018 at 7:28 AM Gilad Ben-Yossef wrote: >> On Thu, Jul 19, 2018 at 3:43 PM, Geert Uytterhoeven >> wrote: >> > I've noticed CCREE is used with a LUKS-formatted disk, so I did some small ... > > $ 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 128b46.0 MiB/s46.7 MiB/s > serpent-cbc 128b N/A N/A > twofish-cbc 128b N/A N/A > aes-cbc 256b46.5 MiB/s46.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 ffbf5c3c3c20 > Oy. Thank you for reporting this. I'll take a look at what is going on ASAP. Gilad -- Gilad Ben-Yossef Chief Coffee Drinker values of β will give rise to dom!
Re: CCREE performance on R-Car H3 + crash
Hi Gilad, CC linux-crypto for the crash log. On Sun, Jul 22, 2018 at 7:28 AM Gilad Ben-Yossef wrote: > On Thu, Jul 19, 2018 at 3:43 PM, Geert Uytterhoeven > 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 128b46.0 MiB/s46.7 MiB/s serpent-cbc 128b N/A N/A twofish-cbc 128b N/A N/A aes-cbc 256b46.5 MiB/s46.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 ffbf5c3c3c20 Mem abort info: ESR = 0x9605 Exception class = DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 Data abort info: ISV = 0, ISS = 0x0005 CM = 0, WnR = 0 swapper pgtable: 4k pages, 39-bit VAs, pgdp = 0ed05706 [ffbf5c3c3c20] pgd=, pud= Internal error: Oops: 9605 [#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: 2045 (nzCv daif +PAN -UAO) pc : ksize+0x28/0x48 lr : kzfree+0x1c/0x44 sp : ff800bab3a40 x29: ff800bab3a40 x28: ffea x27: x26: 0001 x25: ffc6f72e0480 x24: 0010 x23: ffc6fa227810 x22: x21: ff800900e000 x20: ffc6f48a5a80 x19: 5a5a5a5a5a5a5a5a x18: 000a x17: x16: x15: bc43 x14: ff8089c9aadf x13: x12: 0030 x11: fffe x10: ff8009c9aae8 x9 : 05f5e0ff x8 : x7 : ff800814c948 x6 : 0001 x5 : x4 : x3 : x2 : 38716e04a5aa3600 x1 : ffbf x0 : ffbf5c3c3c18 Process cryptsetup (pid: 986, stack limit = 0xc7b0be1c) 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/0x
