From nobody Sun May 10 22:40:31 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1CE86C433F5 for ; Fri, 22 Apr 2022 09:15:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1445855AbiDVJRv (ORCPT ); Fri, 22 Apr 2022 05:17:51 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60222 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1445880AbiDVJNG (ORCPT ); Fri, 22 Apr 2022 05:13:06 -0400 Received: from mail-pg1-x52b.google.com (mail-pg1-x52b.google.com [IPv6:2607:f8b0:4864:20::52b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 00647B847 for ; Fri, 22 Apr 2022 02:10:13 -0700 (PDT) Received: by mail-pg1-x52b.google.com with SMTP id s137so6878136pgs.5 for ; Fri, 22 Apr 2022 02:10:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance-com.20210112.gappssmtp.com; s=20210112; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=GjFkrXQ0Jf/Wo7tGCVQoupglponKlDpocPGzJ8nG08w=; b=DDbB6iljrKJeU3qyRiGqdLSHMyhTawsIWDhe0PWmZe8MVf39FywzhzvbW1USrCX6xA SEqCVJl4CGpepPI+/tTd6QMAg2Y2VFHQI7m7HMbfnHJEPT5FgDdeCGrgcm2wWSV/rXHm 34N3s6OlJo3O4crhMHesKaXtASOU3OHzbZBuI9yvOeeB1r6yPDIZNi0P3gfbeV5YzGI8 4N0t/K4BKo0sQWUZjuWoFkWIPFAYAiBztKepEbKlQp5TTGwUNC4yoFScWlDakr0GiUSx srPI9n2Mfj5DdYDcr7P3WrmCN0WRdQzaHO8jHv9+9SOiAetsiL0EdvNED3EW/oUkftU7 Gcew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=GjFkrXQ0Jf/Wo7tGCVQoupglponKlDpocPGzJ8nG08w=; b=i8u/WCQJzX3MQ7vqd/ESdQ6+Lt1ZV/5UKhzFNAPwao86G1mEDVjHb3ZIK41t6YP8Xd dzZHli2yk1ZJblbZl7kAjcWmRPISZIbuptCzqx+T+4zebwDz6n5gSxNoDy5UJtNieeLi 48DXVf2Ewne5lDWo2V8yXToRLvR2RHv2z07asW/Od85mth6wIQpKM3fyOyZ2zTCY0tFn +KjGv4mcU/GPrcWB19v9C+krixwFtrb5H6vrkx+bNUrXNV+HA5ZCsG4uNKV+DVGkU4R4 DOZC57tUcojfqwXfjWtUSdAhumqORhmVHoHya//xAgIHMQBePyx+SC3gPK5Bl6O9DFEF wlxA== X-Gm-Message-State: AOAM531EGdddCrklZTQqzN88unaTcLqcC65WoRCkYTgnfRtVSdDS4y7Q ZafVVDeWc9D+vCGsLzBPDW5uHw== X-Google-Smtp-Source: ABdhPJyV+/dzhnfs2RsTb0ksOXgH5/6MCWREjHpjTzGRVMUOdPqGNPSye2+TOSA8Bt16SoYKjRWxng== X-Received: by 2002:a05:6a00:891:b0:4fe:1262:9b4e with SMTP id q17-20020a056a00089100b004fe12629b4emr3805428pfj.21.1650618613443; Fri, 22 Apr 2022 02:10:13 -0700 (PDT) Received: from C02G87K0MD6R.bytedance.net ([139.177.225.244]) by smtp.gmail.com with ESMTPSA id oe7-20020a17090b394700b001d8995368a9sm559239pjb.35.2022.04.22.02.10.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 22 Apr 2022 02:10:13 -0700 (PDT) From: Hao Jia To: mingo@redhat.com, peterz@infradead.org, juri.lelli@redhat.com, vincent.guittot@linaro.org, dietmar.eggemann@arm.com, rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de, bristot@redhat.com Cc: linux-kernel@vger.kernel.org, Hao Jia Subject: [PATCH v2 1/2] sched/core: Avoid obvious double update_rq_clock warning Date: Fri, 22 Apr 2022 17:09:43 +0800 Message-Id: <20220422090944.52618-2-jiahao.os@bytedance.com> X-Mailer: git-send-email 2.32.0 (Apple Git-132) In-Reply-To: <20220422090944.52618-1-jiahao.os@bytedance.com> References: <20220422090944.52618-1-jiahao.os@bytedance.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" When we use raw_spin_rq_lock to acquire the rq lock and have to update the rq clock while holding the lock, the kernel may issue a WARN_DOUBLE_CLOCK warning. Since we directly use raw_spin_rq_lock to acquire rq lock instead of rq_lock, there is no corresponding change to rq->clock_update_flags. In particular, we have obtained the rq lock of other cores, the core rq->clock_update_flags may be RQCF_UPDATED at this time, and then calling update_rq_clock will trigger the WARN_DOUBLE_CLOCK warning. So we need to clear RQCF_UPDATED of rq->clock_update_flags synchronously to avoid the WARN_DOUBLE_CLOCK warning. Some call trace reports: Call Trace 1: sched_rt_period_timer+0x10f/0x3a0 ? enqueue_top_rt_rq+0x110/0x110 __hrtimer_run_queues+0x1a9/0x490 hrtimer_interrupt+0x10b/0x240 __sysvec_apic_timer_interrupt+0x8a/0x250 sysvec_apic_timer_interrupt+0x9a/0xd0 asm_sysvec_apic_timer_interrupt+0x12/0x20 Call Trace 2: activate_task+0x8b/0x110 push_rt_task.part.108+0x241/0x2c0 push_rt_tasks+0x15/0x30 finish_task_switch+0xaa/0x2e0 ? __switch_to+0x134/0x420 __schedule+0x343/0x8e0 ? hrtimer_start_range_ns+0x101/0x340 schedule+0x4e/0xb0 do_nanosleep+0x8e/0x160 hrtimer_nanosleep+0x89/0x120 ? hrtimer_init_sleeper+0x90/0x90 __x64_sys_nanosleep+0x96/0xd0 do_syscall_64+0x34/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae Call Trace 3: deactivate_task+0x93/0xe0 pull_rt_task+0x33e/0x400 balance_rt+0x7e/0x90 __schedule+0x62f/0x8e0 do_task_dead+0x3f/0x50 do_exit+0x7b8/0xbb0 do_group_exit+0x2d/0x90 get_signal+0x9df/0x9e0 ? preempt_count_add+0x56/0xa0 ? __remove_hrtimer+0x35/0x70 arch_do_signal_or_restart+0x36/0x720 ? nanosleep_copyout+0x39/0x50 ? do_nanosleep+0x131/0x160 ? audit_filter_inodes+0xf5/0x120 exit_to_user_mode_prepare+0x10f/0x1e0 syscall_exit_to_user_mode+0x17/0x30 do_syscall_64+0x40/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae Steps to reproduce: 1. Enable CONFIG_SCHED_DEBUG when compiling the kernel 2. echo 1 > /sys/kernel/debug/clear_warn_once echo "WARN_DOUBLE_CLOCK" > /sys/kernel/debug/sched_features echo "NO_RT_PUSH_IPI" > /sys/kernel/debug/sched_features 3. Run some rt tasks that periodically change the priority and sleep Signed-off-by: Hao Jia Signed-off-by: Dietmar Eggemann --- kernel/sched/core.c | 6 +++--- kernel/sched/rt.c | 5 +++-- kernel/sched/sched.h | 31 +++++++++++++++++++++++++++---- 3 files changed, 33 insertions(+), 9 deletions(-) diff --git a/kernel/sched/core.c b/kernel/sched/core.c index 51efaabac3e4..84538271b4eb 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -610,10 +610,10 @@ void double_rq_lock(struct rq *rq1, struct rq *rq2) swap(rq1, rq2); =20 raw_spin_rq_lock(rq1); - if (__rq_lockp(rq1) =3D=3D __rq_lockp(rq2)) - return; + if (__rq_lockp(rq1) !=3D __rq_lockp(rq2)) + raw_spin_rq_lock_nested(rq2, SINGLE_DEPTH_NESTING); =20 - raw_spin_rq_lock_nested(rq2, SINGLE_DEPTH_NESTING); + double_rq_clock_clear_update(rq1, rq2); } #endif =20 diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c index a32c46889af8..7891c0f0e1ff 100644 --- a/kernel/sched/rt.c +++ b/kernel/sched/rt.c @@ -871,6 +871,7 @@ static int do_sched_rt_period_timer(struct rt_bandwidth= *rt_b, int overrun) int enqueue =3D 0; struct rt_rq *rt_rq =3D sched_rt_period_rt_rq(rt_b, i); struct rq *rq =3D rq_of_rt_rq(rt_rq); + struct rq_flags rf; int skip; =20 /* @@ -885,7 +886,7 @@ static int do_sched_rt_period_timer(struct rt_bandwidth= *rt_b, int overrun) if (skip) continue; =20 - raw_spin_rq_lock(rq); + rq_lock(rq, &rf); update_rq_clock(rq); =20 if (rt_rq->rt_time) { @@ -923,7 +924,7 @@ static int do_sched_rt_period_timer(struct rt_bandwidth= *rt_b, int overrun) =20 if (enqueue) sched_rt_rq_enqueue(rt_rq); - raw_spin_rq_unlock(rq); + rq_unlock(rq, &rf); } =20 if (!throttled && (!rt_bandwidth_enabled() || rt_b->rt_runtime =3D=3D RUN= TIME_INF)) diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h index 8dccb34eb190..7f1a18b2aff2 100644 --- a/kernel/sched/sched.h +++ b/kernel/sched/sched.h @@ -2478,6 +2478,27 @@ unsigned long arch_scale_freq_capacity(int cpu) } #endif =20 +#ifdef CONFIG_SCHED_DEBUG +/* + * In double_lock_balance/double_rq_lock, we use raw_spin_rq_lock to acqui= re rq lock + * instead of rq_lock. So at the end of these two functions we need to call + * double_rq_clock_clear_update synchronously to clear RQCF_UPDATED of + * rq->clock_update_flags to avoid the WARN_DOUBLE_CLOCK warning. + */ +static inline void double_rq_clock_clear_update(struct rq *rq1, struct rq = *rq2) +{ + rq1->clock_update_flags &=3D (RQCF_REQ_SKIP|RQCF_ACT_SKIP); + /* + * If CONFIG_SMP is not defined, rq1 and rq2 are the same, + * so we just clear RQCF_UPDATED one of them. + */ +#ifdef CONFIG_SMP + rq2->clock_update_flags &=3D (RQCF_REQ_SKIP|RQCF_ACT_SKIP); +#endif +} +#else +static inline void double_rq_clock_clear_update(struct rq *rq1, struct rq = *rq2) {} +#endif =20 #ifdef CONFIG_SMP =20 @@ -2543,14 +2564,15 @@ static inline int _double_lock_balance(struct rq *t= his_rq, struct rq *busiest) __acquires(busiest->lock) __acquires(this_rq->lock) { - if (__rq_lockp(this_rq) =3D=3D __rq_lockp(busiest)) - return 0; - - if (likely(raw_spin_rq_trylock(busiest))) + if (__rq_lockp(this_rq) =3D=3D __rq_lockp(busiest) || + likely(raw_spin_rq_trylock(busiest))) { + double_rq_clock_clear_update(this_rq, busiest); return 0; + } =20 if (rq_order_less(this_rq, busiest)) { raw_spin_rq_lock_nested(busiest, SINGLE_DEPTH_NESTING); + double_rq_clock_clear_update(this_rq, busiest); return 0; } =20 @@ -2644,6 +2666,7 @@ static inline void double_rq_lock(struct rq *rq1, str= uct rq *rq2) BUG_ON(rq1 !=3D rq2); raw_spin_rq_lock(rq1); __acquire(rq2->lock); /* Fake it out ;) */ + double_rq_clock_clear_update(rq1, rq2); } =20 /* --=20 2.32.0 From nobody Sun May 10 22:40:31 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 22BDDC433F5 for ; Fri, 22 Apr 2022 09:15:44 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1351173AbiDVJSd (ORCPT ); Fri, 22 Apr 2022 05:18:33 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60254 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1445882AbiDVJNL (ORCPT ); Fri, 22 Apr 2022 05:13:11 -0400 Received: from mail-pl1-x62c.google.com (mail-pl1-x62c.google.com [IPv6:2607:f8b0:4864:20::62c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9A24BB847 for ; Fri, 22 Apr 2022 02:10:19 -0700 (PDT) Received: by mail-pl1-x62c.google.com with SMTP id s17so9510190plg.9 for ; Fri, 22 Apr 2022 02:10:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance-com.20210112.gappssmtp.com; s=20210112; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=G8S0f1fxh4tyjKf+IoZyuPgywpYwOEgpWk257TfqhQI=; b=d4wk5OPV0Zah6tt7VlyuF11yJsiCW6MgsfsalPD7a7HYycnmRNy+tjvAvkYU7EyWo/ bDu5pyb6bQA6X3p99ngSNjMDWTgXp/lpLH7EWvt9tdmfoUjn4cfdEtHvrpBUkgIcWAZ8 HXcUY3BC0ze5Xagu/AioHT5xTu3HQPMrjGb7k6GYzUiEuQcvJlQNvJUJ1RBrVX3Rmr2V 8u7yzfDpOyJxwWplB2iFYmqElYyvNxqZao1xapDmF3Ry8sqKiSZ59RdIqfRqIhIP63LH JX1bADYycSryyEhwT3GWRP+WWA+Cx/lhWRV2QN8eCHqBHbx9vuM7gzlObJnWpV3wA+k7 Kxsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=G8S0f1fxh4tyjKf+IoZyuPgywpYwOEgpWk257TfqhQI=; b=AZz5hDzgD7367EaPQFtdVT/Z8E9tgmFoIyRMuxS7Byk3sOG9+E9gXorGWo3PTi/eOR xIDe1HL1TEoPXxZ5zvw45G6CrIourHspj6jf5GjHLtZdBBttlHxhFm6HZhR8kNMmgctr DggwwYxCuX0eu03XajOvGauZPYOEc2KTdgOf1YqWoTunfwDRreZcDTKv99xFsmCIBXdF bgLdTclPcc+X/LQvfhFbSJJpWqjUKxz4GardZQOgQhxZotARaoPD5F9Uzkdt5MUTfquF yklkulGRMcbgR/KHvTUAfcU6wvaZ1XtyO4xwUHaMVTu7HNbDMq4z8HWy0OrXTvws9Bqz 1aZA== X-Gm-Message-State: AOAM531lBFqMbtYpKp1jIYKx9wdYiVubqO5rpuNtsUE89898naQ35WCR oKeY2GLIAdPG/rsUbYzWppeQjA== X-Google-Smtp-Source: ABdhPJz+j6iCMBbmMv2F+PtTyVy2Vkfyw2jgwAOMpNg1dazx/7ebgmLR9gHVessAIIG2LBvr3jIYLw== X-Received: by 2002:a17:903:290:b0:15c:1c87:e66c with SMTP id j16-20020a170903029000b0015c1c87e66cmr1803213plr.61.1650618619137; Fri, 22 Apr 2022 02:10:19 -0700 (PDT) Received: from C02G87K0MD6R.bytedance.net ([139.177.225.244]) by smtp.gmail.com with ESMTPSA id oe7-20020a17090b394700b001d8995368a9sm559239pjb.35.2022.04.22.02.10.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 22 Apr 2022 02:10:18 -0700 (PDT) From: Hao Jia To: mingo@redhat.com, peterz@infradead.org, juri.lelli@redhat.com, vincent.guittot@linaro.org, dietmar.eggemann@arm.com, rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de, bristot@redhat.com Cc: linux-kernel@vger.kernel.org, Hao Jia Subject: [PATCH v2 2/2] sched/dl: Remove some comments and adjust code in push_dl_task Date: Fri, 22 Apr 2022 17:09:44 +0800 Message-Id: <20220422090944.52618-3-jiahao.os@bytedance.com> X-Mailer: git-send-email 2.32.0 (Apple Git-132) In-Reply-To: <20220422090944.52618-1-jiahao.os@bytedance.com> References: <20220422090944.52618-1-jiahao.os@bytedance.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" The change to call update_rq_clock() before activate_task() commit 840d719604b0 ("sched/deadline: Update rq_clock of later_rq when pushing a task") is no longer needed since commit f4904815f97a ("sched/deadline: Fix double accounting of rq/running bw in push & pull") removed the add_running_bw() before the activate_task(). So we remove some comments that are no longer needed and update rq clock in activate_task(). Signed-off-by: Hao Jia Reviewed-by: Dietmar Eggemann --- kernel/sched/deadline.c | 8 +------- 1 file changed, 1 insertion(+), 7 deletions(-) diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c index fb4255ae0b2c..8eb694ed7ac1 100644 --- a/kernel/sched/deadline.c +++ b/kernel/sched/deadline.c @@ -2319,13 +2319,7 @@ static int push_dl_task(struct rq *rq) =20 deactivate_task(rq, next_task, 0); set_task_cpu(next_task, later_rq->cpu); - - /* - * Update the later_rq clock here, because the clock is used - * by the cpufreq_update_util() inside __add_running_bw(). - */ - update_rq_clock(later_rq); - activate_task(later_rq, next_task, ENQUEUE_NOCLOCK); + activate_task(later_rq, next_task, 0); ret =3D 1; =20 resched_curr(later_rq); --=20 2.32.0