Received: by 2002:a05:6a10:f3d0:0:0:0:0 with SMTP id a16csp1012546pxv; Fri, 25 Jun 2021 03:33:43 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz5TMWKRIueWusHUyUgfXL3fB4x14IjOyB1khvz4GH3AKUhk7b4hXKDwwTbkMuu07gC+PGF X-Received: by 2002:a05:6402:31ac:: with SMTP id dj12mr13647743edb.382.1624617223663; Fri, 25 Jun 2021 03:33:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1624617223; cv=none; d=google.com; s=arc-20160816; b=oo2njkph2er2Y9Pxx6GUzoNd4svZhbAPbxLpktERcah1U5O66iREAOv0H1Cp8sYVmz WsV2E5QlIvC4BoYIMFYoOnRTKQNjpsFucWQ76sMneX8b16Kf1LIRMK0WqfJr8mSuNX0X BBhadA4Tcsi4jCJnGp8XzWdhZ1t8sZRyoDG9obV+vwEaIpXkqtCTHOuQRC51sP0gi9T+ d9ESROaLAHhCLIZ77b6QeAVtotzYthjwNBugY5Uy5ENwr8m28n7QOV87d/PXoAx5+v3y 5y81zpFgtUrU3lyexT7CYgNSIIlklN5r3oW/n5uE1c5it7UPSvn4/u45HxnCA9covLGC uDhA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=DudSU3WscslcPrWjUw4Fm/3rb0Z6QTkkUiQd35zmN24=; b=Jx0XvN1RpTvX6cRZoM8GlKHOY2jJtiU1oODT+5xWuQWq0lBkqII89MrjTEt4V45pSz feI6nCajCqtuliPgC0QAnQyrLONfTZ+EjDIa41ntkDP6xIiJNmEhTzJqYwc/B9XRD0ey cqcEr+uhhQQJjj/IS+9Siu7UUFEmQKY2jggs6OWfal2PrYgQuzzLaY4AP4m9oJiLuzSF s85TpbZwm5QdyNXClg6iax0HP52+sfsjGIYg4Y3M1QmY9SjfPPeNzmfaKAEMDa37titi CZ/lU4YtgJ5kFSDzhlcmamxoernRoiVmOBWysFmLlhABSSdTbJxiR4k+zKuqpNMgp9dl C7RA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id r15si5844978edx.343.2021.06.25.03.33.19; Fri, 25 Jun 2021 03:33:43 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231196AbhFYKdW (ORCPT + 99 others); Fri, 25 Jun 2021 06:33:22 -0400 Received: from foss.arm.com ([217.140.110.172]:52532 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229956AbhFYKdV (ORCPT ); Fri, 25 Jun 2021 06:33:21 -0400 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 9E888ED1; Fri, 25 Jun 2021 03:31:00 -0700 (PDT) Received: from localhost (unknown [10.1.195.40]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 3E8BB3F719; Fri, 25 Jun 2021 03:31:00 -0700 (PDT) Date: Fri, 25 Jun 2021 11:30:58 +0100 From: Ionela Voinescu To: Viresh Kumar Cc: Rafael Wysocki , linux-pm@vger.kernel.org, Vincent Guittot , Qian Cai , linux-kernel@vger.kernel.org Subject: Re: [PATCH V3 2/4] cpufreq: cppc: Pass structure instance by reference Message-ID: <20210625103058.GC15540@arm.com> References: <20210623134533.GB12411@arm.com> <20210624022252.zrxsftrvcd43eqra@vireshk-i7> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210624022252.zrxsftrvcd43eqra@vireshk-i7> User-Agent: Mutt/1.9.4 (2018-02-28) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hey, On Thursday 24 Jun 2021 at 07:52:52 (+0530), Viresh Kumar wrote: > On 23-06-21, 14:45, Ionela Voinescu wrote: > > On Monday 21 Jun 2021 at 14:49:35 (+0530), Viresh Kumar wrote: > > > Don't pass structure instance by value, pass it by reference instead. > > > > > > > Might be best to justify the change a bit :) > > I had it and removed later as I thought it would be obvious :) > > > For me this is a judgement call, and I don't really see the reasons for > > changing it: we don't care if the structure is modified or not, as we're > > not reusing the data after the call to cppc_get_rate_from_fbctrs(). > > More so, in this scenario we might not even want for the called function > > to modify the counter values. Also there is no further call to a function > > in cppc_get_rate_from_fbctrs(), that might require references to the > > fb_ctrs. > > > > So what is the reason behind this change? > > How about this commit log then: > > Theoretically speaking, call by reference is cheaper/faster than call by value > for structures as the later requires the compiler to make a new copy of the > whole structure (which has four u64 values here), to be used by the called > function, while with call by reference we just need to pass a single pointer > (u64 on 64-bit architectures) to the existing structure. > > Yes, on modern architectures, the compilers will likely end up using the > processor registers for passing this structure as it isn't doesn't have lot of > fields and it shouldn't be bad eventually, but nevertheless the code should do > the right thing without assuming about the compiler's or architecture's > optimizations. > Yes, that's why "judgement call", which I'll let you make. The code is sane and I like the longer commit message. Reviewed-by: Ionela Voinescu > Don't pass structure instance by value, pass it by reference instead. > > -- > viresh