* [dm-devel] [PATCH] dm-crypt: fix softlockup in dmcrypt_write @ 2023-02-23 3:19 yangerkun 2023-02-26 2:01 ` Bart Van Assche 0 siblings, 1 reply; 12+ messages in thread From: yangerkun @ 2023-02-23 3:19 UTC (permalink / raw) To: agk, snitzer, dm-devel; +Cc: yangerkun, yangerkun From: yangerkun <yangerkun@huawei.com> We meet a softlockup: localhost login: [ 3391.153255][ C12] watchdog: BUG: soft lockup - CPU#12 stuck for 23s! [dmcrypt_write/2:2897] ... [ 3391.258372][ C12] CPU: 12 PID: 2897 Comm: dmcrypt_write/2 Tainted: G L 5.10.0+ #8 [ 3391.267288][ C12] Hardware name: Huawei TaiShan 2280 V2/BC82AMDDA, BIOS 1.75 04/26/2021 [ 3391.275428][ C12] pstate: 80400009 (Nzcv daif +PAN -UAO -TCO BTYPE=--) [ 3391.282102][ C12] pc : blk_attempt_bio_merge.part.6+0x38/0x158 [ 3391.288080][ C12] lr : blk_attempt_plug_merge+0xc0/0x1b0 [ 3391.293540][ C12] sp : ffff8000718abc30 [ 3391.297530][ C12] x29: ffff8000718abc30 x28: 0000000000000000 [ 3391.303509][ C12] x27: ffff2020361d9ac0 x26: 0000000000000001 [ 3391.309488][ C12] x25: 0000000000000001 x24: ffff8000718abd08 [ 3391.315467][ C12] x23: ffff0020a10dbb00 x22: 0000000000000001 [ 3391.321445][ C12] x21: ffff8000718abe20 x20: ffff0020a10dbb00 [ 3391.327424][ C12] x19: ffff0020aed7b040 x18: 0000000000000000 [ 3391.333402][ C12] x17: 0000000000000000 x16: fffffdffffe00000 [ 3391.339381][ C12] x15: 0000000000001000 x14: 0000000000000000 [ 3391.345359][ C12] x13: 0000000000002000 x12: ffff2060011f9070 [ 3391.351338][ C12] x11: 0000000000000001 x10: 0000000000000002 [ 3391.357316][ C12] x9 : ffff800010586c38 x8 : ffff202009a7f200 [ 3391.363294][ C12] x7 : ffff8000718abd00 x6 : ffff20200df33750 [ 3391.369274][ C12] x5 : 0000000000000001 x4 : 0000000000000000 [ 3391.375252][ C12] x3 : 0000000000000001 x2 : ffff0020a10dbb00 [ 3391.381230][ C12] x1 : ffff0020aed7b040 x0 : 0000000000001000 [ 3391.387210][ C12] Call trace: [ 3391.390338][ C12] blk_attempt_bio_merge.part.6+0x38/0x158 [ 3391.395970][ C12] blk_attempt_plug_merge+0xc0/0x1b0 [ 3391.401085][ C12] blk_mq_submit_bio+0x398/0x550 [ 3391.405856][ C12] submit_bio_noacct+0x308/0x380 [ 3391.410630][ C12] dmcrypt_write+0x1e4/0x208 [dm_crypt] [ 3391.416005][ C12] kthread+0x130/0x138 [ 3391.419911][ C12] ret_from_fork+0x10/0x18 dmcrypt_write may see not empty write_tree for a long time if we have a heavy load of write, and submit_bio for high-performance disk like nvme can always get a valid tag, so the bio routine will not yield cpu too. So the softlockup seems reasonably. Fix it by schedule periodically. Fixes: dc2676210c42 ("dm crypt: offload writes to thread") Signed-off-by: yangerkun <yangerkun@huawei.com> --- drivers/md/dm-crypt.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm-crypt.c index 2653516bcdef..755a01d72cdb 100644 --- a/drivers/md/dm-crypt.c +++ b/drivers/md/dm-crypt.c @@ -1891,6 +1891,7 @@ static int dmcrypt_write(void *data) { struct crypt_config *cc = data; struct dm_crypt_io *io; + unsigned long start_time = jiffies; while (1) { struct rb_root write_tree; @@ -1913,6 +1914,7 @@ static int dmcrypt_write(void *data) schedule(); + start_time = jiffies; set_current_state(TASK_RUNNING); spin_lock_irq(&cc->write_thread_lock); goto continue_locked; @@ -1924,6 +1926,10 @@ static int dmcrypt_write(void *data) BUG_ON(rb_parent(write_tree.rb_node)); + if (time_is_before_jiffies(start_time + HZ)) { + schedule(); + start_time = jiffies; + } /* * Note: we cannot walk the tree here with rb_next because * the structures may be freed when kcryptd_io_write is called. -- 2.31.1 -- dm-devel mailing list dm-devel@redhat.com https://listman.redhat.com/mailman/listinfo/dm-devel ^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [dm-devel] [PATCH] dm-crypt: fix softlockup in dmcrypt_write 2023-02-23 3:19 [dm-devel] [PATCH] dm-crypt: fix softlockup in dmcrypt_write yangerkun @ 2023-02-26 2:01 ` Bart Van Assche 2023-02-27 1:31 ` yangerkun 0 siblings, 1 reply; 12+ messages in thread From: Bart Van Assche @ 2023-02-26 2:01 UTC (permalink / raw) To: yangerkun, agk, snitzer, dm-devel; +Cc: yangerkun On 2/22/23 19:19, yangerkun wrote: > @@ -1924,6 +1926,10 @@ static int dmcrypt_write(void *data) > > BUG_ON(rb_parent(write_tree.rb_node)); > > + if (time_is_before_jiffies(start_time + HZ)) { > + schedule(); > + start_time = jiffies; > + } Why schedule() instead of cond_resched()? Thanks, Bart. -- dm-devel mailing list dm-devel@redhat.com https://listman.redhat.com/mailman/listinfo/dm-devel ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [dm-devel] [PATCH] dm-crypt: fix softlockup in dmcrypt_write 2023-02-26 2:01 ` Bart Van Assche @ 2023-02-27 1:31 ` yangerkun 2023-02-27 17:55 ` [dm-devel] " Mike Snitzer 0 siblings, 1 reply; 12+ messages in thread From: yangerkun @ 2023-02-27 1:31 UTC (permalink / raw) To: Bart Van Assche, agk, snitzer, dm-devel; +Cc: yangerkun 在 2023/2/26 10:01, Bart Van Assche 写道: > On 2/22/23 19:19, yangerkun wrote: >> @@ -1924,6 +1926,10 @@ static int dmcrypt_write(void *data) >> BUG_ON(rb_parent(write_tree.rb_node)); >> + if (time_is_before_jiffies(start_time + HZ)) { >> + schedule(); >> + start_time = jiffies; >> + } > > Why schedule() instead of cond_resched()? cond_resched may not really schedule, which may trigger the problem too, but it seems after 1 second, it may never happend? Thanks, Kun. > > Thanks, > > Bart. > -- dm-devel mailing list dm-devel@redhat.com https://listman.redhat.com/mailman/listinfo/dm-devel ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [dm-devel] dm-crypt: fix softlockup in dmcrypt_write 2023-02-27 1:31 ` yangerkun @ 2023-02-27 17:55 ` Mike Snitzer 2023-02-27 18:03 ` Mike Snitzer 2023-02-28 1:25 ` yangerkun 0 siblings, 2 replies; 12+ messages in thread From: Mike Snitzer @ 2023-02-27 17:55 UTC (permalink / raw) To: yangerkun; +Cc: yangerkun, dm-devel, Bart Van Assche, agk On Sun, Feb 26 2023 at 8:31P -0500, yangerkun <yangerkun@huaweicloud.com> wrote: > > > 在 2023/2/26 10:01, Bart Van Assche 写道: > > On 2/22/23 19:19, yangerkun wrote: > > > @@ -1924,6 +1926,10 @@ static int dmcrypt_write(void *data) > > > BUG_ON(rb_parent(write_tree.rb_node)); > > > + if (time_is_before_jiffies(start_time + HZ)) { > > > + schedule(); > > > + start_time = jiffies; > > > + } > > > > Why schedule() instead of cond_resched()? > > cond_resched may not really schedule, which may trigger the problem too, but > it seems after 1 second, it may never happend? I had the same question as Bart when reviewing your homegrown conditional schedule(). Hopefully you can reproduce this issue? If so, please see if simply using cond_resched() fixes the issue. Thanks, Mike -- dm-devel mailing list dm-devel@redhat.com https://listman.redhat.com/mailman/listinfo/dm-devel ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [dm-devel] dm-crypt: fix softlockup in dmcrypt_write 2023-02-27 17:55 ` [dm-devel] " Mike Snitzer @ 2023-02-27 18:03 ` Mike Snitzer 2023-02-27 18:06 ` Mike Snitzer 2023-02-28 1:25 ` yangerkun 1 sibling, 1 reply; 12+ messages in thread From: Mike Snitzer @ 2023-02-27 18:03 UTC (permalink / raw) To: yangerkun; +Cc: yangerkun, dm-devel, Bart Van Assche, agk On Mon, Feb 27 2023 at 12:55P -0500, Mike Snitzer <snitzer@kernel.org> wrote: > On Sun, Feb 26 2023 at 8:31P -0500, > yangerkun <yangerkun@huaweicloud.com> wrote: > > > > > > > 在 2023/2/26 10:01, Bart Van Assche 写道: > > > On 2/22/23 19:19, yangerkun wrote: > > > > @@ -1924,6 +1926,10 @@ static int dmcrypt_write(void *data) > > > > BUG_ON(rb_parent(write_tree.rb_node)); > > > > + if (time_is_before_jiffies(start_time + HZ)) { > > > > + schedule(); > > > > + start_time = jiffies; > > > > + } > > > > > > Why schedule() instead of cond_resched()? > > > > cond_resched may not really schedule, which may trigger the problem too, but > > it seems after 1 second, it may never happend? > > I had the same question as Bart when reviewing your homegrown > conditional schedule(). Hopefully you can reproduce this issue? If > so, please see if simply using cond_resched() fixes the issue. This seems like a more appropriate patch: diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm-crypt.c index 87c5706131f2..faba1be572f9 100644 --- a/drivers/md/dm-crypt.c +++ b/drivers/md/dm-crypt.c @@ -1937,6 +1937,7 @@ static int dmcrypt_write(void *data) io = crypt_io_from_node(rb_first(&write_tree)); rb_erase(&io->rb_node, &write_tree); kcryptd_io_write(io); + cond_resched(); } while (!RB_EMPTY_ROOT(&write_tree)); blk_finish_plug(&plug); } -- dm-devel mailing list dm-devel@redhat.com https://listman.redhat.com/mailman/listinfo/dm-devel ^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [dm-devel] dm-crypt: fix softlockup in dmcrypt_write 2023-02-27 18:03 ` Mike Snitzer @ 2023-02-27 18:06 ` Mike Snitzer 2023-02-28 1:40 ` yangerkun 0 siblings, 1 reply; 12+ messages in thread From: Mike Snitzer @ 2023-02-27 18:06 UTC (permalink / raw) To: yangerkun; +Cc: yangerkun, dm-devel, Bart Van Assche, agk On Mon, Feb 27 2023 at 1:03P -0500, Mike Snitzer <snitzer@kernel.org> wrote: > On Mon, Feb 27 2023 at 12:55P -0500, > Mike Snitzer <snitzer@kernel.org> wrote: > > > On Sun, Feb 26 2023 at 8:31P -0500, > > yangerkun <yangerkun@huaweicloud.com> wrote: > > > > > > > > > > > 在 2023/2/26 10:01, Bart Van Assche 写道: > > > > On 2/22/23 19:19, yangerkun wrote: > > > > > @@ -1924,6 +1926,10 @@ static int dmcrypt_write(void *data) > > > > > BUG_ON(rb_parent(write_tree.rb_node)); > > > > > + if (time_is_before_jiffies(start_time + HZ)) { > > > > > + schedule(); > > > > > + start_time = jiffies; > > > > > + } > > > > > > > > Why schedule() instead of cond_resched()? > > > > > > cond_resched may not really schedule, which may trigger the problem too, but > > > it seems after 1 second, it may never happend? > > > > I had the same question as Bart when reviewing your homegrown > > conditional schedule(). Hopefully you can reproduce this issue? If > > so, please see if simply using cond_resched() fixes the issue. > > This seems like a more appropriate patch: > > diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm-crypt.c > index 87c5706131f2..faba1be572f9 100644 > --- a/drivers/md/dm-crypt.c > +++ b/drivers/md/dm-crypt.c > @@ -1937,6 +1937,7 @@ static int dmcrypt_write(void *data) > io = crypt_io_from_node(rb_first(&write_tree)); > rb_erase(&io->rb_node, &write_tree); > kcryptd_io_write(io); > + cond_resched(); > } while (!RB_EMPTY_ROOT(&write_tree)); > blk_finish_plug(&plug); > } or: diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm-crypt.c index 87c5706131f2..3ba2fd3e4358 100644 --- a/drivers/md/dm-crypt.c +++ b/drivers/md/dm-crypt.c @@ -1934,6 +1934,7 @@ static int dmcrypt_write(void *data) */ blk_start_plug(&plug); do { + cond_resched(); io = crypt_io_from_node(rb_first(&write_tree)); rb_erase(&io->rb_node, &write_tree); kcryptd_io_write(io); -- dm-devel mailing list dm-devel@redhat.com https://listman.redhat.com/mailman/listinfo/dm-devel ^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [dm-devel] dm-crypt: fix softlockup in dmcrypt_write 2023-02-27 18:06 ` Mike Snitzer @ 2023-02-28 1:40 ` yangerkun 2023-03-06 18:02 ` Mikulas Patocka 0 siblings, 1 reply; 12+ messages in thread From: yangerkun @ 2023-02-28 1:40 UTC (permalink / raw) To: Mike Snitzer; +Cc: yangerkun, dm-devel, Bart Van Assche, agk 在 2023/2/28 2:06, Mike Snitzer 写道: > On Mon, Feb 27 2023 at 1:03P -0500, > Mike Snitzer <snitzer@kernel.org> wrote: > >> On Mon, Feb 27 2023 at 12:55P -0500, >> Mike Snitzer <snitzer@kernel.org> wrote: >> >>> On Sun, Feb 26 2023 at 8:31P -0500, >>> yangerkun <yangerkun@huaweicloud.com> wrote: >>> >>>> >>>> >>>> 在 2023/2/26 10:01, Bart Van Assche 写道: >>>>> On 2/22/23 19:19, yangerkun wrote: >>>>>> @@ -1924,6 +1926,10 @@ static int dmcrypt_write(void *data) >>>>>> BUG_ON(rb_parent(write_tree.rb_node)); >>>>>> + if (time_is_before_jiffies(start_time + HZ)) { >>>>>> + schedule(); >>>>>> + start_time = jiffies; >>>>>> + } >>>>> >>>>> Why schedule() instead of cond_resched()? >>>> >>>> cond_resched may not really schedule, which may trigger the problem too, but >>>> it seems after 1 second, it may never happend? >>> >>> I had the same question as Bart when reviewing your homegrown >>> conditional schedule(). Hopefully you can reproduce this issue? If >>> so, please see if simply using cond_resched() fixes the issue. >> >> This seems like a more appropriate patch: >> >> diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm-crypt.c >> index 87c5706131f2..faba1be572f9 100644 >> --- a/drivers/md/dm-crypt.c >> +++ b/drivers/md/dm-crypt.c >> @@ -1937,6 +1937,7 @@ static int dmcrypt_write(void *data) >> io = crypt_io_from_node(rb_first(&write_tree)); >> rb_erase(&io->rb_node, &write_tree); >> kcryptd_io_write(io); >> + cond_resched(); >> } while (!RB_EMPTY_ROOT(&write_tree)); >> blk_finish_plug(&plug); >> } > > > or: > > diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm-crypt.c > index 87c5706131f2..3ba2fd3e4358 100644 > --- a/drivers/md/dm-crypt.c > +++ b/drivers/md/dm-crypt.c > @@ -1934,6 +1934,7 @@ static int dmcrypt_write(void *data) > */ > blk_start_plug(&plug); > do { > + cond_resched(); > io = crypt_io_from_node(rb_first(&write_tree)); > rb_erase(&io->rb_node, &write_tree); > kcryptd_io_write(io); Hi, Thanks a lot for your review! It's ok to fix the softlockup, but for async write encrypt, kcryptd_crypt_write_io_submit will add bio to write_tree, and once we call cond_resched before every kcryptd_io_write, the write performance may be poor while we meet a high cpu usage scene. kcryptd_crypt_write_io_submit will wakeup write_thread once there is a empty write_tree, and dmcrypt_write will peel the old write_tree to submit bio, so there can not exist too many bio in write_tree. Then I choose yield cpu before the 'while' that submit bio... Thanks, Kun. -- dm-devel mailing list dm-devel@redhat.com https://listman.redhat.com/mailman/listinfo/dm-devel ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [dm-devel] dm-crypt: fix softlockup in dmcrypt_write 2023-02-28 1:40 ` yangerkun @ 2023-03-06 18:02 ` Mikulas Patocka 2023-03-06 18:16 ` Bart Van Assche 0 siblings, 1 reply; 12+ messages in thread From: Mikulas Patocka @ 2023-03-06 18:02 UTC (permalink / raw) To: yangerkun; +Cc: yangerkun, Mike Snitzer, dm-devel, agk, Bart Van Assche [-- Attachment #1: Type: text/plain, Size: 3451 bytes --] On Tue, 28 Feb 2023, yangerkun wrote: > > > 在 2023/2/28 2:06, Mike Snitzer 写道: > > On Mon, Feb 27 2023 at 1:03P -0500, > > Mike Snitzer <snitzer@kernel.org> wrote: > > > >> On Mon, Feb 27 2023 at 12:55P -0500, > >> Mike Snitzer <snitzer@kernel.org> wrote: > >> > >>> On Sun, Feb 26 2023 at 8:31P -0500, > >>> yangerkun <yangerkun@huaweicloud.com> wrote: > >>> > >>>> > >>>> > >>>> 在 2023/2/26 10:01, Bart Van Assche 写道: > >>>>> On 2/22/23 19:19, yangerkun wrote: > >>>>>> @@ -1924,6 +1926,10 @@ static int dmcrypt_write(void *data) > >>>>>> BUG_ON(rb_parent(write_tree.rb_node)); > >>>>>> + if (time_is_before_jiffies(start_time + HZ)) { > >>>>>> + schedule(); > >>>>>> + start_time = jiffies; > >>>>>> + } > >>>>> > >>>>> Why schedule() instead of cond_resched()? > >>>> > >>>> cond_resched may not really schedule, which may trigger the problem too, > but > >>>> it seems after 1 second, it may never happend? > >>> > >>> I had the same question as Bart when reviewing your homegrown > >>> conditional schedule(). Hopefully you can reproduce this issue? If > >>> so, please see if simply using cond_resched() fixes the issue. > >> > >> This seems like a more appropriate patch: > >> > >> diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm-crypt.c > >> index 87c5706131f2..faba1be572f9 100644 > >> --- a/drivers/md/dm-crypt.c > >> +++ b/drivers/md/dm-crypt.c > >> @@ -1937,6 +1937,7 @@ static int dmcrypt_write(void *data) > >> io = crypt_io_from_node(rb_first(&write_tree)); > >> rb_erase(&io->rb_node, &write_tree); > >> kcryptd_io_write(io); > >> + cond_resched(); > >> } while (!RB_EMPTY_ROOT(&write_tree)); > >> blk_finish_plug(&plug); > >> } > > > > > > or: > > > > diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm-crypt.c > > index 87c5706131f2..3ba2fd3e4358 100644 > > --- a/drivers/md/dm-crypt.c > > +++ b/drivers/md/dm-crypt.c > > @@ -1934,6 +1934,7 @@ static int dmcrypt_write(void *data) > > */ > > blk_start_plug(&plug); > > do { > > + cond_resched(); > > io = crypt_io_from_node(rb_first(&write_tree)); > > rb_erase(&io->rb_node, &write_tree); > > kcryptd_io_write(io); > > Hi, > > Thanks a lot for your review! > > It's ok to fix the softlockup, but for async write encrypt, > kcryptd_crypt_write_io_submit will add bio to write_tree, and once we > call cond_resched before every kcryptd_io_write, the write performance > may be poor while we meet a high cpu usage scene. Hi To fix this problem, find the PID of the process "dmcrypt_write" and change its priority to -20, for example "renice -n -20 -p 34748". This is the proper way how to fix it; locking up the process for one second is not. We used to have high-priority workqueues by default, but it caused audio playback skipping, so we had to revert it - see f612b2132db529feac4f965f28a1b9258ea7c22b. Perhaps we should add an option to have high-priority kernel threads? Mikulas > kcryptd_crypt_write_io_submit will wakeup write_thread once there is a > empty write_tree, and dmcrypt_write will peel the old write_tree to > submit bio, so there can not exist too many bio in write_tree. Then I > choose yield cpu before the 'while' that submit bio... > > Thanks, > Kun. > > -- > dm-devel mailing list > dm-devel@redhat.com > https://listman.redhat.com/mailman/listinfo/dm-devel > [-- Attachment #2: Type: text/plain, Size: 98 bytes --] -- dm-devel mailing list dm-devel@redhat.com https://listman.redhat.com/mailman/listinfo/dm-devel ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [dm-devel] dm-crypt: fix softlockup in dmcrypt_write 2023-03-06 18:02 ` Mikulas Patocka @ 2023-03-06 18:16 ` Bart Van Assche 2023-03-06 19:03 ` Mikulas Patocka 0 siblings, 1 reply; 12+ messages in thread From: Bart Van Assche @ 2023-03-06 18:16 UTC (permalink / raw) To: Mikulas Patocka, yangerkun; +Cc: yangerkun, Mike Snitzer, dm-devel, agk On 3/6/23 10:02, Mikulas Patocka wrote: > On Tue, 28 Feb 2023, yangerkun wrote: >> It's ok to fix the softlockup, but for async write encrypt, >> kcryptd_crypt_write_io_submit will add bio to write_tree, and once we >> call cond_resched before every kcryptd_io_write, the write performance >> may be poor while we meet a high cpu usage scene. > > Hi > > To fix this problem, find the PID of the process "dmcrypt_write" and > change its priority to -20, for example "renice -n -20 -p 34748". > > This is the proper way how to fix it; locking up the process for one > second is not. > > We used to have high-priority workqueues by default, but it caused audio > playback skipping, so we had to revert it - see > f612b2132db529feac4f965f28a1b9258ea7c22b. > > Perhaps we should add an option to have high-priority kernel threads? Would calling cond_resched() every n iterations instead of every iteration help? From mm/swapfile.c: if (unlikely(--latency_ration < 0)) { cond_resched(); latency_ration = LATENCY_LIMIT; } Thanks, Bart. -- dm-devel mailing list dm-devel@redhat.com https://listman.redhat.com/mailman/listinfo/dm-devel ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [dm-devel] dm-crypt: fix softlockup in dmcrypt_write 2023-03-06 18:16 ` Bart Van Assche @ 2023-03-06 19:03 ` Mikulas Patocka 0 siblings, 0 replies; 12+ messages in thread From: Mikulas Patocka @ 2023-03-06 19:03 UTC (permalink / raw) To: Bart Van Assche; +Cc: yangerkun, agk, Mike Snitzer, dm-devel, yangerkun On Mon, 6 Mar 2023, Bart Van Assche wrote: > On 3/6/23 10:02, Mikulas Patocka wrote: > > On Tue, 28 Feb 2023, yangerkun wrote: > > > It's ok to fix the softlockup, but for async write encrypt, > > > kcryptd_crypt_write_io_submit will add bio to write_tree, and once we > > > call cond_resched before every kcryptd_io_write, the write performance > > > may be poor while we meet a high cpu usage scene. > > > > Hi > > > > To fix this problem, find the PID of the process "dmcrypt_write" and > > change its priority to -20, for example "renice -n -20 -p 34748". > > > > This is the proper way how to fix it; locking up the process for one > > second is not. > > > > We used to have high-priority workqueues by default, but it caused audio > > playback skipping, so we had to revert it - see > > f612b2132db529feac4f965f28a1b9258ea7c22b. > > > > Perhaps we should add an option to have high-priority kernel threads? > > Would calling cond_resched() every n iterations instead of every iteration > help? From mm/swapfile.c: > > if (unlikely(--latency_ration < 0)) { > cond_resched(); > latency_ration = LATENCY_LIMIT; > } > > Thanks, > > Bart. I think that if this helps, it is really a bug in the scheduler... It shouldn't switch tasks so often. Mikulas -- dm-devel mailing list dm-devel@redhat.com https://listman.redhat.com/mailman/listinfo/dm-devel ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [dm-devel] dm-crypt: fix softlockup in dmcrypt_write 2023-02-27 17:55 ` [dm-devel] " Mike Snitzer 2023-02-27 18:03 ` Mike Snitzer @ 2023-02-28 1:25 ` yangerkun 2023-02-28 7:22 ` yangerkun 1 sibling, 1 reply; 12+ messages in thread From: yangerkun @ 2023-02-28 1:25 UTC (permalink / raw) To: Mike Snitzer; +Cc: yangerkun, dm-devel, Bart Van Assche, agk 在 2023/2/28 1:55, Mike Snitzer 写道: > On Sun, Feb 26 2023 at 8:31P -0500, > yangerkun <yangerkun@huaweicloud.com> wrote: > >> >> >> 在 2023/2/26 10:01, Bart Van Assche 写道: >>> On 2/22/23 19:19, yangerkun wrote: >>>> @@ -1924,6 +1926,10 @@ static int dmcrypt_write(void *data) >>>> BUG_ON(rb_parent(write_tree.rb_node)); >>>> + if (time_is_before_jiffies(start_time + HZ)) { >>>> + schedule(); >>>> + start_time = jiffies; >>>> + } >>> >>> Why schedule() instead of cond_resched()? >> >> cond_resched may not really schedule, which may trigger the problem too, but >> it seems after 1 second, it may never happend? > > I had the same question as Bart when reviewing your homegrown > conditional schedule(). Hopefully you can reproduce this issue? If > so, please see if simply using cond_resched() fixes the issue. Yes, our testcase can trigger the issue, will do it with cond_resched. > > Thanks, > Mike -- dm-devel mailing list dm-devel@redhat.com https://listman.redhat.com/mailman/listinfo/dm-devel ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [dm-devel] dm-crypt: fix softlockup in dmcrypt_write 2023-02-28 1:25 ` yangerkun @ 2023-02-28 7:22 ` yangerkun 0 siblings, 0 replies; 12+ messages in thread From: yangerkun @ 2023-02-28 7:22 UTC (permalink / raw) To: yangerkun, Mike Snitzer; +Cc: dm-devel, Bart Van Assche, agk 在 2023/2/28 9:25, yangerkun 写道: > > > 在 2023/2/28 1:55, Mike Snitzer 写道: >> On Sun, Feb 26 2023 at 8:31P -0500, >> yangerkun <yangerkun@huaweicloud.com> wrote: >> >>> >>> >>> 在 2023/2/26 10:01, Bart Van Assche 写道: >>>> On 2/22/23 19:19, yangerkun wrote: >>>>> @@ -1924,6 +1926,10 @@ static int dmcrypt_write(void *data) >>>>> BUG_ON(rb_parent(write_tree.rb_node)); >>>>> + if (time_is_before_jiffies(start_time + HZ)) { >>>>> + schedule(); >>>>> + start_time = jiffies; >>>>> + } >>>> >>>> Why schedule() instead of cond_resched()? >>> >>> cond_resched may not really schedule, which may trigger the problem >>> too, but >>> it seems after 1 second, it may never happend? >> >> I had the same question as Bart when reviewing your homegrown >> conditional schedule(). Hopefully you can reproduce this issue? If >> so, please see if simply using cond_resched() fixes the issue. > > Yes, our testcase can trigger the issue, will do it with cond_resched. Without this patch, the softlockup may trigger soon, after this patch no matter cond_resched or schedule, softlockup won't trigger after two hour test. Thanks, Kun. > > > >> >> Thanks, >> Mike -- dm-devel mailing list dm-devel@redhat.com https://listman.redhat.com/mailman/listinfo/dm-devel ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2023-03-06 19:04 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2023-02-23 3:19 [dm-devel] [PATCH] dm-crypt: fix softlockup in dmcrypt_write yangerkun 2023-02-26 2:01 ` Bart Van Assche 2023-02-27 1:31 ` yangerkun 2023-02-27 17:55 ` [dm-devel] " Mike Snitzer 2023-02-27 18:03 ` Mike Snitzer 2023-02-27 18:06 ` Mike Snitzer 2023-02-28 1:40 ` yangerkun 2023-03-06 18:02 ` Mikulas Patocka 2023-03-06 18:16 ` Bart Van Assche 2023-03-06 19:03 ` Mikulas Patocka 2023-02-28 1:25 ` yangerkun 2023-02-28 7:22 ` yangerkun
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).