Just to bring in some more context: the primary trigger that made us look
into it was high p99 read latency on a random read workflow on modern-ish
SATA SSD and NVME disks. That is, on average things looked fine, but some
portions of requests, which required a small chunk of data to be fetched
from
Thank you John, Damien for extensive measurements. I don't have much
to add as my measurements are probably just a subset of Damien's and
repeat their results.
One interesting thing I noticed when experimenting with this: we
mostly talk about average throughput, but sometimes it is interesting
to
On Wed, Dec 23, 2020 at 3:37 PM Maciej S. Szmigiero
wrote:
>
> On 14.12.2020 19:11, Maciej S. Szmigiero wrote:
> > Hi,
> >
> > I hit a reproducible BUG() when scrubbing a btrfs fs on top of
> > a dm-crypt device with no_read_workqueue and no_write_workqueue
> > flags enabled.
>
> Still happens on
On Wed, Dec 23, 2020 at 9:20 PM Maciej S. Szmigiero
wrote:
>
> On 23.12.2020 22:09, Ignat Korchagin wrote:
> (..)
> > I've been looking into this for the last couple of days because of
> > other reports [1].
> > Just finished testing a possible solution. Will sub
Hi,
Looks like a2b8b2d975673b1a50ab0bcce5d146b9335edfad broke the ability
to reload dm-crypt targets.
I usually used to enable additional flags like this on an existing
dm-crypt instance:
ignat@dev:~$ sudo dmsetup table --showkeys test | sed 's/$/ 2
no_read_workqueue no_write_workqueue/' | sudo
On Wed, Dec 23, 2020 at 8:57 PM Herbert Xu wrote:
>
> On Wed, Dec 23, 2020 at 04:37:34PM +0100, Maciej S. Szmigiero wrote:
> >
> > It looks like to me that the skcipher API might not be safe to
> > call from a softirq context, after all.
>
> skcipher is safe to use in a softirq. The problem is on
dd flags to optionally bypass kcryptd
workqueues")
Reported-by: Maciej S. Szmigiero
Cc: # v5.9+
Signed-off-by: Ignat Korchagin
---
drivers/md/dm-crypt.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm-crypt.c
index 5f9f9b3a226d..777
function reentrant from the point of a single
bio and make dm-crypt defer further bio processing to a workqueue, if Crypto API
backlogs a request in interrupt context.
Fixes: 39d42fa96ba1 ("dm crypt: add flags to optionally bypass kcryptd workq
ueues")
Cc: # v5.9+
Signed-off-by: Ignat
les if we are to avoid in_*irq() marcos in the code.
> is correct.
>
> > Reported-by: Maciej S. Szmigiero
> > Cc: # v5.9+
> > Signed-off-by: Ignat Korchagin
> > ---
> > drivers/md/dm-crypt.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
&
dd flags to optionally bypass kcryptd
workqueues")
Reported-by: Maciej S. Szmigiero
Cc: # v5.9+
Signed-off-by: Ignat Korchagin
---
drivers/md/dm-crypt.c | 33 +++--
1 file changed, 23 insertions(+), 10 deletions(-)
diff --git a/drivers/md/dm-crypt.c b/drivers/md/
function reentrant from the point of a single
bio and make dm-crypt defer further bio processing to a workqueue, if Crypto API
backlogs a request in interrupt context.
Fixes: 39d42fa96ba1 ("dm crypt: add flags to optionally bypass kcryptd workq
ueues")
Cc: # v5.9+
Signed-off-by: Ignat
Changes from v1:
0001: Handle memory allocation failure for GFP_ATOMIC
Ignat Korchagin (2):
dm crypt: use GFP_ATOMIC when allocating crypto requests from softirq
dm crypt: do not wait for backlogged crypto request completion in
softirq
drivers/md/dm-crypt.c | 135
Yes, good call!
Reposted with allocation failure handling.
Thanks,
Ignat
On Wed, Dec 30, 2020 at 6:11 PM Mikulas Patocka wrote:
>
> Hi
>
> This patch doesn't handle allocation failure gracefully.
>
> Mikulas
>
>
>
> On Tue, 29 Dec 2020,
On Fri, Jan 1, 2021 at 10:00 AM Mikulas Patocka wrote:
>
>
>
> On Wed, 30 Dec 2020, Ignat Korchagin wrote:
>
> > diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm-crypt.c
> > index 53791138d78b..e4fd690c70e1 100644
> > --- a/drivers/md/dm-crypt.c
> > +++
function reentrant from the point of a single
bio and make dm-crypt defer further bio processing to a workqueue, if Crypto API
backlogs a request in interrupt context.
Fixes: 39d42fa96ba1 ("dm crypt: add flags to optionally bypass kcryptd workq
ueues")
Cc: # v5.9+
Signed-off-by: Ignat
dd flags to optionally bypass kcryptd
workqueues")
Reported-by: Maciej S. Szmigiero
Cc: # v5.9+
Signed-off-by: Ignat Korchagin
---
drivers/md/dm-crypt.c | 35 +--
1 file changed, 25 insertions(+), 10 deletions(-)
diff --git a/drivers/md/dm-crypt.c b/drivers/md/
Changes from v1:
* 0001: handle memory allocation failure for GFP_ATOMIC
Changes from v2:
* reordered patches
* 0002: crypt_convert will be retried from a workqueue, when a crypto request
allocation fails with GFP_ATOMIC instead of just returning an IO error to
the user
Ignat
"dm crypt: add flags to optionally bypass kcryptd
workqueues")
Cc: # v5.9+
Signed-off-by: Ignat Korchagin
---
drivers/md/dm-crypt.c | 24 +++-
1 file changed, 23 insertions(+), 1 deletion(-)
diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm-crypt.c
index 5379113
t defer it to a tasklet as with requests from hard irqs.
Fixes: 39d42fa96ba1 ("dm crypt: add flags to optionally bypass kcryptd
workqueues")
Cc: # v5.9+
Signed-off-by: Ignat Korchagin
---
drivers/md/dm-crypt.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/d
AD request pointer
are part of a union, but may confuse code reviewers.
Fixes: d68b295 ("dm crypt: use GFP_ATOMIC when allocating crypto requests from
softirq")
Cc: sta...@vger.kernel.org # v5.9+
Reported-by: Pavel Machek
Signed-off-by: Ignat Korchagin
---
drivers/md/dm-crypt.c | 6 +++--
On Sat, Feb 13, 2021 at 11:11 AM Sebastian Andrzej Siewior
wrote:
>
> By looking at the handling of DM_CRYPT_NO_*_WORKQUEUE in
> kcryptd_queue_crypt() it appears that READ and WRITE requests might be
> handled in the tasklet context as long as interrupts are disabled or it
> is handled in hardirq
On Sat, Feb 13, 2021 at 11:11 AM Sebastian Andrzej Siewior
wrote:
>
> The atomic argument of crypto_convert() is used to decide if
> cond_resched() may be invoked.
>
> kcryptd_crypt_write_continue() and kcryptd_crypt_read_continue() pass
> true here but both are invoked by a worker where schedulin
On Thu, Mar 11, 2021 at 6:25 PM Mike Snitzer wrote:
>
> On Sat, Feb 13 2021 at 9:31am -0500,
> Ignat Korchagin wrote:
>
> > On Sat, Feb 13, 2021 at 11:11 AM Sebastian Andrzej Siewior
> > wrote:
> > >
> > > By looking at the handling of DM_CRYPT_NO_*_W
On Fri, Jun 19, 2020 at 7:39 PM Mikulas Patocka wrote:
>
>
>
> On Fri, 19 Jun 2020, Mike Snitzer wrote:
>
> > On Fri, Jun 19 2020 at 12:41pm -0400,
> > Ignat Korchagin wrote:
> >
> > > This is a follow up from the long-forgotten [1], but with some more
Yes, it should.
I got one when I was testing the first iteration (without the tasklet)
of the patch on an NVME? disk.
On Sat, Jun 20, 2020 at 8:36 PM Mikulas Patocka wrote:
>
>
>
> On Sat, 20 Jun 2020, Herbert Xu wrote:
>
> > On Fri, Jun 19, 2020 at 02:39:39PM -0400, Mikulas Patocka wrote:
> > >
-by: Ignat Korchagin
---
drivers/md/dm-crypt.c | 55 +--
1 file changed, 43 insertions(+), 12 deletions(-)
diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm-crypt.c
index 000ddfab5ba0..5a9bac4fdffb 100644
--- a/drivers/md/dm-crypt.c
+++ b/drivers/md/dm
0 datacentres on both SATA SSDs and NVME SSDs and so far were very
happy with the performance benefits.
[1]: https://www.spinics.net/lists/dm-crypt/msg07516.html
[2]: https://blog.cloudflare.com/speeding-up-linux-disk-encryption/
Ignat Korchagin (1):
Add DM_CRYPT_FORCE_INLINE flag to dm-c
On Mon, Jun 22, 2020 at 1:45 AM Damien Le Moal wrote:
>
> On 2020/06/20 1:56, Mike Snitzer wrote:
> > On Fri, Jun 19 2020 at 12:41pm -0400,
> > Ignat Korchagin wrote:
> >
> >> This is a follow up from the long-forgotten [1], but with some more
> >&
On Tue, Jun 23, 2020 at 4:34 PM Mike Snitzer wrote:
>
> On Fri, Jun 19 2020 at 9:23pm -0400,
> Herbert Xu wrote:
>
> > On Fri, Jun 19, 2020 at 02:39:39PM -0400, Mikulas Patocka wrote:
> > >
> > > I'm looking at this and I'd like to know why does the crypto API fail in
> > > hard-irq context and
Damien Le Moal wrote:
>
> > On 2020/06/20 1:56, Mike Snitzer wrote:
> > > On Fri, Jun 19 2020 at 12:41pm -0400,
> > > Ignat Korchagin wrote:
> > >
> > >> This is a follow up from the long-forgotten [1], but with some more
> > >> convincing
On Wed, Jun 24, 2020 at 6:22 AM Mike Snitzer wrote:
>
> On Wed, Jun 24 2020 at 12:54am -0400,
> Damien Le Moal wrote:
>
> > On 2020/06/24 0:23, Mike Snitzer wrote:
> > > On Tue, Jun 23 2020 at 11:07am -0400,
> > > Ignat Korchagin wrote:
> > >
> &
On Wed, Jun 24, 2020 at 6:04 AM Eric Biggers wrote:
>
> On Fri, Jun 19, 2020 at 05:41:32PM +0100, Ignat Korchagin wrote:
> > Sometimes extra thread offloading imposed by dm-crypt hurts IO latency.
> > This is
> > especially visible on busy systems with many processes/thre
On Wed, Jun 24, 2020 at 5:24 PM Eric Biggers wrote:
>
> On Wed, Jun 24, 2020 at 09:24:07AM +0100, Ignat Korchagin wrote:
> > On Wed, Jun 24, 2020 at 6:04 AM Eric Biggers wrote:
> > >
> > > On Fri, Jun 19, 2020 at 05:41:32PM +0100, Ignat Korchagin wrote:
> > &
log crypto requests.
[1]: https://www.spinics.net/lists/dm-crypt/msg07516.html
[2]: https://blog.cloudflare.com/speeding-up-linux-disk-encryption/
Signed-off-by: Ignat Korchagin
---
drivers/md/dm-crypt.c | 68 +--
1 file changed, 52 insertions(+), 16 deletions(-)
diff --g
On Tue, Jun 30, 2020 at 3:51 AM Damien Le Moal wrote:
>
> On 2020/06/27 6:03, Ignat Korchagin wrote:
> > This is a follow up from [1]. Consider the following script:
> >
> > sudo modprobe brd rd_nr=1 rd_size=4194304
> >
> > echo '0 8388608 crypt capi:ecb(c
d encryption into
their own workqueues, which are independent of the dm-crypt and its
configuration. However upon enabling no_(read|write)_workqueue flags dm-crypt
will instruct Crypto API not to backlog crypto requests.
[1]: https://www.spinics.net/lists/dm-crypt/msg07516.html
[2]: https://blog.c
On Mon, Jul 6, 2020 at 3:28 PM Bob Liu wrote:
>
> Hi Ignat,
>
> On 6/27/20 5:03 AM, Ignat Korchagin wrote:
> > This is a follow up from [1]. Consider the following script:
> >
> > sudo modprobe brd rd_nr=1 rd_size=4194304
> >
>
> Did you test null_blk dev
On Wed, Mar 8, 2023 at 2:56 AM Hou Tao wrote:
>
> Hi,
>
> On 3/7/2023 10:47 PM, Mike Snitzer wrote:
> > On Mon, Mar 06 2023 at 9:12P -0500,
> > Hou Tao wrote:
> >
> >> Hi,
> >>
> >> On 3/7/2023 3:31 AM, Mike Snitzer wrote:
> >>> On Mon, Mar 06 2023 at 8:49P -0500,
> >>> Hou Tao wrote:
> >>>
>
On Wed, Mar 8, 2023 at 7:19 PM Mike Snitzer wrote:
>
> On Wed, Mar 08 2023 at 8:55P -0500,
> Ignat Korchagin wrote:
>
> > On Wed, Mar 8, 2023 at 2:56 AM Hou Tao wrote:
> > >
> > > Hi,
> > >
> > > On 3/7/2023 10:47 PM, Mike Snitzer wrote:
&g
On Wed, Mar 8, 2023 at 8:27 PM Mike Snitzer wrote:
>
> On Wed, Mar 08 2023 at 2:19P -0500,
> Mike Snitzer wrote:
>
> > On Wed, Mar 08 2023 at 8:55P -0500,
> > Ignat Korchagin wrote:
> >
> > > Perhaps instead we can just pass an additional flag from
&g
HI,
On Thu, May 25, 2023 at 3:34 AM wrote:
>
> Hello,
>
> On Tue, 23 May 2023 13:53:23 -0400 Mike Snitzer wrote:
>
> > > In order to improve the IO performance of the dm-crypt
> > > implementation, the commit 39d42fa96ba1 ("dm crypt:
> > > add flags to optionally bypass kcryptd workqueues")
> > >
41 matches
Mail list logo
