Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp799648ybe; Thu, 5 Sep 2019 06:12:46 -0700 (PDT) X-Google-Smtp-Source: APXvYqzwg+DMfq8M5tIjuaDULCedkA8RgLugMxRXmRA5gTvDdlfYTN8wLHxhwWrjufVOx93+TD7U X-Received: by 2002:a17:90b:f03:: with SMTP id br3mr2548491pjb.93.1567689166837; Thu, 05 Sep 2019 06:12:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1567689166; cv=none; d=google.com; s=arc-20160816; b=x19IKnWjvNN+Iq8EsYhSLwXC3ZjtGmPN8FJyA4jebG6M2FdGi/crzC+JKz9r92gUUn +Jj0RFBMxHo45p9jfN2Yx72foaRvxPMv3AvVQZgaM69/OBGaP/bV/feWoKbLRWh7yBgm QiL8uehoAmT7VTzhPlAt4FiNedUDOXosbgjrJKFQ7MzzPWy4PeSHTq2CksLiVZ1vMWJU PmVtn8ICXHZmt+nHBgUw8+KVE9oqN3lMzbDDJbCkFhiyZFh51dR3BLVz9unMxjqqR9nx D1h0cGZGN68hwV4PAIQ+trm1R4HHMVGHhKHG8NwhC7iHX5ErYZEeysrkR/+5h+tIUxHy yn+g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:in-reply-to :subject:cc:to:from:user-agent:references; bh=z+QsgeOGem7W7pZ9mGN3zzNHYc+MGRquJI6HX0NGuVQ=; b=Xbh/EPg1yOpwkYbjf9yR4KCN3FZgZVm7hqSfVWkccZGG4FGDRS/UBA4qQgUFfnMsyQ brUE3joP0GYtF3U2O2Jjnz6dWVr+nz1T/lYLxq2jzsL3QmE8CNOmxkUIFDPQFrhayP16 CtDXhgmPvFqNcLbTcDn1SLX+YosPzg4RBfMiJ3j3cKc5D2Jsb5Q+yZqbUf8m7XlMD34n BYBTayu+XLoXwDfAm98LP2T3WMWEMfNxp16oHHNIlL43nbWSL1lFqxoM+mxRH3d971P1 ShUR4eb4jQVVvihua+uBaim4gHXlezTjKd2zTJub4KdVkkPLjxK4uGJsXZs1WTExQBKo N4Iw== 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 j25si2081640pfi.264.2019.09.05.06.12.30; Thu, 05 Sep 2019 06:12:46 -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 S2388597AbfIELkG (ORCPT + 99 others); Thu, 5 Sep 2019 07:40:06 -0400 Received: from foss.arm.com ([217.140.110.172]:42896 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730753AbfIELkG (ORCPT ); Thu, 5 Sep 2019 07:40:06 -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 8DF2628; Thu, 5 Sep 2019 04:40:05 -0700 (PDT) Received: from e110439-lin (e110439-lin.cambridge.arm.com [10.1.194.43]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id BBCC43F718; Thu, 5 Sep 2019 04:40:03 -0700 (PDT) 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> <20190905111346.2w6kuqrdvaqvgilu@e107158-lin.cambridge.arm.com> <20190905113002.GK2349@hirez.programming.kicks-ass.net> User-agent: mu4e 1.3.3; emacs 26.2 From: Patrick Bellasi To: Peter Zijlstra Cc: Qais Yousef , Subhra Mazumdar , linux-kernel@vger.kernel.org, mingo@redhat.com, tglx@linutronix.de, steven.sistare@oracle.com, dhaval.giani@oracle.com, daniel.lezcano@linaro.org, vincent.guittot@linaro.org, viresh.kumar@linaro.org, tim.c.chen@linux.intel.com, mgorman@techsingularity.net, parth@linux.ibm.com Subject: Re: [RFC PATCH 1/9] sched,cgroup: Add interface for latency-nice In-reply-to: <20190905113002.GK2349@hirez.programming.kicks-ass.net> Date: Thu, 05 Sep 2019 12:40:01 +0100 Message-ID: <87ftlb2cq6.fsf@arm.com> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Sep 05, 2019 at 12:30:02 +0100, Peter Zijlstra wrote... > On Thu, Sep 05, 2019 at 12:13:47PM +0100, Qais Yousef wrote: >> On 09/05/19 12:46, Peter Zijlstra wrote: > >> > This is important because we want to be able to bias towards less >> > importance to (tail) latency as well as more importantance to (tail) >> > latency. >> > >> > Specifically, Oracle wants to sacrifice (some) latency for throughput. >> > Facebook OTOH seems to want to sacrifice (some) throughput for latency. >> >> Another use case I'm considering is using latency-nice to prefer an idle CPU if >> latency-nice is set otherwise go for the most energy efficient CPU. >> >> Ie: sacrifice (some) energy for latency. >> >> The way I see interpreting latency-nice here as a binary switch. But >> maybe we can use the range to select what (some) energy to sacrifice >> mean here. Hmmm. > > It cannot be binary, per definition is must be ternary, that is, <0, ==0 > and >0 (or middle value if you're of that persuasion). > > In your case, I'm thinking you mean >0, we want to lower the latency. > > Anyway; there were a number of things mentioned at OSPM that we could > tie into this thing and finding sensible mappings is going to be a bit > of trial and error I suppose. > > But as patrick said; we're very much exporting a BIAS knob, not a set of > behaviours. Right, although I think behaviours could still be exported but via a different and configurable interface, using thresholds. Either at compile time or via procfs maybe we can expose and properly document what happen in the scheduler if/when a task has a "latency niceness" crossing a given threshold. For example, by setting something like: /proc/sys/kernel/sched_cfs_latency_idle = 1000 we state that the task is going to be scheduled according to the SCHED_IDLE policy. ( ( (tomatoes target here) ) ) Not sure also if we wanna commit to user-space APIs how we internally map/translate a "latency niceness" value into a scheduler behaviour bias. Maybe better not at least at the very beginning. Best, Patrick -- #include Patrick Bellasi