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 529BF39DBC0 for ; Sat, 16 May 2026 13:43:17 +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=1778938999; cv=none; b=MdyLo3HHhmvKOCI0v+LEfEeUqCvTaOylItvBG8Idrm+B4cBW4GA6gQoTvqtO2FgjquMy5UySRbcjd3FVcw72e042zcn+00VcCzgIRAE+cRJqm40fevlmqA6V3xPNoP8rt4MoFmWwB+hifZiNt2P20oZYQNogKxBk6AYCqghli7I= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778938999; c=relaxed/simple; bh=vNXa+pxQLcP53BnOaNbrHrAr9+Fu0qEeXgGgvekR7Js=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=loc8fdl7c+Xmo8zILgu+wkDIfclgQZgS7oWNecnz2r/hcLszS71RyMy9a0vmUAZUCLfOnRwY0vksXnWWpXS5c2KLc9W01V7X5kA2ZaNI0nHAmmb6UsMb+GLeVeid5vto8c2Ik1KCrzKRt3yH0Eh4F9EDHjucicAGhczq0MJqWqE= 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=VXCxVfzu; 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="VXCxVfzu" 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 392731713; Sat, 16 May 2026 06:43:11 -0700 (PDT) Received: from [10.57.27.10] (unknown [10.57.27.10]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 2895E3F85F; Sat, 16 May 2026 06:43:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1778938996; bh=vNXa+pxQLcP53BnOaNbrHrAr9+Fu0qEeXgGgvekR7Js=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=VXCxVfzu/zcXAqw3phf++pE5PAA1PAPFw17WsRL50KXM+F2XzawA1txQIUwCvpyMa 4LP9Gh9NsW0hktTrzp4tKckA3qNGpgeP4ZRGxipOGXS0KrF6+TGfmw6J7CpL0bxmuP 7grR0bGGPblYJL/CgR274Ki9kUJL0SbTLVC8YZug= Message-ID: Date: Sat, 16 May 2026 14:43:12 +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: [PATCH v2 00/13] sched/fair/schedutil: Better manage system response time To: Tom Gebhardt Cc: Qais Yousef , linux-kernel@vger.kernel.org, Peter Zijlstra , Ingo Molnar , Vincent Guittot References: <20260504020003.71306-1-qyousef@layalina.io> <20260515014250.tueinbuk7ldttdop@airbuntu> <32dea9123588227a02971341b22e84d3.tomge68@gmail.com> <28c59186-4ba0-44f4-b5b8-42f6f73cd3e6@arm.com> <318a4aaf404b66f7a04ed4d4a18d228a.tomge68@gmail.com> Content-Language: en-US From: Christian Loehle In-Reply-To: <318a4aaf404b66f7a04ed4d4a18d228a.tomge68@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 5/15/26 14:57, Tom Gebhardt wrote: > Hi Christian, > > Good point -- I ran additional tests with `performance` and `ondemand` governors > side by side on the same kernel (7.0.0 + ttwu + patch 12 only): > > Clock Governor pipe bogo ops/s > -------- ------------ ---------------- > 2400 MHz performance 2 095 187 > 2400 MHz ondemand 2 093 221 > 2800 MHz performance 2 415 817 > 2800 MHz ondemand 2 415 617 > > The difference between governors is <0.1% -- well within noise. So you are > right: the effect is not cpufreq-related. Whatever patch 12 changes, it > affects the scheduler path directly, not through frequency selection. > > I also applied Vincent's fix [1] and benchmarked it: > > Kernel Clock pipe bogo ops/s Δ vs. 6.6.78 > ---------------------- -------- ---------------- ------------ > 6.6.78 2400 MHz 2 129 330 ±0% > 6.6.78 2800 MHz 2 487 746 ±0% > 7.0 + ttwu + patch 12 2400 MHz 2 093 221 −1.7% > 7.0 + ttwu + patch 12 2800 MHz 2 415 617 −2.9% > 7.0 + ttwu + Vincent 2400 MHz 2 077 526 −2.4% > 7.0 + ttwu + Vincent 2800 MHz 2 458 151 −1.2% > > Vincent's fix gets very close to 6.6 at 2800 MHz (−1.2%) and is similar to > patch 12 at 2400 MHz. Both are a large improvement over vanilla 7.0+ttwu > (−22% at 2800 MHz) and plain 7.0 stock (−26% at 2800 MHz). I tried to replicate using orion o6 and offlining all big CPUs leaving 4 little CPUs and an SMP system. Workload: for i in $(seq 0 19); do stress-ng --pipe 4 --pipe-ops 5000000 --metrics-brief --timeout 60 ; sleep 60 ; done Results: (bogo ops/s real time) 7.1-rc3 powersave: 27186.17 ± 813.42 7.1-rc3vingu powersave: 26866.67 ± 899.51 7.1-rc3 performance: 78223.83 ± 4344.88 7.1-rc3vingu performance: 77289.57 ± 3321.10 As expected there's no significant change with Vincent's patch. I didn't notice anything suspicious in the patch either, looks fine to me. Next suspect is of course some interaction with Peter's ttwu series you've applied. Alternatively you could also push your exact tree somewhere and I'll go and use that myself. > > Note: [1] applied with a manual context fixup for the DELAY_DEQUEUE hunk -- > the rpi-7.0.y tree's dequeue_entity() differs slightly from mainline in that > block (no update_entity_lag() call inside the DELAY_DEQUEUE early-return). > The semantic intent of the hunk was preserved. > > [1] https://lore.kernel.org/lkml/agRyoe1wHyZ-vMk9@vingu-cube/ > > Thanks for catching that and for offering to reproduce it. > > Tom