On Mon, Apr 14, 2025 at 12:53:15PM -0400, Benjamin Marzinski wrote:
> On Mon, Apr 14, 2025 at 03:52:18PM +0200, Mikulas Patocka wrote:
> >
> >
> > On Fri, 11 Apr 2025, Benjamin Marzinski wrote:
> >
> > > When using a kthread to delay the IOs, dm-delay would continuously loop,
> > > checking if I
On Mon, 14 Apr 2025, Benjamin Marzinski wrote:
> > cond_resched() shouldn't be removed because fsleep may fall back to
> > udelay.
>
> Again, your version is fine, but I'm not sure that cond_resched() was
> ever necessary, since there already is one in flush_delayed_bios().
> Also, at least t
On Mon, Apr 14, 2025 at 03:52:18PM +0200, Mikulas Patocka wrote:
>
>
> On Fri, 11 Apr 2025, Benjamin Marzinski wrote:
>
> > When using a kthread to delay the IOs, dm-delay would continuously loop,
> > checking if IOs were ready to submit. It had a cond_resched() call in
> > the loop, but might s
On Fri, 11 Apr 2025, Benjamin Marzinski wrote:
> When using a kthread to delay the IOs, dm-delay would continuously loop,
> checking if IOs were ready to submit. It had a cond_resched() call in
> the loop, but might still loop hundreds of millions of times waiting for
> an IO that was scheduled
On 4/12/25 5:56 AM, Benjamin Marzinski wrote:
> When using a kthread to delay the IOs, dm-delay would continuously loop,
> checking if IOs were ready to submit. It had a cond_resched() call in
> the loop, but might still loop hundreds of millions of times waiting for
> an IO that was scheduled to b
On 4/12/25 5:56 AM, Benjamin Marzinski wrote:
> When using a kthread to delay the IOs, dm-delay would continuously loop,
> checking if IOs were ready to submit. It had a cond_resched() call in
> the loop, but might still loop hundreds of millions of times waiting for
> an IO that was scheduled to b
On Fri, Apr 11, 2025 at 04:56:56PM -0400, Benjamin Marzinski wrote:
> When using a kthread to delay the IOs, dm-delay would continuously loop,
> checking if IOs were ready to submit. It had a cond_resched() call in
> the loop, but might still loop hundreds of millions of times waiting for
> an IO t
When using a kthread to delay the IOs, dm-delay would continuously loop,
checking if IOs were ready to submit. It had a cond_resched() call in
the loop, but might still loop hundreds of millions of times waiting for
an IO that was scheduled to be submitted 10s of ms in the future. With
the change t
