Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp3541586imm; Fri, 25 May 2018 07:28:22 -0700 (PDT) X-Google-Smtp-Source: AB8JxZpsKxLQZMshhFb7+g6M3NuNQmWTLIgu2tS6OUEi8kIeSxj6BijewzA6taW/x1ws0kUSFerM X-Received: by 2002:a62:c95c:: with SMTP id k89-v6mr2809352pfg.47.1527258502227; Fri, 25 May 2018 07:28:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527258502; cv=none; d=google.com; s=arc-20160816; b=bTkYTVUAZub4m70iAu9dCFW43Yr+zPSmXO/ypGNsstCUY8XLEYnBcLr6CHm2QJcXiN sy32srovxC137MTs8LW5OCNbtXSWzzqhdOHsymDs+QVSYeJy8LX4d+Mn7/fIPWbEUnIB CmiSuuhsS2SXPYaHxA0BLXNs84i0b5WBvP4S7yPo9soK3nKhsI6puZI7/BbX1qnz7fod hawaGnCVP02Vv0RzN1n2DB2nKwAAtN0zdBMi5VMMjwrh1AhsIfNE78/DzjKEwKK19x/0 DJrFdL/a4e5V8XQPKBsfF2mhhW+HlqMiwZl3Ieca16Yg65T/mhLEyd7rkn84PLcPoOiv 1sbw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=i3dFkCy22DzFv0/bdbzPAZegOyZzolQHc+Ecudr+ehs=; b=u/Suq+S/W6dIBOTL4TgO7I22JgKV/Xafz2yRx6HHShhWd8Zlj5qp0mBEE3V1Xh+Syg rhCqY6XYCdad+otbB58Yg3AhCT626Cg6GDdUWTkSz7LFeyEVIugVa5AhNKGbGY5HXV6I gBwW08xHcuIh/gaWy6E32PpsKgw4qqxfCIZWujKNraASEI+PyeBISVl1PeWvbOw1vXv0 eyBHCFEsJrVwSPS95lifLKEsRaHKw0b9W3RJk2UxhO3sH4Dv4ajlrcFbhx66uaNmWcqW gpeLBeV5wfVRSqythevQR9+kdwrso4+68v3r+vbuiwU1MGW6eTuIkWsOP8t8bZ2yNA2r /0Bw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g130-v6si23406343pfc.366.2018.05.25.07.28.06; Fri, 25 May 2018 07:28:22 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S936203AbeEYO0y (ORCPT + 99 others); Fri, 25 May 2018 10:26:54 -0400 Received: from foss.arm.com ([217.140.101.70]:34614 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S935826AbeEYO0w (ORCPT ); Fri, 25 May 2018 10:26:52 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 7FA0F80D; Fri, 25 May 2018 07:26:52 -0700 (PDT) Received: from e108498-lin.cambridge.arm.com (e108498-lin.cambridge.arm.com [10.1.210.84]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 50C083F557; Fri, 25 May 2018 07:26:50 -0700 (PDT) Date: Fri, 25 May 2018 15:26:48 +0100 From: Quentin Perret To: Vincent Guittot Cc: peterz@infradead.org, mingo@kernel.org, linux-kernel@vger.kernel.org, rjw@rjwysocki.net, juri.lelli@redhat.com, dietmar.eggemann@arm.com, Morten.Rasmussen@arm.com, viresh.kumar@linaro.org, valentin.schneider@arm.com Subject: Re: [PATCH v5 01/10] sched/pelt: Move pelt related code in a dedicated file Message-ID: <20180525142648.GC15173@e108498-lin.cambridge.arm.com> References: <1527253951-22709-1-git-send-email-vincent.guittot@linaro.org> <1527253951-22709-2-git-send-email-vincent.guittot@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1527253951-22709-2-git-send-email-vincent.guittot@linaro.org> User-Agent: Mutt/1.8.3 (2017-05-23) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Vincent, On Friday 25 May 2018 at 15:12:22 (+0200), Vincent Guittot wrote: > We want to track rt_rq's utilization as a part of the estimation of the > whole rq's utilization. This is necessary because rt tasks can steal > utilization to cfs tasks and make them lighter than they are. > As we want to use the same load tracking mecanism for both and prevent > useless dependency between cfs and rt code, pelt code is moved in a > dedicated file. I tried to do a quick build test to check if this patch actually introduces function calls or not in the end. The base branch I used is today's tip/sched/core ("2539fc82aa9b sched/fair: Update util_est before updating schedutil"). * x86, x86_defconfig - Without patch: queper01 ~/work/linux> size vmlinux text data bss dec hex filename 17476437 4942296 999628 23418361 16555f9 vmlinux - With patch: queper01 ~/work/linux> size vmlinux text data bss dec hex filename 17476757 4942296 999628 23418681 1655739 vmlinux * arm64, defconfig - Without patch: queper01 ~/work/linux> size vmlinux text data bss dec hex filename 11349598 6440764 395336 18185698 1157de2 vmlinux - With patch: queper01 ~/work/linux> size vmlinux text data bss dec hex filename 11349598 6440764 395336 18185698 1157de2 vmlinux It's also true that I'm not using the same gcc version for both archs (both quite old TBH -- 4.9.4 for arm64, 4.8.4 for x86). The fact that the code size doesn't change for arm64 suggests that we already had function calls for the __update_load_avg* functions, so the patch isn't making things worst than they already are, but for x86, this is different. Have you tried on x86 on your end ? And also, I understand these functions are large, but if we _really_ want to inline them even though they're big, why not putting them in sched-pelt.h ? We probably wouldn't accept that for everything, but those PELT functions are used all over the place, including latency sensitive code paths (e.g. task wake-up). Thanks, Quentin