From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f43.google.com (mail-wm1-f43.google.com [209.85.128.43]) (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 A64C9405C58 for ; Sat, 16 May 2026 03:01:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.43 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778900490; cv=none; b=sGVVQqaJFXtWawUPzSuYVL64QNU29lDq0BTqkNWnLqzYJv+3ECl7sVllp0YOwcJEKOP8TGNluKsWS8myzMvkghU6sjTgjdf+UQkarWJgBbeJkDIpBwX9WWBkY8aLnIfogCfrp510xzajOEsMA0eCMKMkFFWvTz0Xw6PNAtKhtXM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778900490; c=relaxed/simple; bh=CIJTyYfBzEzN5Y/t9Dm5aYJu5Ok3wcY6PbSwtctJ0as=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=K8FYv1EF+gdq041kOD2oTWQ2Rhuno9VFOK4ifC5TVjroX2E7IlkBllLIMrBBSK74z10FlA5bpkOvvZ0AC9aZDm4a8/TsqiqfTOd9YcoieEPXOQKI9GBNCL6SWC7xi5l0q4qSYj6x6+lberRKgUjUoRxR8ZwzsWoqHQpIVG6z9Lg= 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.20251104.gappssmtp.com header.i=@layalina-io.20251104.gappssmtp.com header.b=vb9jytaw; arc=none smtp.client-ip=209.85.128.43 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.20251104.gappssmtp.com header.i=@layalina-io.20251104.gappssmtp.com header.b="vb9jytaw" Received: by mail-wm1-f43.google.com with SMTP id 5b1f17b1804b1-48984d29fe3so4601445e9.0 for ; Fri, 15 May 2026 20:01:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=layalina-io.20251104.gappssmtp.com; s=20251104; t=1778900487; x=1779505287; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=3vfPsUdb8ksnUyHQ0t+pQ0MIZNxt0OfPDtIzW6hB0LM=; b=vb9jytawg1JiXS1NOKEww+aeHX5wUKnq7Zfe28Ws7RCo36ps7pXfi/tXTd8X3QFPff 4eqUySjzipw8o8t5jVAyjvKmiPV10Suxuxy3aToqW42W1nQv3t+fO33SISzhy7tttZdG 7u8B/HGEXNCwZ92ld8QtzrdUwwLY1VcOP7nV596fj5FFmfHum1LDnBJxR7/m0NiDhMWt ES8WZ1qPc/22XLi3WTsDMLECOrU/eM/tQOxy0PzvpAFrbjkgTSPJMQBFCEE+4fR0RTHo IKs874sZZ1mAOV9625KqHwDbJEYMaGNspVXDG8n9G/i45saQ3WOWZ62B7Zzc2hGNuQoZ gl0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778900487; x=1779505287; h=in-reply-to: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=3vfPsUdb8ksnUyHQ0t+pQ0MIZNxt0OfPDtIzW6hB0LM=; b=Wjz17tXzgsLvVIFswJQiwGRPWNNpaQO9py7gJo/JK5lFAiFrBuLqePWczs0yAr2KpH UIc8aOBRR7A4BTl0CiSkX482XDAx2hKFAQuWq7An8eEOtqMQAy2X/1kSNJb+vlZGM8Vs cN4IL0yKNzLUfAz8DNZonAX4tS76oCxef/o0HaoGLq4LBt1yZRHJNvIp0dJ/sU/qvYJ8 EfQGnItujolp1RSYBDNyrZOT1JqaNQFZ5Y/jqGc2hjTnqByAztI24OYFOosc2XApFSSz yOJBV50sJ0yll9LhlD5lTZhgXRmYMyJJ5oh/Ea5n0lhF1NZstP5qX7fDacPEy0LHq+5V OdDA== X-Gm-Message-State: AOJu0YzyinIo1bxVWGcvplCg7EabsWJt7NGoEzCwQ2Y9kfnRJUwJqKDQ WI8L6ZQeOOlZjO2xcqsWScHRj4ByWo0FLd4VJg9O44Py5hPDVhysgb5CXU5snCKm34s= X-Gm-Gg: Acq92OFwS2Lfl3/bRiEAPkpi1srP/u11MxY5j7Oj6G6LNYW0XDf9tS6BwKW4eNLVdXT GlfIMLF7L37BZz4R5UOStMh2LoUwNEZEZd7LGcBAzlKMI78XzlHtvKmgVlsHRzryfx6hF3esVnS dpXkiOMe8eFcCzYyDSJrT5vcz62vq3iviGiH5lJpueL6JTRIgSeOjKYHAVVaPKbj8xHayfaFFlC V10vC6a3qpTwQSiPKSncFvMTYOgvYJESEimt3vKr1PQ4vc0B1lw31PRlX+QfgFPFwj/JmncSILX armIO7ow7ekpDM8hJgjGpqgKGwZyaVp4u/sw4hblSTZAtYbGwfIbw6aJ2svfs+2Gp693nWJiHsh HvdcHTUY94ZQZzHFOGJGKpdXjv/SCEOdnnQBeAVOpcVeV2lJ0dHyAoSQqgXRv0ZmO28g7VFRhdQ LBzWndp9mB/WdVMrTd13BR//vzzA== X-Received: by 2002:a05:600c:6290:b0:48f:f199:7a33 with SMTP id 5b1f17b1804b1-48ff1997b3emr36366535e9.28.1778900486907; Fri, 15 May 2026 20:01:26 -0700 (PDT) Received: from airbuntu ([149.40.48.89]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48fe5694fbfsm172662925e9.6.2026.05.15.20.01.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 15 May 2026 20:01:25 -0700 (PDT) Date: Sat, 16 May 2026 04:01:23 +0100 From: Qais Yousef To: Tom Gebhardt Cc: linux-kernel@vger.kernel.org, Peter Zijlstra , Ingo Molnar , Vincent Guittot Subject: Re: [PATCH v2 00/13] sched/fair/schedutil: Better manage system response time Message-ID: <20260516030123.o26tbwwqeetvo5ix@airbuntu> References: <20260504020003.71306-1-qyousef@layalina.io> <20260515014250.tueinbuk7ldttdop@airbuntu> <32dea9123588227a02971341b22e84d3.tomge68@gmail.com> 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 In-Reply-To: <32dea9123588227a02971341b22e84d3.tomge68@gmail.com> On 05/15/26 10:24, Tom Gebhardt wrote: > Hi Qais, > > Thanks for the follow-up. Here are the patch isolation results and answers to your questions. > > Regarding the governor: > > Yes, I'm running `ondemand`, not `schedutil`. My mistake for not mentioning that upfront - I > assumed the improvement was due to the util_est path being triggered regardless of the governor. > The improvement is clearly measurable even with `ondemand`, which is surprising given that your > patches specifically target `schedutil`. > > Patch isolation -- 12/13 only vs. both: > > I re-ran the benchmarks with patch 13/13 (`sched/pelt: Always allow load updates`) reverted, > keeping only patch 12/13 (`sched/fair: Call update_util_est() after dequeue_entities()`). > > Results using stress-ng 0.15.06 pipe stressor (4 workers, 20s): > > Kernel Clock pipe bogo ops/s delta vs. 6.6 > ----------------------------------- -------- ---------------- ------------- > 6.6.78-v8-16k+ 2400 MHz 2 129 330 +/-0% (ref) > 6.6.78-v8-16k+ 2800 MHz 2 487 746 +/-0% (ref) > 7.0.0-v8-16k+ stock 2400 MHz 1 694 011 -20.5% > 7.0.0-v8-16k+ stock 2800 MHz 1 851 567 -25.6% > 7.0.0 + ttwu only (10 patches) 2400 MHz 1 836 006 -13.8% > 7.0.0 + ttwu only (10 patches) 2800 MHz 1 934 076 -22.3% > 7.0.0 + ttwu + patch 12/13 only 2400 MHz 2 054 879 -3.5% > 7.0.0 + ttwu + patch 12/13 only 2800 MHz 2 415 617 -2.9% > 7.0.0 + ttwu + patches 12+13 2400 MHz 1 996 002 -6.3% > 7.0.0 + ttwu + patches 12+13 2800 MHz 2 342 144 -5.9% > > The key finding: patch 12/13 alone outperforms the combined set on ARM. Adding patch 13/13 > actually hurts performance slightly -- about 3 percentage points -- at both clock speeds. This > suggests that `sched/pelt: Always allow load updates` has a negative interaction on ARM/Cortex-A76, > possibly related to how PELT decay is handled without `schedutil` active, or an ARM-specific > DELAY_DEQUEUE interaction. > > Patch 12/13 alone closes the gap to just -2.9% vs. 6.6 at 2800 MHz (OC), and -3.5% at nominal > 2400 MHz. That is a remarkable recovery from the -31.9% regression in 7.0 stock. > > Regarding Perfetto traces: > > Unfortunately I cannot provide sched-analyzer traces at this time -- the kernel is not compiled > with CONFIG_DEBUG_INFO_BTF=y (pahole/dwarves not available in this build environment), which > is required for BPF CO-RE. I can try to arrange that for a future run if it would still be useful. You don't need to have it enabled in the kernel. I don't need util info, by default if you don't pass any arg it should not cause BPF to be loaded. Note there are binaries in the release page on github, so you don't have to compile it. You can also use regular perfetto command to record a trace and visualize it and the sched-analyzer-pp would be able to analayze it. I am looking to see if the task placement and running/runnable time pattern has changed significantly to cause the big difference. It'd be good to perf it too. You might be hitting weird contention that the patch just happens to accidentally hide. > > Device: Raspberry Pi 5 (8 GB, C1-stepping), Bookworm arm64, kernel rpi-7.0.y. > Background: https://github.com/raspberrypi/linux/issues/7308 > > Tom