Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp3715844pxj; Mon, 21 Jun 2021 05:06:37 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwwXJnNA7FkCtexTIpz2/lOCePieEIt5L2hGmajjtYTGUZVdhbMMZq3mEo/412R3utl4cQS X-Received: by 2002:aa7:db94:: with SMTP id u20mr21079565edt.381.1624277197088; Mon, 21 Jun 2021 05:06:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1624277197; cv=none; d=google.com; s=arc-20160816; b=jflfb73Og7w2WL25Iq+hI9cNJ+hrDMlmZ6uZeGm92xPVOP0jMOthngbJSowQpMfrBH Pgg5Hok+S91kVl0Jy26OqNXvBIyZrzklnwDh+gM1uZPkXHEKbbhoOiHr7s+aHZHjBaH6 kJWmbnEXXlPvR0OQ28NXZ/syi2Z0M8bVzTRJOR1s6C08kXHDgIICxM+BsPBUtOaos9Xx 8PBI0UhHbAoYA3IkaBvVfQqHU7zpsgZULD6P7Orm9rfrVd9MPRksAud2jNK7xIN1luxP 5M5RMYG2WFLkLi68iU1EXmFuegLR2iuO8J4sjqNn8dM7LhN7NYgFVdG2nbzsgbQBauMB miBQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=RLBw6jzZUcoWFnQv/t5zCIfg8AsSPtdCtp9Y9odX5Lg=; b=KXuxUeapkaKdgmF8l3japCfVwGqx0kHHqTYJ2PDpMe/kCN9trt334bHS9RckA/x4Hi D5GVDG8jdy0rHtEqRBA/LtEWFY2j5EfaYoqI0q9TYQEyHEDcrn2zLfmto7R7FCoy99SC cKJzUa2F5608LnLmIoDWcziTGiPKXDxIJ8YWfH5gFCkLmIT4g03c+uXXS1PPTRh6dhud KmB7M3NAcaWhulnxJOBTYMytxo+VFgGGEG4UCFsm+BlIN/tgpsSB28hny0caXjO/G/ZX p8mwa7G3FlqxSP+MbTeBITi+HDJ7g1bchz0U7aOIeEqa+DcTbnpDRQrVlx9ys5XqqLQ9 MugQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b="AQ13Yui/"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id k13si9193885edq.390.2021.06.21.05.06.14; Mon, 21 Jun 2021 05:06:37 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b="AQ13Yui/"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231134AbhFUMGd (ORCPT + 99 others); Mon, 21 Jun 2021 08:06:33 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53596 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229887AbhFUMGQ (ORCPT ); Mon, 21 Jun 2021 08:06:16 -0400 Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1D60AC0617A6 for ; Mon, 21 Jun 2021 05:03:58 -0700 (PDT) Received: by mail-lf1-x132.google.com with SMTP id a11so16720299lfg.11 for ; Mon, 21 Jun 2021 05:03:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RLBw6jzZUcoWFnQv/t5zCIfg8AsSPtdCtp9Y9odX5Lg=; b=AQ13Yui/xEP4So25jkuK4rRwl5qKLjSBDp06GcVsEGi6ToCQ7D4//qsla1l49Az/4N jbwhYTuI5cmQGYrQsW/e1tOKqRX0x4oiTUn34xPDqN+wlNDQLWtCKN5WG/jC9iC9aV+L iPzo53iTiSf3Qf4bKYjHNsMlIk3UVBopmxsxIU00x6OK7PlSPBo5zhuCcaaG9RCCbOWK SqrfnODO7Uo+bcEajCOezrd4sUtGiV7Mun1WlQ/6FO+MaJYHag64tHkQO3ZKi4BLdF0e TMbRTxmw1E0dW4e+W3s/BiQ7cmkm1TlBmbWbV9UC7K9V/0gI1aZAc+yUoNLsOfhF/KXM dmeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=RLBw6jzZUcoWFnQv/t5zCIfg8AsSPtdCtp9Y9odX5Lg=; b=NCuvTu4l0/cboua8cBsejLOw8bZ5Yg3XvDEzIYE4DJh4aW6ewambiP7qnVjftjvuOY STYfVljlbVd6UXRDyswvPmiyn1gjI6yKX83L8U5YoRNGI5bCRh1bjc/QYYkb4BiN0DEw dByk4OXMb2lwyHKV/+hC187cKMvu9mVp+TKR9VkloyehP9R/OULN4sN14uGYOQK96j6y SkPeBGgihoCw58B+09pP9KDMxJOdYgqkBfkY34lESQY/VhLMa6c995uXwg0pBAcdkiPa ZPNnpS65qBIq6iSChaH0Qfs7j+OPQmZ8vNCEzbyYWPNq/SVqUxzuuMqUGSbYBQjNzFan 4UGw== X-Gm-Message-State: AOAM533NSmK5atKsFUQrlGxS3lVIDhk9NiyLAgyNTYPenFMX2C5yjMBW f9i29EHbcwY2ORSU1lD4xmiYsx/L6MlImprU6bkzx5a/OKsGJg== X-Received: by 2002:ac2:4949:: with SMTP id o9mr14150436lfi.254.1624277036416; Mon, 21 Jun 2021 05:03:56 -0700 (PDT) MIME-Version: 1.0 References: <1624271872-211872-1-git-send-email-vincent.donnefort@arm.com> <1624271872-211872-2-git-send-email-vincent.donnefort@arm.com> In-Reply-To: <1624271872-211872-2-git-send-email-vincent.donnefort@arm.com> From: Vincent Guittot Date: Mon, 21 Jun 2021 14:03:43 +0200 Message-ID: Subject: Re: [PATCH v2 1/2] sched/rt: Fix RT utilization tracking during policy change To: Vincent Donnefort Cc: Ingo Molnar , Peter Zijlstra , Juri Lelli , Dietmar Eggemann , Valentin Schneider , Steven Rostedt , linux-kernel Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 21 Jun 2021 at 12:39, Vincent Donnefort wrote: > > RT keeps track of the utilization on a per-rq basis with the structure > avg_rt. This utilization is updated during task_tick_rt(), > put_prev_task_rt() and set_next_task_rt(). However, when the current > running task changes its policy, set_next_task_rt() which would usually > take care of updating the utilization when the rq starts running RT tasks, > will not see a such change, leaving the avg_rt structure outdated. When > that very same task will be dequeued later, put_prev_task_rt() will then > update the utilization, based on a wrong last_update_time, leading to a > huge spike in the RT utilization signal. > > The signal would eventually recover from this issue after few ms. Even if > no RT tasks are run, avg_rt is also updated in __update_blocked_others(). > But as the CPU capacity depends partly on the avg_rt, this issue has > nonetheless a significant impact on the scheduler. > > Fix this issue by ensuring a load update when a running task changes > its policy to RT. > > Fixes: 371bf427 ("sched/rt: Add rt_rq utilization tracking") > Signed-off-by: Vincent Donnefort Reviewed-by: Vincent Guittot > > diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c > index a525447..3daf42a 100644 > --- a/kernel/sched/rt.c > +++ b/kernel/sched/rt.c > @@ -2341,13 +2341,20 @@ void __init init_sched_rt_class(void) > static void switched_to_rt(struct rq *rq, struct task_struct *p) > { > /* > - * If we are already running, then there's nothing > - * that needs to be done. But if we are not running > - * we may need to preempt the current running task. > - * If that current running task is also an RT task > + * If we are running, update the avg_rt tracking, as the running time > + * will now on be accounted into the latter. > + */ > + if (task_current(rq, p)) { > + update_rt_rq_load_avg(rq_clock_pelt(rq), rq, 0); > + return; > + } > + > + /* > + * If we are not running we may need to preempt the current > + * running task. If that current running task is also an RT task > * then see if we can move to another run queue. > */ > - if (task_on_rq_queued(p) && rq->curr != p) { > + if (task_on_rq_queued(p)) { > #ifdef CONFIG_SMP > if (p->nr_cpus_allowed > 1 && rq->rt.overloaded) > rt_queue_push_tasks(rq); > -- > 2.7.4 >