On 4/11/25 03:10, Benjamin Marzinski wrote:
>>> Don't we only need to do that if anything is queued up due to a
>>> suspension? Then again having a different patch might be premature
>>> optimization, it's not like anyone cares about dm-delay performance
>>> almost by definition :)
>>
>> True. I c
On 4/10/25 4:54 PM, Christoph Hellwig wrote:
> On Thu, Apr 10, 2025 at 01:33:11PM +0900, Damien Le Moal wrote:
>> When a dm-delay devie is being suspended, the .presuspend() operation is
>
> s/devie/device/
>
>> first executed (delay_presuspend()) to immediately issue all the BIOs
>> present in t
On Thu, Apr 10, 2025 at 05:02:00PM +0900, Damien Le Moal wrote:
> On 4/10/25 4:54 PM, Christoph Hellwig wrote:
> > On Thu, Apr 10, 2025 at 01:33:11PM +0900, Damien Le Moal wrote:
> >> When a dm-delay devie is being suspended, the .presuspend() operation is
> >
> > s/devie/device/
> >
> >> first e
On Thu, Apr 10, 2025 at 01:33:11PM +0900, Damien Le Moal wrote:
> When a dm-delay devie is being suspended, the .presuspend() operation is
s/devie/device/
> first executed (delay_presuspend()) to immediately issue all the BIOs
> present in the delayed list of the device and also sets the device
>
On 4/10/25 1:33 PM, Damien Le Moal wrote:
> When a dm-delay devie 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 boolean to false. At the same
When a dm-delay devie 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 boolean to false. At the same time, any new BIO is issued to
the device will no
