[PATCH] iopoll: use fsleep() instead of usleep_range()

[PATCH] iopoll: use fsleep() instead of usleep_range()

[Jani Nikula]

Sometimes it's necessary to poll with long sleeps, and the accuracy of
usleep_range() is overkill. Use the flexible sleep helper fsleep() for
sleeping in the read_poll_timeout() family of macros to automatically
choose the appropriate method of waiting.

Functionally there are a few consequences for existing users:

- 10 us and shorter sleeps will use usleep() instead of
  usleep_range(). Presumably this will not be an issue.

- When it leads to a slack of less than 25%, msleep() will be used
  instead of usleep_range(). Presumably this will not be an issue, given
  the sleeps will be longer in this case.

- Otherwise, the usleep_range() slack gets switched from the begin of
  the range to the end of the range, i.e. [sleep/2+1..sleep] ->
  [sleep..sleep+sleep/2]. In theory, this could be an issue in some
  cases, but difficult to determine before this hits the real world.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>

---

Not really sure who to Cc, given MAINTAINERS doesn't match this. Adding
some past committers.

Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-kernel@vger.kernel.org
---
 include/linux/iopoll.h | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/include/linux/iopoll.h b/include/linux/iopoll.h
index 91324c331a4b..359ff5ab95de 100644
--- a/include/linux/iopoll.h
+++ b/include/linux/iopoll.h
@@ -20,7 +20,7 @@
  * @val: Variable to read the value into
  * @cond: Break condition (usually involving @val)
  * @sleep_us: Maximum time to sleep between reads in us (0 tight-loops). Please
- *            read usleep_range() function description for details and
+ *            read fsleep() function description for details and
  *            limitations.
  * @timeout_us: Timeout in us, 0 means never timeout
  * @sleep_before_read: if it is true, sleep @sleep_us before read.
@@ -41,7 +41,7 @@
 	ktime_t __timeout = ktime_add_us(ktime_get(), __timeout_us); \
 	might_sleep_if((__sleep_us) != 0); \
 	if (sleep_before_read && __sleep_us) \
-		usleep_range((__sleep_us >> 2) + 1, __sleep_us); \
+		fsleep(__sleep_us); \
 	for (;;) { \
 		(val) = op(args); \
 		if (cond) \
@@ -52,7 +52,7 @@
 			break; \
 		} \
 		if (__sleep_us) \
-			usleep_range((__sleep_us >> 2) + 1, __sleep_us); \
+			fsleep(__sleep_us); \
 		cpu_relax(); \
 	} \
 	(cond) ? 0 : -ETIMEDOUT; \
@@ -120,7 +120,7 @@
  * @val: Variable to read the value into
  * @cond: Break condition (usually involving @val)
  * @sleep_us: Maximum time to sleep between reads in us (0 tight-loops). Please
- *            read usleep_range() function description for details and
+ *            read fsleep() function description for details and
  *            limitations.
  * @timeout_us: Timeout in us, 0 means never timeout
  *
-- 
2.39.5

Re: [PATCH] iopoll: use fsleep() instead of usleep_range()

[Geert Uytterhoeven]

Hi Jani,

Thanks for your patch!

On Thu, 26 Jun 2025 at 16:51, Jani Nikula <jani.nikula@intel.com> wrote:
> Sometimes it's necessary to poll with long sleeps, and the accuracy of
> usleep_range() is overkill. Use the flexible sleep helper fsleep() for
> sleeping in the read_poll_timeout() family of macros to automatically
> choose the appropriate method of waiting.
>
> Functionally there are a few consequences for existing users:
>
> - 10 us and shorter sleeps will use usleep() instead of

s/usleep/udelay/.

>   usleep_range(). Presumably this will not be an issue.

Note that udelay() does not sleep, but loops.

>
> - When it leads to a slack of less than 25%, msleep() will be used
>   instead of usleep_range(). Presumably this will not be an issue, given
>   the sleeps will be longer in this case.
>
> - Otherwise, the usleep_range() slack gets switched from the begin of
>   the range to the end of the range, i.e. [sleep/2+1..sleep] ->
>   [sleep..sleep+sleep/2]. In theory, this could be an issue in some
>   cases, but difficult to determine before this hits the real world.
>
> Signed-off-by: Jani Nikula <jani.nikula@intel.com>

> Not really sure who to Cc, given MAINTAINERS doesn't match this. Adding
> some past committers.

Oh well ;-)

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH] iopoll: use fsleep() instead of usleep_range()

[Jani Nikula]

