Received: by 10.223.176.46 with SMTP id f43csp1154884wra; Wed, 24 Jan 2018 11:32:26 -0800 (PST) X-Google-Smtp-Source: AH8x226OnHkJ2rV5iwvjDeXXrXCRfyAfD/YiWLxaaODlZwglxX9j63K/H7rujLUPRayxqce6y5Dv X-Received: by 10.101.72.143 with SMTP id n15mr11197778pgs.181.1516822346229; Wed, 24 Jan 2018 11:32:26 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1516822346; cv=none; d=google.com; s=arc-20160816; b=vtj1Bv09OK1WJZpDcCpy+2rqR6c153EzjyILxH36/mEr/B/fvC1lTG6W88Ds9gaoVi u9g+N1lQatYGP6Pz2XpDAWr5VLtKS3q7uSCuwfPaRGJcFyYy7a0ms5mm5mZJEZ8+6YID kMbiOjECeNoPkxTq10O3/0mS0L68Q0r93qMyvSIxdgCQwDSD17H5QWpSSWPVEVQckssO KQKX9NKyOo9q1Dh0ZaSaRWJg9OVkrsJPNsmjEsG39I2iurpFKqGpVm+eeYJOqOcbIKGZ qUGKBxHDxblrPBu8rIJdLxKi9DlBnB8pSorQ+l3l9GFi82jg0Hd5mFq1g7ORpGiHcGR+ oXpQ== 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=LKe+hkqy0C07XImDUlIve6Xpdm4V0CQiRSIzKYfzjRk=; b=BKLmZDhqzSMJwGHT+MXZ4F0OY4KLoMvMjFZHkZsQ2kC1iwNo08evteM/reP+A7brJ/ bJCvnVqtXiUDPUMsrEa9PwiTuqLVE+4K6Ko1PKGKQQoeOmxcV2bqpWyqauYOeIXKPXII 7l1sRbuqpyofoCTvINgUKkePjFZRs3+drm6H9HYp4+x0Ew8LKmIvBurEVhOob4YamqJZ laIhkdK5dcIqbUshdNPzSr/omfafpSmorT87u8wMZSTEFeho64Np2yPWTKx2RG5frtt3 E0ykjyFES4F1KFIawXMXRK9b04CoNulfmBFSrIIVrsBnJBTqGMDMzagpG7qQjFD2zxoY hVcQ== 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 a7-v6si609939plz.613.2018.01.24.11.32.11; Wed, 24 Jan 2018 11:32:26 -0800 (PST) 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 S932135AbeAXTbs (ORCPT + 99 others); Wed, 24 Jan 2018 14:31:48 -0500 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:56874 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752339AbeAXTbo (ORCPT ); Wed, 24 Jan 2018 14:31:44 -0500 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 9640515A2; Wed, 24 Jan 2018 11:31:43 -0800 (PST) Received: from e110439-lin (e110439-lin.cambridge.arm.com [10.1.210.68]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 16FD13F318; Wed, 24 Jan 2018 11:31:40 -0800 (PST) Date: Wed, 24 Jan 2018 19:31:38 +0000 From: Patrick Bellasi To: Pavan Kondeti Cc: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, Ingo Molnar , Peter Zijlstra , "Rafael J . Wysocki" , Viresh Kumar , Vincent Guittot , Paul Turner , Dietmar Eggemann , Morten Rasmussen , Juri Lelli , Todd Kjos , Joel Fernandes , Steve Muckle Subject: Re: [PATCH v3 2/3] sched/fair: use util_est in LB and WU paths Message-ID: <20180124193138.GB5739@e110439-lin> References: <20180123180847.4477-1-patrick.bellasi@arm.com> <20180123180847.4477-3-patrick.bellasi@arm.com> <20180124113342.GD30677@codeaurora.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180124113342.GD30677@codeaurora.org> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 24-Jan 17:03, Pavan Kondeti wrote: > Hi Patrick, Hi Pavan, > On Tue, Jan 23, 2018 at 06:08:46PM +0000, Patrick Bellasi wrote: > > static unsigned long cpu_util_wake(int cpu, struct task_struct *p) > > { > > - unsigned long util, capacity; > > + long util, util_est; > > > > /* Task has no contribution or is new */ > > if (cpu != task_cpu(p) || !p->se.avg.last_update_time) > > - return cpu_util(cpu); > > + return cpu_util_est(cpu); > > > > - capacity = capacity_orig_of(cpu); > > - util = max_t(long, cpu_rq(cpu)->cfs.avg.util_avg - task_util(p), 0); > > + /* Discount task's blocked util from CPU's util */ > > + util = cpu_util(cpu) - task_util(p); > > + util = max(util, 0L); > > > > - return (util >= capacity) ? capacity : util; > > + if (!sched_feat(UTIL_EST)) > > + return util; > > At first, It is not clear to me why you are not clamping the capacity to > CPU original capacity. It looks like it is not needed any more with > commit f453ae2200b0 ("sched/fair: Consider RT/IRQ pressure in > capacity_spare_wake()") inclusion. Mainly because the above code now uses only cpu_util() which is already clamped by capacity_orig_of(). However, you made me notice that in the few lines which follows, where I do: > > + /* > > + * These are the main cases covered: > > + * - if *p is the only task sleeping on this CPU, then: > > + * cpu_util (== task_util) > util_est (== 0) > > + * and thus we return: > > + * cpu_util_wake = (cpu_util - task_util) = 0 > > + * > > + * - if other tasks are SLEEPING on the same CPU, which is just waking > > + * up, then: > > + * cpu_util >= task_util > > + * cpu_util > util_est (== 0) > > + * and thus we discount *p's blocked utilization to return: > > + * cpu_util_wake = (cpu_util - task_util) >= 0 > > + * > > + * - if other tasks are RUNNABLE on that CPU and > > + * util_est > cpu_util > > + * then we use util_est since it returns a more restrictive > > + * estimation of the spare capacity on that CPU, by just considering > > + * the expected utilization of tasks already runnable on that CPU. > > + */ > > + util_est = cpu_rq(cpu)->cfs.util_est_runnable; > > + util = max(util, util_est); > > + > > + return util; I should instead clamp util before returning it! ;-) > May be a separate patch to remove the clamping part? No, I think we should keep cpu_util_wake clamped to not affect the existing call sites. I just need to remove it where not needed (done) and add it where needed (will do on the next iteration). > Thanks, > Pavan Cheers Patrick -- #include Patrick Bellasi