Received: by 2002:ab2:1149:0:b0:1f3:1f8c:d0c6 with SMTP id z9csp1931224lqz; Tue, 2 Apr 2024 01:58:30 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCVoJ7P2Cljh+Iv0XRkVKljigkrNicl2vDDEdjYjpFFIqk2lq78jcbih/1bxXCnTJkovEMrbU1xr0cJShpGPnC3LM6ky0/p9VwJqUNeYsg== X-Google-Smtp-Source: AGHT+IHyy516TtqqQOAdktle5nvjdqoVfUr5sbGmYG45vffKbCtRf3mqcb4kT43fEmp7PMg5BxrJ X-Received: by 2002:ae9:c117:0:b0:789:fe83:c601 with SMTP id z23-20020ae9c117000000b00789fe83c601mr13413773qki.53.1712048310449; Tue, 02 Apr 2024 01:58:30 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1712048310; cv=pass; d=google.com; s=arc-20160816; b=pc8Kpe2vQ8BbcKQHe7mOCtTolOF8sUBLMk7J4vbr+Zw6N4yE4bTGn0arVD5JvelYlH oz/po5Sup6Gsvi0GI915zchUX5LOyvmQJAmu1bMrjXrK2/VkBCdYYcjFjbwKjuBcR96p 5C+ekm0xX+2YTdGshNDyKTxjsmVPkIDJAJUhQbHOJeNzrcnJLUcDmavIffFZrfkhyqPt i8Qov1iEbV/eBRVzQ+wKceb57jNgbL5AFW+77wSTVAaR64nWH5xQxVvI1wV5Y8s2uVfE WFLdwhQfIWt7ybEFSQL/XTRSIYR9xIS5rMVXFMU894Q3jBvTN6kmU8DXipz0D1nUFYdU RIxQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:date:message-id:dkim-signature; bh=vjeLiKB25shTPfBbKnNL5XlTVHkDE3ktnIcrN/G3DQc=; fh=dFUVbrNnk0u665fq9DkuNUrC4hM8iNRPp7LfuPZgtxw=; b=ln19DT3L2d99942GeG8KBM+00w24hCZeBSfLgVCqTJGJZ82Ka+vBGRB/mTeGlvD5Qu lCH+iiQAE1+5sh2G2RzjGC816OtSOOum6SrnDWnWMLLXJ3m4u0J4uNn3VF+npHtGc1QY b0tVM81MQAqKP6vHEIfUI/Ga52sD78CbrUzryfxsyTTmMak53bAXQfZuyWDepPp5CF9n E3wIr8QHhkWFFFonoazfnNL5UMr2AQ6SOoNNroVmFbdfyv9HqfZepQyKki2quvYHUCED s3lmR3Csur6O84MpsxgrlhJhd9TlFoEdQERAGYMnWB/Brc88iN0i4rrraxcLk5EZGqIV r8HQ==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@ibm.com header.s=pp1 header.b=Yb1g7Sly; arc=pass (i=1 spf=pass spfdomain=linux.ibm.com dkim=pass dkdomain=ibm.com dmarc=pass fromdomain=linux.ibm.com); spf=pass (google.com: domain of linux-kernel+bounces-127591-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-127591-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=REJECT sp=NONE dis=NONE) header.from=ibm.com Return-Path: Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [2604:1380:45d1:ec00::1]) by mx.google.com with ESMTPS id u19-20020a05620a121300b0078a70ff8399si11151064qkj.476.2024.04.02.01.58.30 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 02 Apr 2024 01:58:30 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-127591-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1; Authentication-Results: mx.google.com; dkim=pass header.i=@ibm.com header.s=pp1 header.b=Yb1g7Sly; arc=pass (i=1 spf=pass spfdomain=linux.ibm.com dkim=pass dkdomain=ibm.com dmarc=pass fromdomain=linux.ibm.com); spf=pass (google.com: domain of linux-kernel+bounces-127591-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-127591-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=REJECT sp=NONE dis=NONE) header.from=ibm.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 ny.mirrors.kernel.org (Postfix) with ESMTPS id 220E11C22149 for ; Tue, 2 Apr 2024 08:58:30 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 1260353E3D; Tue, 2 Apr 2024 08:58:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=ibm.com header.i=@ibm.com header.b="Yb1g7Sly" Received: from mx0b-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4B5823D544 for ; Tue, 2 Apr 2024 08:58:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=148.163.158.5 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712048306; cv=none; b=AWR9MQsaCA0rgGLhaLc2sAMQhVadwMMK1CGDMWFpjH+Gc58tkGP9z1bP8DtXzMiy7g61zkPmcOtgiJkoQCuPP6lJRWeIzDFQrsZijCFkXMNkAbH0bElcqrHUY76W8im4tOEwluahJvMmv0UHqUbabXcxgxNCqhHfu+WAWoCVHkQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712048306; c=relaxed/simple; bh=o1gq+NXOPOISE9vCvWrjHc8SwRXA4CCcrp26JlijL8M=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=cRkKZdSzArSaJo8cz+Bn8kFfVioD0eDPA83pGzORC2ImNTTF+HyjbhFEyCHzlr4QK6YzregUW0j1ag5noqKVVkt1Qg1WhZXvYSdiLfGnvcisl3VsVBbnl38dehWmyx59k4zsYlvKC+VfbQKSZhTGZAWONWnxNPNIgFflb4F+TUQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.ibm.com; spf=pass smtp.mailfrom=linux.ibm.com; dkim=pass (2048-bit key) header.d=ibm.com header.i=@ibm.com header.b=Yb1g7Sly; arc=none smtp.client-ip=148.163.158.5 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.ibm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.ibm.com Received: from pps.filterd (m0356516.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 4328vnw5010477; Tue, 2 Apr 2024 08:58:07 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=message-id : date : mime-version : subject : to : cc : references : from : in-reply-to : content-type : content-transfer-encoding; s=pp1; bh=vjeLiKB25shTPfBbKnNL5XlTVHkDE3ktnIcrN/G3DQc=; b=Yb1g7SlyVxG9WmSOXEYHfKwh/e/jHhoLJbK6RVhMAC/GqJQWvH7kK/HDYI3j3hGbcYZI GsgAYw/O7A7AxI3QMmwHthr9A17lsPPgN+tbztD4QTOuL4y7o6Ltadnlw4AbpKvkFSiO uVR/p+VkYcVs51EZUkU+6vEkk06hchNIebAIz5ufzcwa+nEdkrP5BrIuFLBn1/wPlgM2 3p5VkK34jqAawDlsdr3LBGiFkosP2LIwRt1xiW5P1a7dhL9FjWWbqja6cv89xX1uy4Xe icoNFiO/2mndE6TQTws/+3mmpiTO2gxEcK3sp9AoaF7hWxuxcvkFmmh9jhLEYfel0l9y eA== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3x8eyag01n-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 02 Apr 2024 08:58:07 +0000 Received: from m0356516.ppops.net (m0356516.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 4328w6e5010629; Tue, 2 Apr 2024 08:58:06 GMT Received: from ppma22.wdc07v.mail.ibm.com (5c.69.3da9.ip4.static.sl-reverse.com [169.61.105.92]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3x8eyag01g-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 02 Apr 2024 08:58:06 +0000 Received: from pps.filterd (ppma22.wdc07v.mail.ibm.com [127.0.0.1]) by ppma22.wdc07v.mail.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 43275IAv027165; Tue, 2 Apr 2024 08:58:05 GMT Received: from smtprelay05.wdc07v.mail.ibm.com ([172.16.1.72]) by ppma22.wdc07v.mail.ibm.com (PPS) with ESMTPS id 3x6wf05mfw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 02 Apr 2024 08:58:05 +0000 Received: from smtpav02.dal12v.mail.ibm.com (smtpav02.dal12v.mail.ibm.com [10.241.53.101]) by smtprelay05.wdc07v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 4328w3Di23855838 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 2 Apr 2024 08:58:05 GMT Received: from smtpav02.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id DE6A258066; Tue, 2 Apr 2024 08:58:02 +0000 (GMT) Received: from smtpav02.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id BDC5758060; Tue, 2 Apr 2024 08:57:58 +0000 (GMT) Received: from [9.171.24.250] (unknown [9.171.24.250]) by smtpav02.dal12v.mail.ibm.com (Postfix) with ESMTP; Tue, 2 Apr 2024 08:57:58 +0000 (GMT) Message-ID: <3b411431-1a04-4ac4-a6ae-56dd188da0f9@linux.ibm.com> Date: Tue, 2 Apr 2024 14:27:57 +0530 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: [PATCH v2] sched/fair: fix initial util_avg calculation To: Vincent Guittot Cc: Dawei Li , Ingo Molnar , Peter Zijlstra , Juri Lelli , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Daniel Bristot de Oliveira , Valentin Schneider , linux-kernel@vger.kernel.org References: <20240315015916.21545-1-daweilics@gmail.com> Content-Language: en-US From: Vishal Chourasia In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-TM-AS-GCONF: 00 X-Proofpoint-GUID: KjqsdLRmrjnB0M2yj2TmkkQvMvNceNHS X-Proofpoint-ORIG-GUID: 9-5bqLNX5hz24agdTNLHmju4I-nBm1BH X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.1011,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2024-04-02_03,2024-04-01_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxlogscore=999 spamscore=0 impostorscore=0 suspectscore=0 adultscore=0 lowpriorityscore=0 phishscore=0 priorityscore=1501 mlxscore=0 bulkscore=0 malwarescore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2403210000 definitions=main-2404020063 On 02/04/24 2:19 pm, Vincent Guittot wrote: > On Tue, 2 Apr 2024 at 10:44, Vishal Chourasia wrote: >> >> On 02/04/24 11:17 am, Dawei Li wrote: >>> Hi Vishal >>> >>> Thanks for the comment! >>> Do you suggest using scale_load_down() in place of se_weight()? >> scale_load_down should be better. > > se_weight is used for computing sched_entity's pelt signal so keep > using it looks better but all this clearly just nitpick because that > doesn't make any difference Alright. Thank you for the clarification. > >>> It's a soft bug we should fix one way or another before what the >>> comment mentions really happens. >> IIUC, We should be moving towards using full load resolution >> for all the calculations. In that case, we need not worry about scaling load at >> all. Maybe someone could provide context here. >> >>> I am actually confused that we have both se_weight() and >>> scale_load_down(), and they do the same thing. >>> >>> Best regards, >>> Dawei >>> >>> On Mon, Apr 1, 2024 at 3:36 AM Vishal Chourasia wrote: >>>> >>>> On Thu, Mar 14, 2024 at 06:59:16PM -0700, Dawei Li wrote: >>>>> Change se->load.weight to se_weight(se) in the calculation for the >>>>> initial util_avg to avoid unnecessarily inflating the util_avg by 1024 >>>>> times. >>>>> >>>>> The reason is that se->load.weight has the unit/scale as the scaled-up >>>>> load, while cfs_rg->avg.load_avg has the unit/scale as the true task >>>>> weight (as mapped directly from the task's nice/priority value). With >>>>> CONFIG_32BIT, the scaled-up load is equal to the true task weight. With >>>>> CONFIG_64BIT, the scaled-up load is 1024 times the true task weight. >>>>> Thus, the current code may inflate the util_avg by 1024 times. The >>>>> follow-up capping will not allow the util_avg value to go wild. But the >>>>> calculation should have the correct logic. >>>>> >>>>> Signed-off-by: Dawei Li >>>>> --- >>>>> Changes in v2: >>>>> - update the commit message >>>>> --- >>>>> kernel/sched/fair.c | 5 +++-- >>>>> 1 file changed, 3 insertions(+), 2 deletions(-) >>>>> >>>>> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c >>>>> index a19ea290b790..5f98f639bdb9 100644 >>>>> --- a/kernel/sched/fair.c >>>>> +++ b/kernel/sched/fair.c >>>>> @@ -1031,7 +1031,8 @@ void init_entity_runnable_average(struct sched_entity *se) >>>>> * With new tasks being created, their initial util_avgs are extrapolated >>>>> * based on the cfs_rq's current util_avg: >>>>> * >>>>> - * util_avg = cfs_rq->util_avg / (cfs_rq->load_avg + 1) * se.load.weight >>>>> + * util_avg = cfs_rq->avg.util_avg / (cfs_rq->avg.load_avg + 1) >>>>> + * * se_weight(se) >>>>> * >>>>> * However, in many cases, the above util_avg does not give a desired >>>>> * value. Moreover, the sum of the util_avgs may be divergent, such >>>>> @@ -1078,7 +1079,7 @@ void post_init_entity_util_avg(struct task_struct *p) >>>>> >>>>> if (cap > 0) { >>>>> if (cfs_rq->avg.util_avg != 0) { >>>>> - sa->util_avg = cfs_rq->avg.util_avg * se->load.weight; >>>>> + sa->util_avg = cfs_rq->avg.util_avg * se_weight(se); >>>> Hi, >>>> >>>> The comment above the declaration of se_weight function says we should be >>>> using full load resolution and get rid of this helper. >>>> >>>> Should we be adding new user of the helper? >>>> >>>> /* >>>> * XXX we want to get rid of these helpers and use the full load resolution. >>>> */ >>>> static inline long se_weight(struct sched_entity *se) >>>> { >>>> return scale_load_down(se->load.weight); >>>> } >>>> >>>> >>>>> sa->util_avg /= (cfs_rq->avg.load_avg + 1); >>>>> >>>>> if (sa->util_avg > cap) >>>>> -- >>>>> 2.40.1 >>>>> >>