On Wed, Aug 28, 2024 at 08:17:06PM +0200, Valentin Schneider wrote: > On 28/08/24 09:35, Paul E. McKenney wrote: > > On Wed, Aug 28, 2024 at 04:32:41PM +0200, Valentin Schneider wrote: > >> On 28/08/24 21:44, Chen Yu wrote: > >> > > >> > 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!!! > > Fantastic, I'll hammer this into a "proper" patch then. Thanks again for > all the testing! > > > 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... > > :-) The 500*TREE03 run had exactly one failure that was the dreaded enqueue_dl_entity() failure, followed by RCU CPU stall warnings. But a huge improvement over the prior state! Plus, this failure is likely unrelated (see earlier discussions with Peter). I just started a 5000*TREE03 run, just in case we can now reproduce this thing. Thanx, Paul