Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp1130513ybe; Fri, 6 Sep 2019 12:18:39 -0700 (PDT) X-Google-Smtp-Source: APXvYqx74KoDFq0nVpNOy+9dT0IQc59MymsasglVDSrdCmuxSLbmCQE1YlHYDvmX+BddI4KlDiYj X-Received: by 2002:a17:90a:c597:: with SMTP id l23mr11696397pjt.62.1567797519060; Fri, 06 Sep 2019 12:18:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1567797519; cv=none; d=google.com; s=arc-20160816; b=W8x+RqNzz+OadFZI7Umeq7DM+syVgvsK/PEHZIaYN+QZU8h4hXqidxz7FPdriRMUP+ ywGV4iLtp5Fwu+Ucvt+Aq7F/6244/y/+4OmNI/xfWlBSKtanZ6ThaLPDx0Pa1d5rFOpE kfw9ik6s05zrNNmnS9WmDOu16WxVMRafE/lv+sb1PxgkaNLKasp2iwXHPCXX51LvrDK0 a0/yepDXbh+/phTEIqyc4cl4IYPBPbDR+d/Vh+Mq7WZRxUKSyKLyo2/VcBK7JbodTKMe eEXL4sF5NmS1M2JX5mk3Xis9CcS+ZG/4y65oC7iCyQRafPXZGcyKjw1L6v2aGrST83by grNA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=aOQeqxzL2VcRL6ZYImhbl/u4E/vqj+oJ+z2PtQzLoSA=; b=e0ti0RxaogX9sU5AFVWzi7GKS8O3EBUbzKOPi3XdhBO2JzOrSDP96S7y/oCAJyYLuZ SNGI8aHrPE7OkHhTxcDAPNwEK6uNYS4iaCjRfMLWRG2nzFApJgKATZFzvnQ+Hw8ryaXy ZB2NwjI2FVkBYIqgZ1/dOQoK2N6iBq0VBOaFqY0uiayAjvl9727gjFZuRXl3MCgjBanZ ECZKBP1QfMTyLpsLsDpbuJM2GtKZ2i3hSYeMiOa7UFt+ai/JhWEIAKrnQF9AdeU5Rx5m 7a9T09CZAIAiXUxl8MEqEu9fN1Ikd2I/HDcbAiEL7V6BduG+ytTdshmspxQWtqcb5sA4 zeiQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=HliUuNxj; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id o19si5542092pjq.12.2019.09.06.12.18.23; Fri, 06 Sep 2019 12:18:39 -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; dkim=pass header.i=@linaro.org header.s=google header.b=HliUuNxj; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2394465AbfIFOco (ORCPT + 99 others); Fri, 6 Sep 2019 10:32:44 -0400 Received: from mail-lj1-f195.google.com ([209.85.208.195]:39616 "EHLO mail-lj1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732020AbfIFOco (ORCPT ); Fri, 6 Sep 2019 10:32:44 -0400 Received: by mail-lj1-f195.google.com with SMTP id j16so6218517ljg.6 for ; Fri, 06 Sep 2019 07:32:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=aOQeqxzL2VcRL6ZYImhbl/u4E/vqj+oJ+z2PtQzLoSA=; b=HliUuNxjiuAHyl/V5+MxFwm7cnCiZRak2XtOgE2mD3DhaMnq1HqG8GD5Ed23ZQDjxf VspcUw0/FR3t62kogFTm+aF/6uBLcc5+LAJ4WwsA0nuf5P5Ye7nF5QMOp3A4FBAzQujK miKVpktI+xmtcSJEiB7ye3pZg1QgUV4O6BNkinKWGMO3QSdV60FS4yCv+dfmD1Auzfyo dclEvqnYEn6wn66KlP+jdjf2WlLrtsxH6AOisYzEHjFnoMPMFhGn5EvPUgb8yS9pRGlk oPMhfrgGd9Sb7YjZwfTL8FtXa5oq2mDlc2O+R0Rri15eQGzn4pBzC8lnlP7XtlgNH+/u RnUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=aOQeqxzL2VcRL6ZYImhbl/u4E/vqj+oJ+z2PtQzLoSA=; b=OZeYLuGYkeHLd799HqYoj3HY4YEnoR+bjxo3PbZcoROyrzRe4GgeJhuGV+p7t4l+BD XD2Hm/GcL9soVdOHh/yPW1u7YcJpJ4I6C77jVXwRc9I9QcEMv9B1rQ6gx60cX1c5zRRT m/du414L4JlezlKRsKXaN4qWp0RXiFIJdikkfvR5aKnPrbjkSftfhqkaoLmMjleQQm0n MdXUqEUm19zETTrUMETARbKNkShVl5V8Hil3CUqjSU/LiJBg+1pOq1kyTPKHjm5DJoSE VZIjQq0Cv0ulP4Tqv8rYketUmhL/opUThpvZVmlstVt8yetRo03AhPmIagjxmNQPJE72 e+WQ== X-Gm-Message-State: APjAAAW2QRh8g9Ng2yeXRi7A4Cr/MjS3fg7ut4LQzAJ5VASIcwL7Spi3 2SIWyEtNMxJohooMwDZO2N6IQoRv1rz2lrgmyCOm2A== X-Received: by 2002:a2e:94cd:: with SMTP id r13mr5964644ljh.24.1567780361923; Fri, 06 Sep 2019 07:32:41 -0700 (PDT) MIME-Version: 1.0 References: <20190830174944.21741-1-subhra.mazumdar@oracle.com> <20190830174944.21741-2-subhra.mazumdar@oracle.com> <20190905083127.GA2332@hirez.programming.kicks-ass.net> <87r24v2i14.fsf@arm.com> <20190905104616.GD2332@hirez.programming.kicks-ass.net> <87imq72dpc.fsf@arm.com> <87d0ge3n85.fsf@arm.com> <3bb17e15-5492-b78c-20a8-5989519f20e2@linux.ibm.com> <75e782c7-121d-a0ea-7fbf-efb0c83f50e6@arm.com> In-Reply-To: <75e782c7-121d-a0ea-7fbf-efb0c83f50e6@arm.com> From: Vincent Guittot Date: Fri, 6 Sep 2019 16:32:30 +0200 Message-ID: Subject: Re: [RFC PATCH 1/9] sched,cgroup: Add interface for latency-nice To: Valentin Schneider Cc: Parth Shah , Patrick Bellasi , Peter Zijlstra , Subhra Mazumdar , linux-kernel , Ingo Molnar , Thomas Gleixner , steven.sistare@oracle.com, Dhaval Giani , Daniel Lezcano , viresh kumar , Tim Chen , Mel Gorman Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 6 Sep 2019 at 16:13, Valentin Schneider wrote: > > On 06/09/2019 13:45, Parth Shah wrote:> > > I guess there is some usecase in case of thermal throttling. > > If a task is heating up the core then in ideal scenarios POWER systems throttle > > down to rated frequency. > > In such case, if the task is latency sensitive (min latency nice), we can move the > > task around the chip to heat up the chip uniformly allowing me to gain more performance > > with sustained higher frequency. > > With this, we will require the help from active load balancer and latency-nice > > classification on per task and/or group basis. > > > > Hopefully, this might be useful for other arch as well, right? > > > > Most of the functionality is already there, we're only really missing thermal > pressure awareness. There was [1] but it seems to have died. Thara still works on it but she has been sidetracked on other activities and It takes more time than expected to run all tests with different averaging window and process the results > > > At least with CFS load balancing, if thermal throttling is correctly > reflected as a CPU capacity reduction you will tend to move things away from > that CPU, since load is balanced over capacities. > > > For active balance, we actually already have a condition that moves a task > to a less capacity-pressured CPU (although it is somewhat specific). So if > thermal pressure follows that task (e.g. it's doing tons of vector/float), > it will be rotated around. > > However there should be a point made on latency vs throughput. If you > care about latency you probably do not want to active balance your task. If > you care about throughput, it should be specified in some way (util-clamp > says hello!). > > It sort of feels like you'd want an extension of misfit migration (salesman > hat goes on from here) - misfit moves tasks that are CPU bound (IOW their > util is >= 80% of the CPU capacity) to CPUs of higher capacity. It's only > enabled for systems with asymmetric capacities, but could be enabled globally > for "dynamically-created asymmetric capacities" (IOW RT/IRQ/thermal pressure > on SMP systems). > > On top of that, if we make misfit consider e.g. uclamp.min (I don't think > that's already the case), then you have your throughput knob to have *some* > designated tasks move away from (thermal & else) pressure. > > > [1]: https://lore.kernel.org/lkml/1555443521-579-1-git-send-email-thara.gopinath@linaro.org/