Received: by 2002:a89:d88:0:b0:1fa:5c73:8e2d with SMTP id eb8csp1745105lqb; Sun, 26 May 2024 15:53:47 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCXu7FzAUQkA4fpCPvFzvmkDyUlbQgoxT1hhxONPw9LFT7tfa37FzM4NgaQBD9RT2Rl5mUZWl6+iPspGugWVKgYJo6vEg/TD9CM0XOU56A== X-Google-Smtp-Source: AGHT+IHz9ENajcSi5yzucrofjm5pAPCR6LCBmcfG7VIqvKnSz6bkKveb/ZuB/TM3XkphZpWq9xgs X-Received: by 2002:a05:6358:e90f:b0:194:801b:151a with SMTP id e5c5f4694b2df-197e565dcdcmr758369255d.23.1716764026764; Sun, 26 May 2024 15:53:46 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1716764026; cv=pass; d=google.com; s=arc-20160816; b=W+mYgOdG2LRH4+g0BJ0SOS+hNGOeSmpfspUpLL2dhd/wcy4ng4wMM1hmA0mSnPiQPI RjTj3C30AVkb0lhBP7Y2MafT/pviGq58Qbn1kqxIrrf1RjH0+ILPid1qD8v+0liH2ew9 xTAQS9bTEN6F0k1DdKnO+TiN9GaHGslu4x6C3CC9Qat0aqd2MTXJ1wYGNUVOszQ4/wGU ukVjAP9MBAlAktzkExNMPd5f0KbJz3DE+PyEFq1D+qdRUjyyWNdHQxURw3exysSmBqmG Ul9YASNui7EAB/+vw+Iv1tqCPqzalGbZ3UUf2lufaHzz9f9S/tH0ExabFsVWZV9N5NGS Rvmg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:in-reply-to:content-language:from :references:cc:to:subject:user-agent:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:date:message-id; bh=jQ3xisf7CXx0R68Nb3KPrDW9f/1aL4Obh6aQS5K5rO8=; fh=Cquev1HCU8rRrvORsYLr7VaHkwJsZ83BErC89ct94hg=; b=JcTf9wSfvt6sXNnXt39mdptjTIlYQhaZg1MG5gnxZ8NPSaCeRNpXM0PWHaiI3gcKJC lidJx0teokEEqxX1uceP49achjSL4crAjaSpIGSuldOQKMCsyQFFF+L4B+40AwerSPmi 502Kl6I+FWl/rF11iYuJ3ch1rHlcd4yNLzRK7wDrwiymqYlJFHmzYUi8++Mv1rcOeZG7 BYkPfGSiHljrhozPcyK+7ov5FsnSKeZpuMIZ+Lt+uLlO3AHLhQsqL/EFAMbSCS8jsS1W uVVq5VnEy9EwYW6E/LlYWf2QdEW2QK8XoNXXsYI8nPbw1ayh35I5jNoJ+a6kLFQ4eWjB rtKw==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; arc=pass (i=1 spf=pass spfdomain=arm.com dmarc=pass fromdomain=arm.com); spf=pass (google.com: domain of linux-kernel+bounces-189893-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) smtp.mailfrom="linux-kernel+bounces-189893-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org. [147.75.48.161]) by mx.google.com with ESMTPS id 41be03b00d2f7-68229a303e0si5271995a12.681.2024.05.26.15.53.46 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 26 May 2024 15:53:46 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-189893-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161; Authentication-Results: mx.google.com; arc=pass (i=1 spf=pass spfdomain=arm.com dmarc=pass fromdomain=arm.com); spf=pass (google.com: domain of linux-kernel+bounces-189893-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) smtp.mailfrom="linux-kernel+bounces-189893-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sy.mirrors.kernel.org (Postfix) with ESMTPS id 0D8D3B21239 for ; Sun, 26 May 2024 22:53:28 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 2427113A3EB; Sun, 26 May 2024 22:53:09 +0000 (UTC) Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id E751C13A3E1 for ; Sun, 26 May 2024 22:53:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1716763988; cv=none; b=WHD7rjPGKwnW0ZiDIvFwL93N7r/DnsvHeI+Fxw46Y0YLlb3lIWltIo1CP0O7Pj/wXFsyE2K3M8ESJOgfHzuYISmyPmrWGzTtQpofRbMHBfxV0Ge1wLqcBRcIWC4TDBZ1ItUeC7hUapDw+MxMx+OALG7CIy6tEb6l0vExgjuG3Uc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1716763988; c=relaxed/simple; bh=tOQSs2IjrzjIz5U96bfsXT4UjIsm2cCIB+R7zVNbU10=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=UWbcvHBlAuD75ci5mfJDoh/H+XqCoPjFOpCP2Rq9yn1gelNIIVz7Fnev1DvAGudR+qgFfHHZno47aKRhuf4/VFQxgzXR0iuijVnsosGM43u4oxx/SpDVV6Wrnk2mHRbTPxYLlAGE3L2IZdT9dR4YIQz3ims0/6Ko2Y/ND3N0iU0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com 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 B5693339; Sun, 26 May 2024 15:53:30 -0700 (PDT) Received: from [192.168.178.6] (usa-sjc-mx-foss1.foss.arm.com [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 411AD3F641; Sun, 26 May 2024 15:53:04 -0700 (PDT) Message-ID: Date: Mon, 27 May 2024 00:53:03 +0200 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH v3 6/6] Propagate negative bias To: Hongyan Xia , Ingo Molnar , Peter Zijlstra , Vincent Guittot , Juri Lelli , Steven Rostedt , Ben Segall , Mel Gorman , Daniel Bristot de Oliveira , Valentin Schneider Cc: Qais Yousef , Morten Rasmussen , Lukasz Luba , Christian Loehle , pierre.gondois@arm.com, linux-kernel@vger.kernel.org References: From: Dietmar Eggemann Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 07/05/2024 14:50, Hongyan Xia wrote: > Negative bias is interesting, because dequeuing such a task will > actually increase utilization. > > Solve by applying PELT decay to negative biases as well. This in fact > can be implemented easily with some math tricks. > > Signed-off-by: Hongyan Xia > --- > kernel/sched/fair.c | 44 ++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 44 insertions(+) > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c > index 0177d7e8f364..7259a61e9ae5 100644 > --- a/kernel/sched/fair.c > +++ b/kernel/sched/fair.c > @@ -4863,6 +4863,45 @@ static inline unsigned long task_util_est_uclamp(struct task_struct *p) > { > return max(task_util_uclamp(p), _task_util_est_uclamp(p)); > } > + > +/* > + * Negative biases are tricky. If we remove them right away then dequeuing a > + * uclamp_max task has the interesting effect that dequeuing results in a higher > + * rq utilization. Solve this by applying PELT decay to the bias itself. > + * > + * Keeping track of a PELT-decayed negative bias is extra overhead. However, we > + * observe this interesting math property, where y is the decay factor and p is > + * the number of periods elapsed: > + * > + * util_new = util_old * y^p - neg_bias * y^p > + * = (util_old - neg_bias) * y^p > + * > + * Therefore, we simply subtract the negative bias from util_avg the moment we > + * dequeue, then the PELT signal itself is the total of util_avg and the decayed > + * negative bias, and we no longer need to track the decayed bias separately. > + */ > +static void propagate_negative_bias(struct task_struct *p) > +{ > + if (task_util_bias(p) < 0 && !task_on_rq_migrating(p)) { > + unsigned long neg_bias = -task_util_bias(p); > + struct sched_entity *se = &p->se; > + struct cfs_rq *cfs_rq; > + > + p->se.avg.util_avg_bias = 0; > + > + for_each_sched_entity(se) { > + u32 divider, neg_sum; > + > + cfs_rq = cfs_rq_of(se); > + divider = get_pelt_divider(&cfs_rq->avg); > + neg_sum = neg_bias * divider; > + sub_positive(&se->avg.util_avg, neg_bias); > + sub_positive(&se->avg.util_sum, neg_sum); > + sub_positive(&cfs_rq->avg.util_avg, neg_bias); > + sub_positive(&cfs_rq->avg.util_sum, neg_sum); > + } > + } So you remove the 'task bias = clamp(util_avg, uclamp_min, uclamp_max) - util_avg' from the se and cfs_rq util_avg' in case it's negative. I.e. if the task is capped hard. Looks like this is the old issue that PELT has blocked contribution whereas uclamp does not (runnable only). What's the rationale behind this? Is it because the task didn't get the runtime it needed so we can remove this (artificially accrued) util_avg? Normally we wouldn't remove blocked util_avg and let it rather decay periodically for cfs_rq's and at wakeup for tasks. [...]