Re: Performance issue LUKS1 vs LUKS2

I can do that - what kind of information would be helpful to add.

An interesting observation (anecdotal at best) to add is that
initially there is a whole bunch of kworkers threads and then it goes
down to a few 2-4 whereas in RedHat 7 the kworker thread count is
exponentially more. I only see more kworker threads when increasing
the size of the files being created/deleted (1024K vs 2048K vs 4096K
etc).

I'm still hoping it's just a parameter/flag that needs to be tuned.

Thanks for all the help.

Regards,
JL

On Fri, Apr 28, 2023 at 2:28 AM Ondrej Kozina <[email protected]> wrote:
>
> On 27. 04. 23 18:08, Lodewyk van der Westhuizen wrote:
> > Hello Milan,
> >
> > Thank you for the response. I'll try to answer your questions as best I can.
> >
> >> NOTE: LUKS1 is not cryptsetup version 1.x, it ia a metadata format.
> >> All recent cryptsetup 2.x versions can use LUKS1 as well - just use "--type luks1"
> >> in format (so you will compare the same formats on different kernels).
> > OK let me rephrase, when using luks1 or luks2 the performance slowdown
> > is still there. The only difference is the version of cryptsetup,
> > dm-crypt and the kernel.
> >
> >> You mean slowdown with access to encrypted data, not unlocking time, right?
> > Correct, measuring the I/O (creating/deleting files)
> >
> >> Which crypto modules are used? What architecture it is - do you use AES-NI
> > acceleration on both systems?
> > It's Red Hat for both machines (RHEL7 vs RHEL8).
>
> Please open bug on https://bugzilla.redhat.com/ (product RHEL8). It may
> be system configuration issue unrelated to dm-crypt/cryptsetup. If it
> turns out to be issue in upstream code as well, I will open upstrem
> issue for it myself later.
>
> Thank you
> Ondrej
>