On Tue, Nov 07 2023 at 13:57, Ankur Arora wrote:
> The kernel has a lot of intances of cond_resched() where it is used
> as an alternative to spinning in a tight-loop while waiting to
> retry an operation, or while waiting for a device state to change.
>
> Unfortunately, because the scheduler is unlikely to have an
> interminable supply of runnable tasks on the runqueue, this just
> amounts to spinning in a tight-loop with a cond_resched().
> (When running in a fully preemptible kernel, cond_resched()
> calls are stubbed out so it amounts to even less.)
>
> In sum, cond_resched() in error handling/retry contexts might
> be useful in avoiding softlockup splats, but not very good at
> error handling. Ideally, these should be replaced with some kind
> of timed or event wait.
>
> For now add cond_resched_stall(), which tries to schedule if
> possible, and failing that executes a cpu_relax().
What's the point of this new variant of cond_resched()? We really do not
want it at all.
> +int __cond_resched_stall(void)
> +{
> + if (tif_need_resched(RESCHED_eager)) {
> + __preempt_schedule();
Under the new model TIF_NEED_RESCHED is going to reschedule if the
preemption counter goes to zero.
So the typical
while (readl(mmio) & BUSY)
cpu_relax();
will just be preempted like any other loop, no?
Confused.
