Le lun. 7 avr. 2025 à 16:42, Martin Wilck a écrit :
>
> On Mon, 2025-04-07 at 12:53 +0200, Yoann Congal wrote:
> > Hello,
> >
> > Le lun. 7 avr. 2025 à 12:32, Martin Wilck a écrit :
> > >
> > > On Mon, 2025-04-07 at 10:53 +0200, Martin Wilck wrote:
> > > > On Fri, 2025-04-04 at 14:29 +0200, Sofia
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
On Fri, Apr 11, 2025 at 09:04:35AM +0900, Damien Le Moal wrote:
> When a dm-delay device is being suspended, the .presuspend() operation
> is first executed (delay_presuspend()) to immediately issue all the BIOs
> present in the delayed list of the device and also sets the device
> may_delay boolea
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
On Fri, 11 Apr 2025, Damien Le Moal wrote:
> On 4/11/25 04:49, Benjamin Marzinski wrote:
> > There were multiple places in dm's __bind() function where it could fail
> > and not completely roll back, leaving the device using the the old
> > table, but with device limits and resources from the n
On 4/11/25 04:49, Benjamin Marzinski wrote:
> There were multiple places in dm's __bind() function where it could fail
> and not completely roll back, leaving the device using the the old
> table, but with device limits and resources from the new table.
> Additionally, unused mempools for request-b
