From patchwork Mon Feb 6 14:06:12 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Valentin Schneider X-Patchwork-Id: 53308 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:eb09:0:0:0:0:0 with SMTP id s9csp2257336wrn; Mon, 6 Feb 2023 06:13:14 -0800 (PST) X-Google-Smtp-Source: AK7set+q7WLmqgO+3r/xEvJrtTpYrtxByC19VFUa6whoYApOQesoCRUo/Gd4fL5WcpIILjUJsRWL X-Received: by 2002:a17:906:8a63:b0:888:7ce4:1dc1 with SMTP id hy3-20020a1709068a6300b008887ce41dc1mr20464206ejc.26.1675692794237; Mon, 06 Feb 2023 06:13:14 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1675692794; cv=none; d=google.com; s=arc-20160816; b=jc4Ex9VDAjzNh1uBIO6HpQ1NljJLx3OPBTtfx92LzAFUk28PHZbxm5qqa1Yz6v2qRH 9cxkxgca/cctloLUcdC6SkNI/ckI550SHOnkngGJrG8V0hXE9j8Q4XF0g3W7RQbW2duB AjxIVdlLL4vN7mh0ElfugST13v+tBhg1apdPGwSUd2ZEVi0SJNfIOQjt0f7Z7ntrIJcS uNcPeY7JOsMGKEnXBry4jnOA9qsUxVL9IAg7CvDJryUmkrM3+Gx8LE4pgi0/9fUG8uG2 CjTZtso1z5MP4Bct/wRsdlpFHajCG8hV7H5V/13rr7oKbFB4idg430FdIQak91LcPnvU MHDw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=meB2OizL/cB9S6SgA7lRQbUSecNILy6AA+MWTSh41HQ=; b=BhVQiBBsBT/CzxXqFoi5j+AvbqBGzWt0VfisYFEA5TeRU1eybF8LkRXZ6GONGulolb 8nSgnVJB5dzGX2YWumIBmAuuzci7lsL93nAmhEPqkvYuuiq/cH6Uzm3tAqPAhx7wxA1u EYtQAynsGi08YjpX9+V/zdlul0kpxw2xNXIkr9gew402JpUbPhxu1Ryn7M3TqPxUslV4 gD6QYweebpHWfjNiuCso++YcZuhZMv9zuoDbhRof0h+nZqoLrbVzoyNBwEemhMPC+Uio k5d/ih16D5XNMJxQ0lCtgkU/53T94b39sWy4Wr7YDVWddf5S9PH1hTWSsVC+IexTbSyD PXFw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=hIxbtiZb; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id ad7-20020a170907258700b0088d8becaadesi10340250ejc.602.2023.02.06.06.12.51; Mon, 06 Feb 2023 06:13:14 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=hIxbtiZb; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230132AbjBFOMQ (ORCPT + 99 others); Mon, 6 Feb 2023 09:12:16 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55596 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231535AbjBFOLd (ORCPT ); Mon, 6 Feb 2023 09:11:33 -0500 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9AC885257 for ; Mon, 6 Feb 2023 06:09:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1675692510; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=meB2OizL/cB9S6SgA7lRQbUSecNILy6AA+MWTSh41HQ=; b=hIxbtiZb1Nuowj+C8uU5It+kM1DMETAtHJ1z6us0LAQSFHp4rOFLWQXJOZ956384jCdYsI uIfGH9U9ESbjt/2lr/Mf3U+a/gV7e63Xy9IaG9IZJ0bHGxGxvfMxYnSmTgQHuh0LVQTKsM qaheQLPQDhZY2Aq+kPzjdixNeoJgxnQ= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-639-sB-npgPiNNifwFyoTVeRSA-1; Mon, 06 Feb 2023 09:08:28 -0500 X-MC-Unique: sB-npgPiNNifwFyoTVeRSA-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 658D93815EE0; Mon, 6 Feb 2023 14:08:28 +0000 (UTC) Received: from vschneid.remote.csb (unknown [10.33.36.105]) by smtp.corp.redhat.com (Postfix) with ESMTPS id D6E222026D37; Mon, 6 Feb 2023 14:08:26 +0000 (UTC) From: Valentin Schneider To: linux-kernel@vger.kernel.org Cc: Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Daniel Bristot de Oliveira , Eder Zulian Subject: [RFC PATCH v2] sched/deadline: Add more reschedule cases to prio_changed_dl() Date: Mon, 6 Feb 2023 14:06:12 +0000 Message-Id: <20230206140612.701871-1-vschneid@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.4 X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1756747149576044661?= X-GMAIL-MSGID: =?utf-8?q?1757091247348204268?= I've been tracking down an issue on a ~5.17ish kernel where: CPUx CPUy
[idle task keeps running here until *something* accidentally sets TIF_NEED_RESCHED] On that kernel, it is quite easy to trigger using rt-tests's deadline_test [1] with the test running on isolated CPUs (this reduces the chance of something unrelated setting TIF_NEED_RESCHED on the idle tasks, making the issue even more obvious as the hung task detector chimes in). I haven't been able to reproduce this using a mainline kernel, even if I revert 2972e3050e35 ("tracing: Make trace_marker{,_raw} stream-like") which gets rid of the lock involved in the above test, *but* I cannot convince myself the issue isn't there from looking at the code. Make prio_changed_dl() issue a reschedule if the current task isn't a deadline one. While at it, ensure a reschedule is emitted when a queued-but-not-current task gets boosted with an earlier deadline that current's. [1]: https://git.kernel.org/pub/scm/utils/rt-tests/rt-tests.git Signed-off-by: Valentin Schneider Acked-by: Juri Lelli Reviewed-by: Daniel Bristot de Oliveira --- RFCv1 -> RFCv2 ++++++++++++++ o Fixed UP build issue (Juri) --- kernel/sched/deadline.c | 42 ++++++++++++++++++++++++++--------------- 1 file changed, 27 insertions(+), 15 deletions(-) diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c index 0d97d54276cc8..71b24371a6f77 100644 --- a/kernel/sched/deadline.c +++ b/kernel/sched/deadline.c @@ -2663,17 +2663,20 @@ static void switched_to_dl(struct rq *rq, struct task_struct *p) static void prio_changed_dl(struct rq *rq, struct task_struct *p, int oldprio) { - if (task_on_rq_queued(p) || task_current(rq, p)) { + if (!task_on_rq_queued(p)) + return; + #ifdef CONFIG_SMP - /* - * This might be too much, but unfortunately - * we don't have the old deadline value, and - * we can't argue if the task is increasing - * or lowering its prio, so... - */ - if (!rq->dl.overloaded) - deadline_queue_pull_task(rq); + /* + * This might be too much, but unfortunately + * we don't have the old deadline value, and + * we can't argue if the task is increasing + * or lowering its prio, so... + */ + if (!rq->dl.overloaded) + deadline_queue_pull_task(rq); + if (task_current(rq, p)) { /* * If we now have a earlier deadline task than p, * then reschedule, provided p is still on this @@ -2681,15 +2684,24 @@ static void prio_changed_dl(struct rq *rq, struct task_struct *p, */ if (dl_time_before(rq->dl.earliest_dl.curr, p->dl.deadline)) resched_curr(rq); -#else + } else { /* - * Again, we don't know if p has a earlier - * or later deadline, so let's blindly set a - * (maybe not needed) rescheduling point. + * Current may not be deadline in case p was throttled but we + * have just replenished it (e.g. rt_mutex_setprio()). + * + * Otherwise, if p was given an earlier deadline, reschedule. */ - resched_curr(rq); -#endif /* CONFIG_SMP */ + if (!dl_task(rq->curr) || + dl_time_before(p->dl.deadline, rq->curr->dl.deadline)) + resched_curr(rq); } +#else + /* + * We don't know if p has a earlier or later deadline, so let's blindly + * set a (maybe not needed) rescheduling point. + */ + resched_curr(rq); +#endif } DEFINE_SCHED_CLASS(dl) = {