From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 33F89E555 for ; Wed, 14 Jan 2026 14:20:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768400457; cv=none; b=abUpmv2R+NEGPvohHTQhZb4mfMGi4wOkzSKrNqxUMUzATMqZsxR6DQ4hYbDTKC+0VlB2BvwtYpmSJ3UzebRqa7tfnjrmKvIfxxo47kIU66GkmLJ26A6vKSE3wGOYkIVqr3GkPvV1x3XAx97YQ/SO9Zprr3zskT5Bqi+GlpSkaAw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768400457; c=relaxed/simple; bh=XMj4ssOkyrzw5suqQ9n8OiEK3bHMp4fUmo//LSS0zBE=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=ZeaIVvGq1yd67Q+pxBlM0lSAH48YeEI0UERBOwj31sBaC9OddTrv5zKfp3kGHyj/C0KNaeYi+bJD7inCPgKX3Vej6BWWr29IICw90F7fYGmp97LkL5MGu6xk0pos/I2ZOY6xuIhsDpmGQOuiMaD8CEd6Sq8Agx6q8pOQWjacnNg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=XueP6IYn; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=WKjEwBc+; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="XueP6IYn"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="WKjEwBc+" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1768400454; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=nAAVPKAhdXdYSTKcBmSZbQ487SONxLb+XK4TvVsSDGA=; b=XueP6IYnQU1FhWnVDl28TlR2t2QFgwL71xp0Z2mAj2o+G68M4tCyMnaCLMwLdiu3Q9ronA N0+dXLNIRhfplYFUl8nyQ8PTYgmKNcPMyf/mzisfPdOBLLWSDSUV2ewpLWqF295jXoEjdI z9RdQ2TaRNNXtYSWNEYxWwPKTuKQJi0= Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-208-t8fruGz_PBy8Mz1k-PVU7A-1; Wed, 14 Jan 2026 09:20:53 -0500 X-MC-Unique: t8fruGz_PBy8Mz1k-PVU7A-1 X-Mimecast-MFC-AGG-ID: t8fruGz_PBy8Mz1k-PVU7A_1768400452 Received: by mail-wr1-f71.google.com with SMTP id ffacd0b85a97d-43284edbbc8so5899143f8f.0 for ; Wed, 14 Jan 2026 06:20:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1768400452; x=1769005252; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=nAAVPKAhdXdYSTKcBmSZbQ487SONxLb+XK4TvVsSDGA=; b=WKjEwBc+DpI6RF0VGtR5pUebMvX8hPtm/CYlh0EOVt1FAN907qFoOAEI4Enq9NcrkA C2Y/EYemCbiBhSb7xuFfHWL3k6mVsXdnO4hDIplMA52t4L5j1p3r91MswABmHOyuYxBY pY7+bgrQ04AY3No0B3K3RWGMPxgLcIj8+2Wj83vyozSMRQPQs2WKfaEyrpMV7wBAQ8bM uYR6w2Gv1QqYvG7kK6n4Lvp8XAaskGc1ZhNmDEPC6CMx0v2JmqtEvhvcLlVkmihwwR/f 6pf+Z3AE0YEIXbxrKjd5I4Q2XdiO0464UzAoUcQ3XSQkfiqKQgm+XLWw/CTHgAIwW/d9 QK4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768400452; x=1769005252; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=nAAVPKAhdXdYSTKcBmSZbQ487SONxLb+XK4TvVsSDGA=; b=Ajv6jcdW9hDfH+FwzVIV6VlVRUwL+XmwDiSgd5r4XluGX9uN2inFjCc1DItNPI29Ox IBX4BzF78+L0pyNjnLMSMP+3YfEBvHcsZLLnWVm36QYv1/FcwgeViU8+DH7CjsJLl7+6 ixQtkS8me6W7NVjNVMJqveesLwLAZgwgdJ4C+WaMqLleF8cKkWyTbxmnXJa3LL2qHU6B jng++tuY99uG1jWE5hB7yOXAycfWMTtOKEwMEG+o7HoKqkAZynWeD1D5AKnHlqyfOjxC bxMuCXfaQSp6JdK01NiV39TJRkEIkrsfWL9b1kgPw9sZ1mSNB0b3NwWNCqJr4RHplWC2 AtKQ== X-Forwarded-Encrypted: i=1; AJvYcCU630w/kloDccRucBMJV/Uf9nTWFBJiRsVVu6UT5jVFoWuzRJrQKXlbErFu+GTgsXRpgdRxJhxBGl16E+Q=@vger.kernel.org X-Gm-Message-State: AOJu0YwRzXN5GsXmYXfb3QAkHFq5jvga+l24Zuu+HdRPiygNeLyZQEji a++hLUW1r/y83Fc7kx9F7pv6sgETOB7wN36abwTDkvhRM95tmjPou8DCHcM3djhszVcx9pLu5ud SHGBU39dLiolQrTSxKi7M4YZLZ6HsdBPA3uyS8D3bYHDUv0kPI5Kdh5yVPqKBKEiCnA== X-Gm-Gg: AY/fxX7Zg1RD427OH7D5iihhb2nNQ8X5dfovlCIRQi2adcOkGL/rb3FN4XI1My92UTe 6jTCdIgWnGUkZCM9dL+uzkZcvxdJZvjSEMVflEaXpCLg/6aE0YAea3DPUFUW6VZCJR7/l2HSBz3 S5BX/92VS0gbdzuok/AXZ7hoZjD4dVZXmQ1S65VAz3bX/DaNwlpOHOgLSCTjDVnPjtg8ecAvfrA ArsT7kT9g4hYMS+oK+IQVJxzcniTwdX+etTWOWMqL5WAc95B6htbA2hRbwGwOU751ZQ0nu5rRLq CNiyGAa3rER+f4NK9lhRrAqSsrsXBDDSu6uMzQHV9AJdDvm4Thks0BWT2cZWdI0GERmXqvDt4tu 9F2gjcMah3sRajMGPetb8mwU+EcCvytHbOTQrQAjW X-Received: by 2002:a05:6000:200d:b0:430:fd9f:e6e2 with SMTP id ffacd0b85a97d-4342c4ee846mr2866422f8f.9.1768400451816; Wed, 14 Jan 2026 06:20:51 -0800 (PST) X-Received: by 2002:a05:6000:200d:b0:430:fd9f:e6e2 with SMTP id ffacd0b85a97d-4342c4ee846mr2866361f8f.9.1768400451309; Wed, 14 Jan 2026 06:20:51 -0800 (PST) Received: from jlelli-thinkpadt14gen4.remote.csb ([151.29.129.40]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-432bd0e180csm48924149f8f.10.2026.01.14.06.20.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 14 Jan 2026 06:20:50 -0800 (PST) Date: Wed, 14 Jan 2026 15:20:48 +0100 From: Juri Lelli To: Peter Zijlstra Cc: K Prateek Nayak , Pierre Gondois , tj@kernel.org, linux-kernel@vger.kernel.org, mingo@kernel.org, vincent.guittot@linaro.org, dietmar.eggemann@arm.com, rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de, vschneid@redhat.com, longman@redhat.com, hannes@cmpxchg.org, mkoutny@suse.com, void@manifault.com, arighi@nvidia.com, changwoo@igalia.com, cgroups@vger.kernel.org, sched-ext@lists.linux.dev, liuwenfang@honor.com, tglx@linutronix.de, Christian Loehle , luca.abeni@santannapisa.it Subject: Re: [PATCH 05/12] sched: Move sched_class::prio_changed() into the change pattern Message-ID: References: <20251006104402.946760805@infradead.org> <20251006104527.083607521@infradead.org> <717a0743-6d8f-4e35-8f2f-70a158b31147@arm.com> <20260113114718.GA831050@noisy.programming.kicks-ass.net> <20260114102336.GZ830755@noisy.programming.kicks-ass.net> <20260114130528.GB831285@noisy.programming.kicks-ass.net> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260114130528.GB831285@noisy.programming.kicks-ass.net> On 14/01/26 14:05, Peter Zijlstra wrote: > On Wed, Jan 14, 2026 at 11:23:36AM +0100, Peter Zijlstra wrote: > > > Juri, Luca, I'm tempted to suggest to simply remove the replenish on > > RESTORE entirely -- that would allow the task to continue as it had > > been, irrespective of it being 'late'. > > > > Something like so -- what would this break? > > > > --- a/kernel/sched/deadline.c > > +++ b/kernel/sched/deadline.c > > @@ -2214,10 +2214,6 @@ enqueue_dl_entity(struct sched_dl_entity > > update_dl_entity(dl_se); > > } else if (flags & ENQUEUE_REPLENISH) { > > replenish_dl_entity(dl_se); > > - } else if ((flags & ENQUEUE_RESTORE) && > > - !is_dl_boosted(dl_se) && > > - dl_time_before(dl_se->deadline, rq_clock(rq_of_dl_se(dl_se)))) { > > - setup_new_dl_entity(dl_se); > > } > > > > /* > > Ah, this is de-boost, right? Boosting allows one to break the CBS rules > and then we have to rein in the excesses. > > But we have {DE,EN}QUEUE_MOVE for this, that explicitly allows priority > to change and is set for rt_mutex_setprio() (among others). > > So doing s/RESTORE/MOVE/ above. > > The corollary to all this is that everybody that sets MOVE must be able > to deal with balance callbacks, so audit that too. > > This then gives something like so.. which builds and boots for me, but > clearly I haven't been able to trigger these funny cases. > > --- > --- a/kernel/sched/core.c > +++ b/kernel/sched/core.c > @@ -4969,9 +4969,13 @@ struct balance_callback *splice_balance_ > return __splice_balance_callbacks(rq, true); > } > > -static void __balance_callbacks(struct rq *rq) > +void __balance_callbacks(struct rq *rq, struct rq_flags *rf) > { > + if (rf) > + rq_unpin_lock(rq, rf); > do_balance_callbacks(rq, __splice_balance_callbacks(rq, false)); > + if (rf) > + rq_repin_lock(rq, rf); > } > > void balance_callbacks(struct rq *rq, struct balance_callback *head) > @@ -5018,7 +5022,7 @@ static inline void finish_lock_switch(st > * prev into current: > */ > spin_acquire(&__rq_lockp(rq)->dep_map, 0, 0, _THIS_IP_); > - __balance_callbacks(rq); > + __balance_callbacks(rq, NULL); > raw_spin_rq_unlock_irq(rq); > } > > @@ -6901,7 +6905,7 @@ static void __sched notrace __schedule(i > proxy_tag_curr(rq, next); > > rq_unpin_lock(rq, &rf); > - __balance_callbacks(rq); > + __balance_callbacks(rq, NULL); > raw_spin_rq_unlock_irq(rq); > } > trace_sched_exit_tp(is_switch); > @@ -7350,7 +7354,7 @@ void rt_mutex_setprio(struct task_struct > trace_sched_pi_setprio(p, pi_task); > oldprio = p->prio; > > - if (oldprio == prio) > + if (oldprio == prio && !dl_prio(prio)) > queue_flag &= ~DEQUEUE_MOVE; > > prev_class = p->sched_class; > @@ -7396,9 +7400,7 @@ void rt_mutex_setprio(struct task_struct > out_unlock: > /* Caller holds task_struct::pi_lock, IRQs are still disabled */ > > - rq_unpin_lock(rq, &rf); > - __balance_callbacks(rq); > - rq_repin_lock(rq, &rf); > + __balance_callbacks(rq, &rf); > __task_rq_unlock(rq, p, &rf); > } > #endif /* CONFIG_RT_MUTEXES */ > @@ -9167,6 +9169,8 @@ void sched_move_task(struct task_struct > > if (resched) > resched_curr(rq); > + > + __balance_callbacks(rq, &rq_guard.rf); > } > > static struct cgroup_subsys_state * > @@ -10891,6 +10895,9 @@ void sched_change_end(struct sched_chang > resched_curr(rq); > } > } else { > + /* > + * XXX validate prio only really changed when ENQUEUE_MOVE is set. > + */ > p->sched_class->prio_changed(rq, p, ctx->prio); > } > } > --- a/kernel/sched/deadline.c > +++ b/kernel/sched/deadline.c > @@ -2214,9 +2214,14 @@ enqueue_dl_entity(struct sched_dl_entity > update_dl_entity(dl_se); > } else if (flags & ENQUEUE_REPLENISH) { > replenish_dl_entity(dl_se); > - } else if ((flags & ENQUEUE_RESTORE) && > + } else if ((flags & ENQUEUE_MOVE) && > !is_dl_boosted(dl_se) && > dl_time_before(dl_se->deadline, rq_clock(rq_of_dl_se(dl_se)))) { > + /* > + * Deals with the de-boost case, and ENQUEUE_MOVE explicitly > + * allows us to change priority. Callers are expected to deal > + * with balance_callbacks. > + */ > setup_new_dl_entity(dl_se); > } > > --- a/kernel/sched/ext.c > +++ b/kernel/sched/ext.c > @@ -545,6 +545,7 @@ static void scx_task_iter_start(struct s > static void __scx_task_iter_rq_unlock(struct scx_task_iter *iter) > { > if (iter->locked_task) { > + __balance_callbacks(iter->rq, &iter->rf); > task_rq_unlock(iter->rq, iter->locked_task, &iter->rf); > iter->locked_task = NULL; > } > --- a/kernel/sched/sched.h > +++ b/kernel/sched/sched.h > @@ -2430,7 +2430,8 @@ extern const u32 sched_prio_to_wmult[40 > * should preserve as much state as possible. > * > * MOVE - paired with SAVE/RESTORE, explicitly does not preserve the location > - * in the runqueue. > + * in the runqueue. IOW the priority is allowed to change. Callers > + * must expect to deal with balance callbacks. > * > * NOCLOCK - skip the update_rq_clock() (avoids double updates) > * > @@ -4019,6 +4020,8 @@ extern void enqueue_task(struct rq *rq, > extern bool dequeue_task(struct rq *rq, struct task_struct *p, int flags); > > extern struct balance_callback *splice_balance_callbacks(struct rq *rq); > + > +extern void __balance_callbacks(struct rq *rq, struct rq_flags *rf); > extern void balance_callbacks(struct rq *rq, struct balance_callback *head); > > /* > --- a/kernel/sched/syscalls.c > +++ b/kernel/sched/syscalls.c > @@ -639,7 +639,7 @@ int __sched_setscheduler(struct task_str > * itself. > */ > newprio = rt_effective_prio(p, newprio); > - if (newprio == oldprio) > + if (newprio == oldprio && !dl_prio(newprio)) > queue_flags &= ~DEQUEUE_MOVE; > } We have been using (improperly?) ENQUEUE_SAVE also to know when a new entity gets setscheduled to DEADLINE (or its parameters are changed) and it looks like this keeps that happening with DEQUEUE_MOVE. So, from a quick first look, it does sound good to me. Thanks! Juri