On Thu, 26 Jun 2025, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> Hi Jani,
>
> Thanks for your patch!
>
> On Thu, 26 Jun 2025 at 16:51, Jani Nikula <jani.nikula@intel.com> wrote:
>> Sometimes it's necessary to poll with long sleeps, and the accuracy of
>> usleep_range() is overkill. Use the flexible sleep helper fsleep() for
>> sleeping in the read_poll_timeout() family of macros to automatically
>> choose the appropriate method of waiting.
>>
>> Functionally there are a few consequences for existing users:
>>
>> - 10 us and shorter sleeps will use usleep() instead of
>
> s/usleep/udelay/.

D'oh!

>
>>   usleep_range(). Presumably this will not be an issue.
>
> Note that udelay() does not sleep, but loops.

Quite right. IIUC this is because for short delays it's more efficient.

BR,
Jani.

>
>>
>> - When it leads to a slack of less than 25%, msleep() will be used
>>   instead of usleep_range(). Presumably this will not be an issue, given
>>   the sleeps will be longer in this case.
>>
>> - Otherwise, the usleep_range() slack gets switched from the begin of
>>   the range to the end of the range, i.e. [sleep/2+1..sleep] ->
>>   [sleep..sleep+sleep/2]. In theory, this could be an issue in some
>>   cases, but difficult to determine before this hits the real world.
>>
>> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
>
>> Not really sure who to Cc, given MAINTAINERS doesn't match this. Adding
>> some past committers.
>
> Oh well ;-)
>
> Gr{oetje,eeting}s,
>
>                         Geert

-- 
Jani Nikula, Intel

Re: [PATCH] iopoll: use fsleep() instead of usleep_range()

[Andi Shyti]

Hi Jani,

On Thu, Jun 26, 2025 at 05:51:19PM +0300, Jani Nikula wrote:
> Sometimes it's necessary to poll with long sleeps, and the accuracy of
> usleep_range() is overkill. Use the flexible sleep helper fsleep() for
> sleeping in the read_poll_timeout() family of macros to automatically
> choose the appropriate method of waiting.
> 
> Functionally there are a few consequences for existing users:
> 
> - 10 us and shorter sleeps will use usleep() instead of
>   usleep_range(). Presumably this will not be an issue.
> 
> - When it leads to a slack of less than 25%, msleep() will be used
>   instead of usleep_range(). Presumably this will not be an issue, given
>   the sleeps will be longer in this case.
> 
> - Otherwise, the usleep_range() slack gets switched from the begin of
>   the range to the end of the range, i.e. [sleep/2+1..sleep] ->
>   [sleep..sleep+sleep/2]. In theory, this could be an issue in some
>   cases, but difficult to determine before this hits the real world.
> 
> Signed-off-by: Jani Nikula <jani.nikula@intel.com>

this patch makes sense to me even with the fixes in the commit
message suggested byt Geert.

Reviewed-by: Andi Shyti <andi.shyti@kernel.org>

Andi

Re: [PATCH] iopoll: use fsleep() instead of usleep_range()

[Jani Nikula]

On Wed, 02 Jul 2025, Andi Shyti <andi.shyti@kernel.org> wrote:
> Hi Jani,
>
> On Thu, Jun 26, 2025 at 05:51:19PM +0300, Jani Nikula wrote:
>> Sometimes it's necessary to poll with long sleeps, and the accuracy of
>> usleep_range() is overkill. Use the flexible sleep helper fsleep() for
>> sleeping in the read_poll_timeout() family of macros to automatically
>> choose the appropriate method of waiting.
>> 
>> Functionally there are a few consequences for existing users:
>> 
>> - 10 us and shorter sleeps will use usleep() instead of
>>   usleep_range(). Presumably this will not be an issue.
>> 
>> - When it leads to a slack of less than 25%, msleep() will be used
>>   instead of usleep_range(). Presumably this will not be an issue, given
>>   the sleeps will be longer in this case.
>> 
>> - Otherwise, the usleep_range() slack gets switched from the begin of
>>   the range to the end of the range, i.e. [sleep/2+1..sleep] ->
>>   [sleep..sleep+sleep/2]. In theory, this could be an issue in some
>>   cases, but difficult to determine before this hits the real world.
>> 
>> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
>
> this patch makes sense to me even with the fixes in the commit
> message suggested byt Geert.
>
> Reviewed-by: Andi Shyti <andi.shyti@kernel.org>

Thanks! However I think Ville's series [1] should have more priority
here. It's mostly orthogonal, but IMO it's more important and should go
first. I can follow up with this one afterwards.

BR,
Jani.


[1] https://lore.kernel.org/r/20250702223439.19752-1-ville.syrjala@linux.intel.com

-- 
Jani Nikula, Intel