On Wed, Aug 28, 2024 at 04:32:41PM +0200, Valentin Schneider wrote:
> On 28/08/24 21:44, Chen Yu wrote:
> > Hi,
> >
> > On 2024-08-28 at 14:35:45 +0200, Valentin Schneider wrote:
> >> On 27/08/24 13:36, Paul E. McKenney wrote:
> >> > On Tue, Aug 27, 2024 at 10:30:24PM +0200, Valentin Schneider wrote:
> >> >>
> >> >> Thanks for the testing!
> >> >>
> >> >> The WARN_ON_ONCE(!rt_se->on_list); hit in __dequeue_rt_entity() feels like
> >> >> a put_prev/set_next kind of issue...
> >> >>
> >> >> So far I'd assumed a ->sched_delayed task can't be current during
> >> >> switched_from_fair(), I got confused because it's Mond^CCC Tuesday, but I
> >> >> think that still holds: we can't get a balance_dl() or balance_rt() to drop
> >> >> the RQ lock because prev would be fair, and we can't get a
> >> >> newidle_balance() with a ->sched_delayed task because we'd have
> >> >> sched_fair_runnable() := true.
> >> >>
> >> >> I'll pick this back up tomorrow, this is a task that requires either
> >> >> caffeine or booze and it's too late for either.
> >> >
> >> > Thank you for chasing this, and get some sleep! This one is of course
> >> > annoying, but it is not (yet) an emergency. I look forward to seeing
> >> > what you come up with.
> >> >
> >> > Also, I would of course be happy to apply debug patches.
> >> >
> >> > Thanx, Paul
> >>
> >> Chen Yu made me realize [1] that dequeue_task() really isn't enough; the
> >> dequeue_task() in e.g. __sched_setscheduler() won't have DEQUEUE_DELAYED,
> >> so stuff will just be left on the CFS tree.
> >>
> >
> > One question, although there is no DEQUEUE_DELAYED flag, it is possible
> > the delayed task could be dequeued from CFS tree. Because the dequeue in
> > set_schedule() does not have DEQUEUE_SLEEP. And in dequeue_entity():
> >
> > bool sleep = flags & DEQUEUE_SLEEP;
> >
> > if (flags & DEQUEUE_DELAYED) {
> >
> > } else {
> > bool delay = sleep;
> > if (sched_feat(DELAY_DEQUEUE) && delay && //false
> > !entity_eligible(cfs_rq, se) {
> > //do not dequeue
> > }
> > }
> >
> > //dequeue the task <---- we should reach here?
> >
>
> You're quite right, so really here the main missing bit would be the final
> __block_task() that a DEQUEUE_DELAYED dequeue_entities() would get us.
50*TREE03 passed, yay! Thank you both!!!
I started a 500*TREE03.
Yes, the odds all 50 passing given the baseline 52% failure rate is
something like 10^-16, but software bugs are not necessarily constrained
by elementary statistics...
Thanx, Paul
