| From | Thomas Gleixner <> | Subject | Re: [RFC PATCH 54/86] sched: add cond_resched_stall() | Date | Thu, 09 Nov 2023 12:19:34 +0100 |
| |
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.
|