Re: Performance issue LUKS1 vs LUKS2

CORRECTION: the file blocksize (not actual size of the file)

On Fri, Apr 28, 2023 at 11:05 AM Lodewyk van der Westhuizen
<[email protected]> wrote:
>
> 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
> >