Received: by 2002:a05:7412:31a9:b0:e2:908c:2ebd with SMTP id et41csp4211632rdb; Thu, 14 Sep 2023 15:44:30 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGAcCfhYW0T8+ynMlYggzzML3eJW2YSj/yuJTLfGCC+DjygxLktmlrB1qlacriYXTBezZ7y X-Received: by 2002:a05:6a20:6a20:b0:159:f5fb:bf74 with SMTP id p32-20020a056a206a2000b00159f5fbbf74mr139246pzk.3.1694731470247; Thu, 14 Sep 2023 15:44:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1694731470; cv=none; d=google.com; s=arc-20160816; b=0s0ad1H1nBiWVIZmlxFi1dgWwRFpSeYIYHnp7m/sE/j0C88hJSBg2qTYMBY6Oj/vuf AjLEGySa884ln4MtPSCqShYtGcQYcfoYKirVLHRGrM8Zaxq1sWTltxsTduttJpq2XQdh YYCk0QDrb5oW1LG6ULJqsZ4wHjwYBL8qug0BBo8k7ub/KlfBjWoDq4Eqv/siwOP6wInN EiI+v+K/597aJWigchh9t1uUk7UP9H3yJSzStbuhcMRBXtiWx3q+VKuX8X8Vl9nKojz+ XTnBziExhGY6ePA1ON6Lppmg0/OkqSp/wPf3jRC0cQBEME60IL96oCrgQQkJOmifhwP2 VfiQ== 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=EM3eFodVo02MqjP48/Zt5oG6FCfd9vL3C45cUs3CeJA=; fh=ycFJnpy8R5iLUc5ty1OfUZ27cvG66MEdDjUtmpWymKI=; b=R6pHnH9uxKs2JmnBFdzwAtQ4fREu315+qU+knQZUXW6pnl3Mvn6A+Ckk8FblfwXr6w AVSx5txOhrCN5kpuygkUk+VKqlbOFuRLcVv8DEGCmidnEs9Ha8U1QPJUhcQxhGWsBX2C LMT0Y7mhc6V1KaL9gQ12PBkktwV0W0BOn8MX37x9ovNxbxIM23z0zPm5cu0fXeiAM2tl UYeoc9Fhgi7pccEgLH0z2yGahlfvga52+873E9ww4uHeP0VPYR6pWwbO405pcUfQ2q0J DAf+LBjEG8CYHewetEs2Q7lzUBN1dz0gCMHP1+vQNmiDpeX31S1e3rlfsO35M8+3UQ5n N7Wg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.34 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 howler.vger.email (howler.vger.email. [23.128.96.34]) by mx.google.com with ESMTPS id n67-20020a632746000000b00573fbbf187dsi2217903pgn.216.2023.09.14.15.44.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 14 Sep 2023 15:44:30 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.34 as permitted sender) client-ip=23.128.96.34; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.34 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 out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by howler.vger.email (Postfix) with ESMTP id 248E7826C4D7; Thu, 14 Sep 2023 13:46:05 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at howler.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229836AbjINUqG (ORCPT + 99 others); Thu, 14 Sep 2023 16:46:06 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45400 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229473AbjINUqG (ORCPT ); Thu, 14 Sep 2023 16:46:06 -0400 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 019212120; Thu, 14 Sep 2023 13:46:01 -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 D9C881FB; Thu, 14 Sep 2023 13:46:38 -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 D1F0D3F738; Thu, 14 Sep 2023 13:45:57 -0700 (PDT) Message-ID: Date: Thu, 14 Sep 2023 22:45:46 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: [PATCH 1/4] sched: consolidate and cleanup access to CPU's max compute capacity Content-Language: en-US To: Vincent Guittot , linux@armlinux.org.uk, catalin.marinas@arm.com, will@kernel.org, paul.walmsley@sifive.com, palmer@dabbelt.com, aou@eecs.berkeley.edu, sudeep.holla@arm.com, gregkh@linuxfoundation.org, rafael@kernel.org, mingo@redhat.com, peterz@infradead.org, juri.lelli@redhat.com, rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de, bristot@redhat.com, vschneid@redhat.com, viresh.kumar@linaro.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org, linux-pm@vger.kernel.org Cc: conor.dooley@microchip.com, suagrfillet@gmail.com, ajones@ventanamicro.com, lftan@kernel.org References: <20230901130312.247719-1-vincent.guittot@linaro.org> <20230901130312.247719-2-vincent.guittot@linaro.org> From: Dietmar Eggemann In-Reply-To: <20230901130312.247719-2-vincent.guittot@linaro.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (howler.vger.email [0.0.0.0]); Thu, 14 Sep 2023 13:46:05 -0700 (PDT) On 01/09/2023 15:03, Vincent Guittot wrote: > Remove struct rq cpu_capacity_orig field and use arch_scale_cpu_capacity() > instead. > > Scheduler uses 3 methods to get access to the CPU's max compute capacity: > - arch_scale_cpu_capacity(cpu) which is the default way to get CPU's capacity. > - cpu_capacity_orig field which is periodically updated with > arch_scale_cpu_capacity(). > - capacity_orig_of(cpu) which encapsulates rq->cpu_capacity_orig > > There is no real need to save the value returned by arch_scale_cpu_capacity() > in struct rq. arch_scale_cpu_capacity() returns: > - either a per_cpu variable. > - or a const value for systems which have only one capacity. > > Remove cpu_capacity_orig and use arch_scale_cpu_capacity() everywhere. > > No functional changes. > > some tests of Arm64: > small SMP device (hikey): no noticeable changes > HMP device (RB5): hackbench shows minor improvement (1-2%) > large smp (thx2): hackbench and tbench shows minor improvement (1%) > > Signed-off-by: Vincent Guittot Next to util_fits_cpu() which uses capacity_orig as a local variable (which is fine) there is sis() referring to capacity_orig in a comment. Documentation/scheduler/sched-capacity.rst uses the term `capacity_orig` in chapter 1.2 to explain the difference between CPU's maximum (attainable) capacity and capacity as the former reduced by pressure. Not sure if you want to change those refs as well with this patch? People might get confused about the term `capacity_orig` pretty soon. Reviewed-by: Dietmar Eggemann