From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 0CE383D47D4 for ; Wed, 15 Apr 2026 08:57:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776243470; cv=none; b=jOtRdf0ISf6SJgEKHPb8A2nMTDVQTaoTKd4nfPLfqo+fZp8tAIlM4oV0Qf1BE0Tvv6rKnlADKHhtSEyVsntXnghpp6vIDkuCzG3rCUkd00gXjcULo4UaEc8BTvNMyeMCbjCYleRIyIDzt5tlhliNMFYnWRD2ZEbETJ9LWlBmwlA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776243470; c=relaxed/simple; bh=xNtGwF6yOfYT3XIr0L5TnuKAnj9wEDRvHcMBtZXMqBY=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=kCTq+PwLUTQH3CqJ/vN9fykX8r4lC1Oc1wUX8h4PLotjT7eFu8bvLha/VIsg3TRpAANbr2LZ6vh7CRnbFVOxc6qqvyWEN+tN9flrLH+hT2o2c8WdaJetb49tFmsOgYKBhRaG0xvhzIh7gO4De8wkyWF81csNi9f0I4etxrlDi+Q= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b=rbvTs0ph; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b="rbvTs0ph" 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 AC5204FBA; Wed, 15 Apr 2026 01:57:41 -0700 (PDT) Received: from [10.1.29.43] (e127648.arm.com [10.1.29.43]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 4DE7D3F86F; Wed, 15 Apr 2026 01:57:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1776243467; bh=xNtGwF6yOfYT3XIr0L5TnuKAnj9wEDRvHcMBtZXMqBY=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=rbvTs0phhiOkgik5JnqN7+gBozMtverW+AJZoMTe18rjMoRBIeh2a5/kuBgu5DBl6 hr+vtL0Pvm2w4STe6kcV6tQ2JzBvmsUiMqm0PCVs6YFbOQOV+6gs3OP2YiYfDUcx0f fqvanuN6UhnN21OJvv+qMqRmKst47Ybw/wgJTekU= Message-ID: <87f12180-17c6-4ed7-be05-525bddebc0c6@arm.com> Date: Wed, 15 Apr 2026 09:57:41 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Announcing Sched QoS v0.1-alpha To: Qais Yousef , Ingo Molnar , Peter Zijlstra , Vincent Guittot , John Stultz , Steven Rostedt , Juri Lelli Cc: linux-kernel@vger.kernel.org, Linus Torvalds , Dietmar Eggemann , Mel Gorman , Thomas Gleixner , Tim Chen , Chen Yu , Josh Don , "Rafael J. Wysocki" , Sebastian Andrzej Siewior , Suleiman Souhlal References: <20260415000910.2h5misvwc45bdumu@airbuntu> Content-Language: en-US From: Christian Loehle In-Reply-To: <20260415000910.2h5misvwc45bdumu@airbuntu> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 4/15/26 01:09, Qais Yousef wrote: > Hi everyone > > This is the first announcement of Sched QoS 0.1-alpha release. This is still at > PoC stage and NOT production ready. > > https://github.com/qais-yousef/schedqos > > This is a follow of LPC 2025 discussion about Userspace Assissted Scheduling via Sched QoS > > https://lpc.events/event/19/contributions/2089/ > > > Background and Concepts > ======================= > > The world has changed a _little_ bit in the past 30 years.. > > Modern systems have sophisticated hardware that comes in all shapes and colors. > How software is written to interact with the modern hardware hasn't changed > though. Kernel had to keep up with hardware, but userspace didn't. POSIX is > ancient and didn't evolve to help OS and application writers how to deal with > these changes. > > A major problem faced by many workloads is how to manage resources better so > that important workloads can get the latency or throughput they need, while > still co-exist alongside each others, and while being oblivious of the hardware > they are running on or kernel (scheduler) implementation details. > > Many discussion in this area focused on what kernel interface should look like, > but I think this is the wrong approach. The same way we have libc, pthread etc > to define interface to do common operations that are detached from the OS, we > need to detach how workloads are described from OS specifics. And of course > from hardware by implication. > > Sched QoS utility aims to do that. And it tries to take the unique approach of > Zero-API based approach. > > One of the biggest challenges to adding any new API is the adoption time. It > can easily span 18-14 months if not more. Rolling things out for users to see > benefits has a substantial delay, iterating and reacting to problems will take > similar long time. All in all to reach a maturity point this can end up far > ahead in the future that adoption can never materialize. And it makes the > burden and the par to getting things right the first time very high that > progress can stifle at discussion point. > > Another major challenge is trusting application to provide the right hints. > Managing potential abusers can be difficult (doable, but back to previous point > can lead to stifling discussion to agree on the 'right' approach). But also the > potential ABI implications that can make easy evolution and fast iteration > hard. > > With config based hinting we eliminate these. Admins (which on many systems is > the user, because it's Linux..) will have to choose and approve the config to > be applied for any app. It also provides additional flexibility where > a workload is 'important' on one system, but is actually a 'background' on > another. Group control (discussed at LPC) is better way to manage this, but > generally it inherently better handles potential perf/power trade-offs > variations if tagging could be done differently to suite different needs. e.g: > you can have more than one way to tag an application to suite potential > different needs rather than being stuck with a single one imposed on you. > > By using NETLINK to listen to when new tasks are forked and processes are > created, we can easily create a config based system to auto tag tasks based on > userspace description. > > For example the following config > > { > "chrome": { > "qos": "QOS_USER_INTERACTIVE" > }, > "gcc": { > "qos": "QOS_BACKGROUND" > } > } > > is a poor man's way to tell the system the user wants to treat Chrome as > a user_interactive application and gcc (compiler) as a background one. > > This is a provisional way for 'easy' tagging. The real intended use is for > specific tasks within an application (process) to be tagged to describe their > individual role > > { > "chrome": { > "thread_qos": { > "chrome": "QOS_USER_INTERACTIVE", > "some_bg_task": "QOS_BACKGROUND" > } > } > } > > so that real interactive tasks are given the resource they need, and the noise > is reduced to just that. Note by default everything will be treated as > QOS_DEFAULT, which is set to match QOS_UTILITY. IOW everything is assumed to be > random 'noise' by default. Which makes delivering better beset-effort QoS > easier. > > Roles > ===== > > This model is based on existing one shipped in the industry [1] that its users > are happy with. It breaks down the tasks' role into 4 classes: > > * USER_INTERACTIVE: Requires immediate response > * USER_INITIATED: Tolerates short latencies, but must get work done quickly still > * UTILITY: Tolerates long delays, but not prolonged ones > * BACKGROUND: Doesn't mind prolonged delays > * DEFAULT: All untagged tasks will get this category which will map to utility. > > EEVDF should allow us to describe these different levels via specifying > different runtime (custom slice) to each class. Shortest slice should still be > long enough not to sacrifice throughput. Nice values will operate as bandwidth > control so that long running user_interactive tasks can't be starved by long > running background ones if they had to run on the same CPU under overloaded > scenarios. uclamp_max help constraint power impact and access to expensive > highest performance levels. > > Mapping > ------- > > { > "QOS_USER_INTERACTIVE": { > "sched_policy": "SCHED_NORMAL", > "sched_nice": -4, > "sched_runtime": 8000000, > "sched_util_max": 1024 > }, > "QOS_USER_INITIATED": { > "sched_policy": "SCHED_NORMAL", > "sched_nice": -2, > "sched_runtime": 12000000, > "sched_util_max": 768 > }, > "QOS_UTILITY": { > "sched_policy": "SCHED_BATCH", > "sched_nice": 2, > "sched_runtime": 16000000, > "sched_util_max": 512 > }, > "QOS_BACKGROUND": { > "sched_policy": "SCHED_BATCH", > "sched_nice": 4, > "sched_runtime": 20000000, > "sched_util_max": 256 > }, > "QOS_DEFAULT": { > "sched_policy": "SCHED_BATCH", > "sched_nice": 2, > "sched_runtime": 16000000, > "sched_util_max": 512 > } > } > Is my understand correct that this is device-agnostic? In particular sched_util_max seems very platform-dependent? Also these could very well all land on the same big cluster and be effectively void then. And I don't think I generally buy the argument that uclamp_max is even a good generic way to save power, not with these fixed (and arbitrary) values (e.g. 256 might be just the threshold to allow/require very inefficient OPPs that happen frequently, in particular with the instability of utilization values under sched_util_max / restricted compute capacity).