From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f50.google.com (mail-wm1-f50.google.com [209.85.128.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 19F812D6E66 for ; Tue, 24 Mar 2026 01:33:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.50 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774315984; cv=none; b=nBuUbrweffpPvvWy4cFqiDu53uwrfLouuPImgRJVLz3XHimWVXhuSgubeQFkA8MTavoXTAIlgOQlCaUWCiahWC0nlv9Ai0vnsQFiZrLeX5v4ewp660t023X3q+CMN6nSBhO+I9r2cMZtyHqI4tLXxZZhTh+q+He9itTXiA8EDLM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774315984; c=relaxed/simple; bh=gopK/ieGSHALjvr9fey8jOM4v+B5x6tiKxUd2ygUb/U=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=JtJJ/YRD0pxX5oM6gK51g1yUgT515DTsr4PtTONakRtFb0a/buLU0MItDvvvFadGrXy7zTK1ScrHQ7IswWXzyqLgqhR+gmq3WCv9LSvozzmEwW+xba/V548AUHTKDyYHgIh5qhITP255iyFgmGQzR3r7E73Fs3lSvEllfK3LXkQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=layalina.io; spf=pass smtp.mailfrom=layalina.io; dkim=pass (2048-bit key) header.d=layalina-io.20230601.gappssmtp.com header.i=@layalina-io.20230601.gappssmtp.com header.b=pPta4ere; arc=none smtp.client-ip=209.85.128.50 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=layalina.io Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=layalina.io Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=layalina-io.20230601.gappssmtp.com header.i=@layalina-io.20230601.gappssmtp.com header.b="pPta4ere" Received: by mail-wm1-f50.google.com with SMTP id 5b1f17b1804b1-483487335c2so37328125e9.2 for ; Mon, 23 Mar 2026 18:33:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=layalina-io.20230601.gappssmtp.com; s=20230601; t=1774315981; x=1774920781; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=4610CcFXIVyfslSwm2hxF52RGa3oKGC1LC18WqcenIw=; b=pPta4ereuSEnFQZGlG5GFnOuo6EdZpxcAuck/I/tHjzSwo2946wItf1isEQw6cirIE FBqVu3FJaH/duYIH26Y1dCGeOtQmHp7UcpM29zKI6RWMc43Y1OQa03KJsq30aeSq/W+S YnMHHq1MbJwpeq8sMedFPJdzWp562qdsrhj2cZSGVj1rGnIcM7XlFF+CjdUYaABe24Ly EVa/r7avmnozkn/BRIA/wCz2vEngwiMUnT1i+IR/fVV5WWZ6zQG1Q7nyl+dqDSUY9B8f aTElxmVrgGT601uiVTXi6P0bbWYJWA2vf8xoguOr6KoIPnnVBZCT9uG0smN9nN3McVgy 2YvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774315981; x=1774920781; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=4610CcFXIVyfslSwm2hxF52RGa3oKGC1LC18WqcenIw=; b=YRCElFRZPXKRmzVxGFUkTvrbx4/rDEwFsydvSTrCEZXFT13qAc8f3OTuF2BBLkx9J3 5AgrYA88IAHx/lCHmB7rtZ/wKJcGJVQSbdYj9fsKLx9CHLlJKNaWTI43hJzjTlsSJPA5 MEfuiZ3sYhF1wLV4fgy9kOELL/RL0MY4bBwFueE4tY9CDsQ3NMYU53oNscuVmLd5vxvb 0iXOrFZpAGmjna0kjX3ZYUE22K75GiumppuYsQhg3DfqwtY0gdH5IJ5xJPnZLBeXHcBp +pu6FCe5uTTE8AfNouNUsj/iNi10U4+EmyD3+AwfLLx8PUMxfPbjozGWzT3hhvDmCklg 7C0w== X-Forwarded-Encrypted: i=1; AJvYcCUB81S+89hzWXimNh6Ht0L+aZ0k5/nxhV3tDeF2f3EDEy5ApqT8x6IIePAiPW4+stE9fu+VS3/OR0chAb0=@vger.kernel.org X-Gm-Message-State: AOJu0YwXDERHfhM9wFVsrzdhCvmGVbyc9EjYY7YukDYyI91rUfVFArdJ eacvUK9ypqaKZ9o671rvOPdfHmccKzJCkq1xUSXTLnPJkwErxYKrj84kpN/SNO6AijY= X-Gm-Gg: ATEYQzwZESYmTMDiPS99Nt3ZZr21gHF+sOE0bdeKqIhqvVGxU7BgM3DcMVv5VouhQRB L5TVXHD6Amr3vFUvVdca+W1vvERQaf9/EKzTWmB036NEHLxQ6mDSk7ZRycQ6Ov+h6tNygOpURuS l3nF/KC9rxbndhn/SwOG1V+iph2zkEoe+pmQDFOPV93+h4m963PEmjoWwmvbq/IJqmv+8gRur5i 1HmfBO3QzCiOeW7QkhJUixSpVpqN36a37LJeEAZOGTRPGWHTg8RF0ZrP8drrbSQUS+RWGE0PMxq hj7qo18YPQf0lAVGs1K0DxgPMlIxA/SgGyjzmOf8LtMOb0RACz8TU0nQ4l+NsVUdeHqIOrAVGHa vekiPV2Y9dcZbm8DUaGKdaUgRuEvzo/z9HWdyRzhsz6Uet0xJFObXb5WQoy6Fnzkt19mUoZ4clp dwtZqORskQpQ+y8ZtYrSz8FOJtueQ= X-Received: by 2002:a05:600c:3d87:b0:480:1e40:3d2 with SMTP id 5b1f17b1804b1-486fee2cfa5mr166560685e9.29.1774315981313; Mon, 23 Mar 2026 18:33:01 -0700 (PDT) Received: from airbuntu ([146.70.179.29]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48711117377sm5681625e9.36.2026.03.23.18.32.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 23 Mar 2026 18:33:00 -0700 (PDT) Date: Tue, 24 Mar 2026 01:32:57 +0000 From: Qais Yousef To: Xuewen Yan Cc: Vincent Guittot , Peter Zijlstra , Xuewen Yan , mingo@redhat.com, juri.lelli@redhat.com, tj@kernel.org, dietmar.eggemann@arm.com, rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de, vschneid@redhat.com, lukasz.luba@arm.com, linux-kernel@vger.kernel.org, rui.zhang@intel.com, di.shen@unisoc.com, ke.wang@unisoc.com, Christian Loehle Subject: Re: [RFC PATCH] sched: Add scx_cpuperf_target in sched_cpu_util() Message-ID: <20260324013257.uhoto5v4cfhfqrtc@airbuntu> References: <20260318121755.16354-1-xuewen.yan@unisoc.com> <20260318124718.GC3738786@noisy.programming.kicks-ass.net> <20260318134406.6k23fct6dvpsqagm@airbuntu> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On 03/19/26 10:13, Xuewen Yan wrote: > > Beside that, this sort of plug-and-play is a big concern. You picked up sched > > ext and changed the behavior, then you'd need to get your thermal management to > > work with that. Not retrospectively sprinkle these hacks around to force things > > to work again. > > In fact, I had considered this issue even before sending this patch. > Our initial fix was to modify the thermal subsystem specifically, > in cpufreq_cooling.c, when SCX is enabled, we stopped calling > sched_cpu_util() and instead used idle-time-based calculation to > obtain CPU util. > > However, we later realized that sched_cpu_util() is used not only in > cpufreq_cooling.c but also in dtpm_cpu.c. > Since I’m not familiar with dtpm_cpu.c, I was hesitant to modify it. > This led us to propose the current patch. > Although scx_cpuperf_target may not accurately reflect the true CPU > utilization, as Christian pointed out, it’s still better than having > nothing at all. > > That’s exactly why I marked this patch as RFC, I wasn’t sure whether > the proper fix should be in cpufreq_cooling.c or in sched_cpu_util(). > It now seems clear that modifying only sched_cpu_util() is > insufficient. Ideally, we should also update cpufreq_cooling.c, since > we cannot guarantee that all SCX BPF programs will provide an accurate > cpuperf_target. > I’ll submit a follow-up patch to modify cpufreq_cooling.c shortly. The bigger picture problem is that sched_ext is not trustable. For something that is critical as thermal management you'd have to bake it with your out of tree sched_ext changes. The current system was designed to work together with some assumptions, and by opting to sched_ext you're opting out of these in-tree assumptions. User space scheduler can be used with a user space cpufreq governor and a userspace thermal solutions; I don't think there are restrictions to creating out of tree governors. If you have a problem that needs to be fixed in the scheduler, perhaps we can help with that ;-) If you just want to go and do your own thing, perhaps you can go all the way then and redo it all.