Replace msleep(1) with usleep_range(1000, 2000) in the queue reset
loops.
msleep(1) relies on jiffies and can sleep up to 4-10 ms depending on HZ,
whereas usleep_range provides predictable microsecond-level delay.

Signed-off-by: Mirza Ishan Beg <seedandsyntax@gmail.com>
---
 drivers/virtio/virtio_pci_modern_dev.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/virtio/virtio_pci_modern_dev.c b/drivers/virtio/virtio_pci_modern_dev.c
index 413a8c353463..8e74a813ca97 100644
--- a/drivers/virtio/virtio_pci_modern_dev.c
+++ b/drivers/virtio/virtio_pci_modern_dev.c
@@ -535,10 +535,10 @@ void vp_modern_set_queue_reset(struct virtio_pci_modern_device *mdev, u16 index)
 	vp_iowrite16(1, &cfg->queue_reset);
 
 	while (vp_ioread16(&cfg->queue_reset))
-		msleep(1);
+		usleep_range(1000, 2000);
 
 	while (vp_ioread16(&cfg->cfg.queue_enable))
-		msleep(1);
+		usleep_range(1000, 2000);
 }
 EXPORT_SYMBOL_GPL(vp_modern_set_queue_reset);
 
-- 
2.47.3

On Sun, Aug 16, 2026 at 03:13:19PM +0530, Mirza Ishan Beg wrote:
> Replace msleep(1) with usleep_range(1000, 2000) in the queue reset
> loops.
> msleep(1) relies on jiffies and can sleep up to 4-10 ms depending on HZ,
> whereas usleep_range provides predictable microsecond-level delay.
> 
> Signed-off-by: Mirza Ishan Beg <seedandsyntax@gmail.com>

why do we care?

> ---
>  drivers/virtio/virtio_pci_modern_dev.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/virtio/virtio_pci_modern_dev.c b/drivers/virtio/virtio_pci_modern_dev.c
> index 413a8c353463..8e74a813ca97 100644
> --- a/drivers/virtio/virtio_pci_modern_dev.c
> +++ b/drivers/virtio/virtio_pci_modern_dev.c
> @@ -535,10 +535,10 @@ void vp_modern_set_queue_reset(struct virtio_pci_modern_device *mdev, u16 index)
>  	vp_iowrite16(1, &cfg->queue_reset);
>  
>  	while (vp_ioread16(&cfg->queue_reset))
> -		msleep(1);
> +		usleep_range(1000, 2000);
>  
>  	while (vp_ioread16(&cfg->cfg.queue_enable))
> -		msleep(1);
> +		usleep_range(1000, 2000);
>  }
>  EXPORT_SYMBOL_GPL(vp_modern_set_queue_reset);
>  
> -- 
> 2.47.3

On Sun, Aug 16, 2026 at 05:38:06PM -0400, Michael S. Tsirkin wrote:
> why do we care?

Hi Michael,

The motivation originally came from a checkpatch.pl warning, but looking directly at Documentation/timers/timers-howto.rst, there is a practical penalty here.

The documentation explicitly notes for the 1-20ms range: "msleep(1~20) may not do what the caller intends, and will often sleep longer (~20 ms actual sleep for any value given in the 1~20ms range)."

In these queue reset loops, using msleep(1) means each iteration may be extended to 10-20ms depending on HZ and timer slack. The document recommends using usleep_range() to avoid this overhead and provide the intended precision.

Let me know if you'd like this explanation folded into a v2 commit message.

--
Mirza

On Mon, Aug 17, 2026 at 10:33:31PM +0530, Mirza Ishan Beg wrote:
> On Sun, Aug 16, 2026 at 05:38:06PM -0400, Michael S. Tsirkin wrote:
> > why do we care?
> 
> Hi Michael,
> 
> The motivation originally came from a checkpatch.pl warning, but looking directly at Documentation/timers/timers-howto.rst,
> there is a practical penalty here.
> 
> The documentation explicitly notes for the 1-20ms range: "msleep(1~20) may not do what the caller intends, and will often sleep longer (~20 ms actual sleep for any value given in the 1~20ms range)."
> 
> In these queue reset loops, using msleep(1) means each iteration may be extended to 10-20ms depending on HZ and timer slack. The document recommends using usleep_range() to avoid this overhead and provide the intended precision.
> 
> Let me know if you'd like this explanation folded into a v2 commit message.
> 
> --
> Mirza

I don't think we care anyway. We probably just want fsleep?