On 7/16/23 1:11?PM, Andres Freund wrote:
> Hi,
>
> On 2023-07-16 12:13:45 -0600, Jens Axboe wrote:
>> Here's one for 6.1-stable.
>
> Thanks for working on that!
>
>
>> diff --git a/io_uring/io_uring.c b/io_uring/io_uring.c
>> index cc35aba1e495..de117d3424b2 100644
>> --- a/io_uring/io_uring.c
>> +++ b/io_uring/io_uring.c
>> @@ -2346,7 +2346,7 @@ static inline int io_cqring_wait_schedule(struct io_ring_ctx *ctx,
>> struct io_wait_queue *iowq,
>> ktime_t *timeout)
>> {
>> - int ret;
>> + int token, ret;
>> unsigned long check_cq;
>>
>> /* make sure we run task_work before checking for signals */
>> @@ -2362,9 +2362,18 @@ static inline int io_cqring_wait_schedule(struct io_ring_ctx *ctx,
>> if (check_cq & BIT(IO_CHECK_CQ_DROPPED_BIT))
>> return -EBADR;
>> }
>> +
>> + /*
>> + * Use io_schedule_prepare/finish, so cpufreq can take into account
>> + * that the task is waiting for IO - turns out to be important for low
>> + * QD IO.
>> + */
>> + token = io_schedule_prepare();
>> + ret = 0;
>> if (!schedule_hrtimeout(timeout, HRTIMER_MODE_ABS))
>> - return -ETIME;
>> - return 1;
>> + ret = -ETIME;
>> + io_schedule_finish(token);
>> + return ret;
>> }
>
> To me it looks like this might have changed more than intended? Previously
> io_cqring_wait_schedule() returned 0 in case schedule_hrtimeout() returned
> non-zero, now io_cqring_wait_schedule() returns 1 in that case? Am I missing
> something?
Ah shoot yes indeed. Greg, can you drop the 5.10/5.15/6.1 ones for now?
I'll get it sorted tomorrow. Sorry about that, and thanks for catching
that Andres!
--
Jens Axboe
