Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp4693026iob; Sun, 8 May 2022 22:13:39 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxqSVZlJRuaRzgqEQdy0zz815RDabAJV65RX3xGR5UGpfrbUopzF0sa7+4dbr89YVq6U4hS X-Received: by 2002:aa7:8e44:0:b0:50c:fc0e:8d25 with SMTP id d4-20020aa78e44000000b0050cfc0e8d25mr14197414pfr.81.1652073219043; Sun, 08 May 2022 22:13:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1652073219; cv=none; d=google.com; s=arc-20160816; b=AGgsysl8FRuc25zjenThmAX54Zx08cqiow8Y/hvPN5XhS/Od20lFsAsLyUEAyvxnWw JodAdlagYHHO3DX2LeC2qAsy/Or+78N4VYxqW3ye79ETHidBD9iNpkJT43ZHw3VO6urz 7Md4m87xHnSYWXiyR6xQvdNaX4rZxGylHNwZAhFNsJOmCdJdJSewhamGm+h7cJvwOQi+ IxGeBGou7HSQ/vKGiXlk4CuJHeviK77gfSUh5YWqyvO2W9shITb/NZj8jNCrhSoUty9B poJ+PmlTw1sBuXllf/t2eotFzeK9e43q3hoUKAutgnDd0wvGgXL0E/xmFQRFG7vXYy3r bKvQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id; bh=WYdWJFXoUvWB7IA00QDqGvqf4rumrJGmtO6WrGFH6Dc=; b=wDUsFwu7EHLmq1q6vlUFMDXAfng1AUASm1RAqRVDhjlIIhaYgap6m0hWCyKvLJEG3f PRwaJGrs9MMobR4GJODZoJ4nZhpS5ZPtwp+J0opEGcpw1OUSDfhiYy6fNqnIRGZxWlLp YE4h4xf6g4om48fAb/d5L90/i6w20bcffVUNaW305KkIxTl4p143D3RgULAsQUusXUbg 9sxlEONZteFMppuVpRGlMfFla2aD3ShHRsJC4XLwqoFYMW3tpKW6Gu2MGtnxZwJ6OiT4 opffUobaEzajb0tdHEFb5eY+1a98rYmOYMPh6B+kUvYXDzerGp/UdbhAhTYiTL58ArP/ buWQ== ARC-Authentication-Results: i=1; mx.google.com; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id t197-20020a635fce000000b003a85cf1e1edsi4582995pgb.305.2022.05.08.22.13.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 08 May 2022 22:13:39 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id D13507CDEA; Sun, 8 May 2022 22:10:07 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1384719AbiEESs7 (ORCPT + 99 others); Thu, 5 May 2022 14:48:59 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56292 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1384751AbiEESsZ (ORCPT ); Thu, 5 May 2022 14:48:25 -0400 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id E3BD361619 for ; Thu, 5 May 2022 11:41:17 -0700 (PDT) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id A48D91042; Thu, 5 May 2022 11:41:17 -0700 (PDT) Received: from [192.168.178.6] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 177C73FA31; Thu, 5 May 2022 11:41:15 -0700 (PDT) Message-ID: <3899a404-8016-0f4f-58b8-9353d08db4c9@arm.com> Date: Thu, 5 May 2022 20:41:08 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Subject: Re: [PATCH v8 2/7] sched/fair: Decay task PELT values during wakeup migration Content-Language: en-US To: peterz@infradead.org, mingo@redhat.com, vincent.guittot@linaro.org, vdonnefort@gmail.com Cc: linux-kernel@vger.kernel.org, morten.rasmussen@arm.com, chris.redpath@arm.com, qperret@google.com, tao.zhou@linux.dev References: <20220429141148.181816-1-vincent.donnefort@arm.com> <20220429141148.181816-3-vincent.donnefort@arm.com> From: Dietmar Eggemann In-Reply-To: <20220429141148.181816-3-vincent.donnefort@arm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.4 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=unavailable 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 + vdonnefort@gmail.com - vincent.donnefort@arm.com On 29/04/2022 16:11, Vincent Donnefort wrote: [...] > To that end, we need sched_clock_cpu() but it is a costly function. Limit > the usage to the case where the source CPU is idle as we know this is when > the clock is having the biggest risk of being outdated. In this such case, > let's call it cfs_idle_lag the delta time between the rq_clock_pelt value > at rq idle and cfs_rq idle. And rq_idle_lag the delta between "now" and > the rq_clock_pelt at rq idle. > > The estimated PELT clock is then: Where is this nice diagram (timeline) from v7 ? [...] > + /* > + * estimated "now" is: > + * last_update_time + (the cfs_rq's last_update_time) > + * cfs_idle_lag + (delta between cfs_rq's update and rq's update) > + * rq_idle_lag (delta between rq's update and now) The parentheses here make this hard to get. Same text as in the patch header. What would have speed up me understanding this would have been this line: now = last_update_time + cfs_idle_lag + rq_idle_lag > + * > + * last_update_time = cfs_rq_clock_pelt() > + * = rq_clock_pelt() - cfs->throttled_clock_pelt_time > + * > + * cfs_idle_lag = rq_clock_pelt()@rq_idle - > + * rq_clock_pelt()@cfs_rq_idle > + * > + * rq_idle_lag = sched_clock_cpu() - rq_clock()@rq_idle > + * > + * The rq_clock_pelt() from last_update_time being the same as > + * rq_clock_pelt()@cfs_rq_idle, we can write: > + * > + * now = rq_clock_pelt()@rq_idle - cfs->throttled_clock_pelt_time + > + * sched_clock_cpu() - rq_clock()@rq_idle > + * > + * Where: > + * rq_clock_pelt()@rq_idle is rq->clock_pelt_idle > + * rq_clock()@rq_idle is rq->enter_idle > + * cfs->throttled_clock_pelt_time is cfs_rq->throttled_pelt_idle > + */ [...] > +#ifdef CONFIG_CFS_BANDWIDTH > +static inline void update_idle_cfs_rq_clock_pelt(struct cfs_rq *cfs_rq) > { > - lockdep_assert_rq_held(rq); > - assert_clock_updated(rq); > - > - return rq->clock_pelt - rq->lost_idle_time; > + /* > + * Make sure that pending update of rq->clock_pelt_idle and > + * rq->enter_idle are visible during update_blocked_average() before s/update_blocked_average()/update_blocked_averages() > + * updating cfs_rq->throttled_pelt_idle. > + */ > + smp_wmb(); I don't understand this one. Where is the counterpart barrier? > + if (unlikely(cfs_rq->throttle_count)) > + u64_u32_store(cfs_rq->throttled_pelt_idle, U64_MAX); > + else > + u64_u32_store(cfs_rq->throttled_pelt_idle, > + cfs_rq->throttled_clock_pelt_time); Nit-pick: Using a local u64 throttled might be easier on the eye: if (unlikely(cfs_rq->throttle_count)) - u64_u32_store(cfs_rq->throttled_pelt_idle, U64_MAX); + throttled = U64_MAX; else - u64_u32_store(cfs_rq->throttled_pelt_idle, - cfs_rq->throttled_clock_pelt_time); + throttled = cfs_rq->throttled_clock_pelt_time; + + u64_u32_store(cfs_rq->throttled_pelt_idle, throttled); [...]