Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp9186050ybl; Fri, 17 Jan 2020 07:42:04 -0800 (PST) X-Google-Smtp-Source: APXvYqzhNtwhuJn4Qgh80gGD8RIH/tiMqqQ4NBf8uXi1KS6FC5lj7ddS0rUp39+5h9qkB4EjX8jC X-Received: by 2002:a05:6830:13d3:: with SMTP id e19mr6462346otq.135.1579275723889; Fri, 17 Jan 2020 07:42:03 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1579275723; cv=none; d=google.com; s=arc-20160816; b=a8cLSHnGWaGG4pKYB4FMHb/4knz4E4HV3/IF70kMcOyKi9879G5QLvoBds6bkwxwoT ou/9mAKzgtN/r4W+AKxxJwIzl7fP4KUOkC4Zc5Tyy6YwE52Zdp7cSqjapEDKV/1hKjfB rGhCAYTA19Cur71RppLLGA5j2ZkZ51CT5/+McY3+wkEsjM70F1hCSnurFPZPovzgkxcv jwvq7T6qEqZkV5IdDi9H8hHF1SBMXYKJPTJY8Fsr3aYh8WTV5f9ePG96d/pMHIJxEK6t sdu2nCI92Pxh3u8kpuxuVvyWb1pqUZszWxuB5tIXznNq25/85+v+IwCtUp8LY72ohIfl V+Sw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=2xCbY7FMjigCuairfD/dpXsbJlPPArVKVur2HZKJ7k0=; b=hOri15QuJ++H62Ve7QyQVh/41tKHPFPhvKM77h32MzzlbzYetAP4s6NIUg55YSplZm ZyKcKB0sPKfBznC2eN2jtntQnKMemOOSWc9On5NyvN9hEXZIStCKt8fz+tkBeDQCggv5 MGw68RqRzzA9cHOFB5EPW6yf+DriposIyG6Xbe7xdgyPC4GrHjEbQlxi4+LUfIoTQK0o ec012muulKzOuac1wAuJGNXbYsxRRK364S5bvOo5ll0Rst0FsoRpmX/mkovfF4cupg+p hAMz0HgjcE7/fD56brK6IrZjeWutf4vzYcgqqb+jsjYui+uN7OrOoS97FlDkIV0T5IFR zvlQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=UuxGtcgm; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 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. [209.132.180.67]) by mx.google.com with ESMTP id c7si15486013otr.308.2020.01.17.07.41.51; Fri, 17 Jan 2020 07:42:03 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=UuxGtcgm; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 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 S1729022AbgAQPju (ORCPT + 99 others); Fri, 17 Jan 2020 10:39:50 -0500 Received: from mail-lj1-f174.google.com ([209.85.208.174]:43492 "EHLO mail-lj1-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728816AbgAQPju (ORCPT ); Fri, 17 Jan 2020 10:39:50 -0500 Received: by mail-lj1-f174.google.com with SMTP id a13so26892543ljm.10 for ; Fri, 17 Jan 2020 07:39:49 -0800 (PST) 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=2xCbY7FMjigCuairfD/dpXsbJlPPArVKVur2HZKJ7k0=; b=UuxGtcgm6BCvBPiWvO1GG+7oNqXBg2s+2147Kp4KqV2HhGf89imdR5FCUnaD9G/6SJ QocrHDvPtK2hr75tl8+OHTkxy3CiUUhylgxz2Q4S8RSFbxJmlfZDgZBPORtCmOm37V7X QBkwGhNgybYSheAPtQ6KtmJsaUw1aW4nJptzpYM2JQ7f31/ZK7gg4/xo8C2AlYScMboL itP6Im4K0WjEuwD9FVmx/yGpR41pMnbyMssW6eg8Wj+An41l0fsEy9S62k10R1j4cXXZ vzgOfJcXT2u3VDHEgBEm+EMo732oUkmokhWyTNRn1qcoyVJlQEFD+jW9xNIV1ChH5LU/ nTjQ== 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=2xCbY7FMjigCuairfD/dpXsbJlPPArVKVur2HZKJ7k0=; b=IAYaNMNEE/AIIv2p0QDZ7FUz9pNmvTlORYqIyC0ym6UDy/HKNHQepnCjKQPMqJqy3f Kf3NwOR1F1c46YfbRqT907UdtqVsdLEMn4Kfqj0gJwe4yzJbef5eBJ1gjpwLeh4c1XkJ vg/j/VDnLDGHncVLDCWOB62S7wkwGo/7IKSJ8IT1XXCRkts1KrYc0QNIU74zP5FIbmxp JdlrvaoRozPaFOqEbtjSV3JtV2vBEhVsE0b61ua3Nk+6GBTsZOuM7jkJZ5O0P2HMtteI zad+V/f5xpvCfswBEJQLgndzzG+A/wnDlHBEnD8tQY1L1zWP7F/w8rRV8zrS28imEvPD cE6Q== X-Gm-Message-State: APjAAAVSG0ch4wTrKcuD8ggln1XaWqNSjywwx4QCcJfI1Jmzaye0g89P K6bch895nTVIx7K7FJqDf9R20w+9MgdbgMAS4F/0qA== X-Received: by 2002:a2e:88c5:: with SMTP id a5mr5957930ljk.201.1579275588343; Fri, 17 Jan 2020 07:39:48 -0800 (PST) MIME-Version: 1.0 References: <1579031859-18692-1-git-send-email-thara.gopinath@linaro.org> <1579031859-18692-5-git-send-email-thara.gopinath@linaro.org> <20200116151502.GQ2827@hirez.programming.kicks-ass.net> <20200117145544.GE14879@hirez.programming.kicks-ass.net> In-Reply-To: <20200117145544.GE14879@hirez.programming.kicks-ass.net> From: Vincent Guittot Date: Fri, 17 Jan 2020 16:39:37 +0100 Message-ID: Subject: Re: [Patch v8 4/7] sched/fair: Enable periodic update of average thermal pressure To: Peter Zijlstra Cc: Thara Gopinath , Ingo Molnar , Ionela Voinescu , Dietmar Eggemann , Zhang Rui , Quentin Perret , Daniel Lezcano , viresh kumar , linux-kernel , Amit Kachhap , Javi Merino , Amit Kucheria Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 17 Jan 2020 at 15:55, Peter Zijlstra wrote: > > On Fri, Jan 17, 2020 at 02:22:51PM +0100, Vincent Guittot wrote: > > On Thu, 16 Jan 2020 at 16:15, Peter Zijlstra wrote: > > > > > > > That there indentation trainwreck is a reason to rename the function. > > > > > > decayed = update_rt_rq_load_avg(now, rq, curr_class == &rt_sched_class) | > > > update_dl_rq_load_avg(now, rq, curr_class == &dl_sched_class) | > > > update_thermal_load_avg(rq_clock_task(rq), rq, thermal_pressure) | > > > update_irq_load_avg(rq, 0); > > > > > > Is much better. > > > > > > But now that you made me look at that, I noticed it's using a different > > > clock -- it is _NOT_ using now/rq_clock_pelt(), which means it'll not be > > > in sync with the other averages. > > > > > > Is there a good reason for that? > > > > We don't need to apply frequency and cpu capacity invariance on the > > thermal capping signal which is what rq_clock_pelt does > > Hmm, I suppose that is true, and that really could've done with a > comment. Now clock_pelt is sort-of in sync with clock_task, but won't it > still give weird artifacts by having it on a slightly different basis? No we should not. Weird artifacts happens when we add/subtract/propagate signals between each other and then apply pelt algorithm on the results. In the case of thermal signal, we only add it to others to update cpu_capacity but pelt algo is then not applied on it. The error because of some signals being at segment boundaries whereas others are not, is limited to 2% and doesn't accumulate over time. > > Anyway, looking at this, would it make sense to remove the @now argument > from update_*_load_avg()? All those functions already take @rq, and > rq_clock_*() are fairly trivial inlines. TBH I was thinking of doing the opposite for update_irq_load_avg which hides the clock that is used for irq_avg. This helps to easily identify which signals use the exact same clock and can be mixed to create a new pelt signal and which can't