Received: by 2002:a25:b323:0:0:0:0:0 with SMTP id l35csp325525ybj; Thu, 19 Sep 2019 15:06:55 -0700 (PDT) X-Google-Smtp-Source: APXvYqyvhVE4beQ50tsQyMrifANxLygvSfhG38jgvHkprGtC53aSZvTpTBegpl00hayvEIbU9Llf X-Received: by 2002:a50:eb4c:: with SMTP id z12mr18695490edp.155.1568930814904; Thu, 19 Sep 2019 15:06:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1568930814; cv=none; d=google.com; s=arc-20160816; b=vEbWttQsIcZEpiu66aAQ2telb8R5VyRBg1dTqXUGzr1OEB4wz7uE+a4/0AHPjlEb5k P4ysrCkH8DoN1yfLqLtIPGJgNGd/T9oIGUrmnhcte9OqRV8cUwXBduo6Uy+62MP1+CrE nfCO5svETsHvgRaFSYDteqBtbACZ+4KL/LVOyZuw8c2RjTJiyE3JeoXm0kM8fzJpsAm7 2LTOFHbtX3BvtrI70eZnkkoFalEArS9lSn2y5TS8S86p+oyJ4hSP7vTYV3GOND3xbeg/ onosCHJQ59E8YHfjAaiEAgSwPk47NHz5XN9xQiRYGojc9UlU0xXxg/XLOS+I0Sz5Mm8U 7Vcw== 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; bh=tb5SFs6Irs2lUnB9CD3fbqD2KR2vweYpqtqyQdhqJho=; b=Z/TrdugmCHNpbtwozx7WgS6Lr8V3bW512Z4bdNEGLLvsOSgvpjVYTccHwVXkarFHxg H4bZev4b5qopWbuKJdgo1c0bOp9jd4AJi72sdzXGmPJWlpaXQjM/zyV9GgqWfv/d2qyA zVT7lkJS4n9HRb5UG4g8EbtWxYIet4mhIxFM4MTgbGXoU4VCKEh8UBnNRkRcrBx0kjgq dl0gl3IaTuJGpn0ZwXw5H/ohvsv4oR3luywelWbA0jkZHo7ch9OumougZCNNZp0JwFJQ r4lCmtuoSuaifiI0qu8Iw7Gw7jNy658vWnwbl09uVZIrrJD1Ftw/H2eNDxIH0tB0tAnC x/Iw== 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 b44si46229ede.451.2019.09.19.15.06.29; Thu, 19 Sep 2019 15:06:54 -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 S1732724AbfISOnF (ORCPT + 99 others); Thu, 19 Sep 2019 10:43:05 -0400 Received: from foss.arm.com ([217.140.110.172]:59958 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732606AbfISOnF (ORCPT ); Thu, 19 Sep 2019 10:43:05 -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 B4F3C337; Thu, 19 Sep 2019 07:43:04 -0700 (PDT) Received: from e107158-lin.cambridge.arm.com (e107158-lin.cambridge.arm.com [10.1.194.52]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 967393F575; Thu, 19 Sep 2019 07:43:02 -0700 (PDT) Date: Thu, 19 Sep 2019 15:43:00 +0100 From: Qais Yousef To: Parth Shah Cc: linux-kernel@vger.kernel.org, Peter Zijlstra , Patrick Bellasi , subhra mazumdar , tim.c.chen@linux.intel.com, Valentin Schneider , mingo@redhat.com, morten.rasmussen@arm.com, dietmar.eggemann@arm.com, pjt@google.com, vincent.guittot@linaro.org, quentin.perret@arm.com, dhaval.giani@oracle.com, daniel.lezcano@linaro.org, tj@kernel.org, rafael.j.wysocki@intel.com Subject: Re: Usecases for the per-task latency-nice attribute Message-ID: <20190919144259.vpuv7hvtqon4qgrv@e107158-lin.cambridge.arm.com> References: <3e5c3f36-b806-5bcc-e666-14dc759a2d7b@linux.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <3e5c3f36-b806-5bcc-e666-14dc759a2d7b@linux.ibm.com> User-Agent: NeoMutt/20171215 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 09/18/19 18:11, Parth Shah wrote: > Hello everyone, > > As per the discussion in LPC2019, new per-task property like latency-nice > can be useful in certain scenarios. The scheduler can take proper decision > by knowing latency requirement of a task from the end-user itself. > > There has already been an effort from Subhra for introducing Task > latency-nice [1] values and have seen several possibilities where this type of > interface can be used. > > From the best of my understanding of the discussion on the mail thread and > in the LPC2019, it seems that there are two dilemmas; > > 1. Name: What should be the name for such attr for all the possible usecases? > ============= > Latency nice is the proposed name as of now where the lower value indicates > that the task doesn't care much for the latency and we can spend some more > time in the kernel to decide a better placement of a task (to save time, > energy, etc.) > But there seems to be a bit of confusion on whether we want biasing as well > (latency-biased) or something similar, in which case "latency-nice" may > confuse the end-user. > > 2. Value: What should be the range of possible values supported by this new > attr? > ============== > The possible values of such task attribute still need community attention. > Do we need a range of values or just binary/ternary values are sufficient? > Also signed or unsigned and so the length of the variable (u64, s32, etc)? IMO the main question is who is the intended user of this new knob/API? If it's intended for system admins to optimize certain workloads on a system then I like the latency-nice range. If we want to support application writers to define the latency requirements of their tasks then I think latency-nice would be very confusing to use. Especially when one has to consider they lack a pre-knowledge about the system they will run on; and what else they are sharing the resources with. > > > > This mail is to initiate the discussion regarding the possible usecases of > such per task attribute and to come up with a specific name and value for > the same. > > Hopefully, interested one should plot out their usecase for which this new > attr can potentially help in solving or optimizing it. > > > Well, to start with, here is my usecase. > > ------------------- > **Usecases** > ------------------- > > $> TurboSched > ==================== > TurboSched [2] tries to minimize the number of active cores in a socket by > packing an un-important and low-utilization (named jitter) task on an > already active core and thus refrains from waking up of a new core if > possible. This requires tagging of tasks from the userspace hinting which > tasks are un-important and thus waking-up a new core to minimize the > latency is un-necessary for such tasks. > As per the discussion on the posted RFC, it will be appropriate to use the > task latency property where a task with the highest latency-nice value can > be packed. > But for this specific use-cases, having just a binary value to know which > task is latency-sensitive and which not is sufficient enough, but having a > range is also a good way to go where above some threshold the task can be > packed. $> EAS ==================== The new knob can help EAS path to switch to spreading behavior when latency-nice is set instead of packing tasks on the most energy efficient CPU. ie: pick the most energy efficient idle CPU. -- Qais Yousef