From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f52.google.com (mail-wm1-f52.google.com [209.85.128.52]) (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 5C40A337BB0 for ; Fri, 15 May 2026 01:42:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.52 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778809377; cv=none; b=XdlNb32usOeBLJVoVWBHFNEfZR1VrS1xTz4OooSfqMZlUN44CI3w0qBcgDrnqK/cJAYi7Ef/Y458Jv6Qu/Zg1lke7ns25ukJ8YkKm0kgDsNdV+wQVUfuDpJhCjOcrGVslIyJcWNDaJRGBLGtHXc/uuNRy8dGimjIR14xXZuloS4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778809377; c=relaxed/simple; bh=4LdD3Pq2G+1Xp6F6lUzSD8XUqAdYjZfgbltyq0nY5oc=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=fRdkFCWhkatF+ACfDp5x/3QgIiTk+FFKKgB+EnlXBzjpbthhw+oi8sUL/JpZ0Omvf765qRTxnqd5Kyx3Xhf6fJINTx19PiI5Tl7u9a94u3qGuh64D0+WSSe5g6qlFUaRaIWEsvYGvMobbk+lwXXjzl1lzpNJmmnUIrugSazyVic= 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=g3Rt9p2+; arc=none smtp.client-ip=209.85.128.52 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="g3Rt9p2+" Received: by mail-wm1-f52.google.com with SMTP id 5b1f17b1804b1-48896199cbaso74477105e9.1 for ; Thu, 14 May 2026 18:42:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=layalina-io.20251104.gappssmtp.com; s=20251104; t=1778809374; x=1779414174; 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=sI/tPjg87Z1Ebe8hIgLFzeugyNfC4alXEN3b8iIih+c=; b=g3Rt9p2+T6imwwLz32nEa45O7kXhOb2u9WR37yuMFwqIfjAWUPu/lXzgkybSI9Xiru iAvAQYALkW/v70Hz0hXMgBXsq9SZ5tPe9v+yUs6F6JVl2nv+p3tSokRH36qndLDCNXwx uSW9lRHH06EG/XbphNZdKHNI4e1Wx0pGjdYvKBX3LKk2iMmRgDxhIMd+y0v5xdG142TU +i0p3fWNbnYcOtR4hd9SpRkdcwyOGKEHe9F6bhTBl/kBF6whzWhMj7zczmhUKtEoyBF+ 7vG6Kwl4lZ4KkgANt+6nEcFkiwMsfivi2wjuaejJUqf6Lz78nf6ncpwh3ylKahy8+v+S TWGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778809374; x=1779414174; 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=sI/tPjg87Z1Ebe8hIgLFzeugyNfC4alXEN3b8iIih+c=; b=NPlS2xBPfSWdd+W3b/ooU3NkAi1EwUtLAVvTgivG1KJskz3jNRW5uP81NlPjNVFeom xHfLYpg6qd6DkedxmfxgoibkTxIEtehn6pyiOZGgNSWd2sgEu3DxHw8c3V6iSpm3/ai7 J9u+dps+a8OYAZNHm9gn4q2m9XRc43rdwDuBBZntP/gSsKfgdyNjLjZhqDMpxU/OrFk6 +f6HmB3MWbRD0uwggPZZuOmLtP29mNekaMEih+bRNOqxf0teg2yJjQ9MeptIqeZBEFZV WY7ifiLSJE0fNJsiKowVJDmLZ9QRzcfexErzbu/QcNvazLVQ0x3teXtmqYdBPJr5ppjE opjw== X-Gm-Message-State: AOJu0Yyl8iGw8KOoxgfT6hkIfjaF7ltIO6mUjr3d6I2tbatK6sPnfJVU CzKCFfnNImL1vGlL87FuogqXixcTuPy7YesnEwzIoq5mTKV01cwLBGX2m+4ve/V/zZs= X-Gm-Gg: Acq92OF0eUTtLo9rNlFGiVGi9c7Zy9vTnAS8sD3GLrKRPgg0gLh7MRs87YNqzrEPFWa z84sVeNbrSmWV6PPVG0JFAkayfvnWPfZ7VFk+21T+nPYE+2/XHOaDHEBaJYR8t7uNA2JdnS+WUI g2IhTRGxRHNVAywzbuNM+LwElN22UFzxcGdJeqMDl9FpyZMcUyhGpbLdNtjCuY9haY+6xiLk6Be HmoAJch/vbx9Z9jlHcmCwxBvWSrCWyW8h5yDFCQNmi0dSFagNjBSdqpecZDAh8Sngml+Lj3Hp4B C2y0EWkJdbilp6xsZdSERRHGBUsyZ+SOkIAFsX7LluMY68f63krHEIz57nshAey+w7LAEVspgN4 bIdzHNJ3maMQb3ktnHIXK1K4b16fAgbqbj+pYllIFfsE0ZCFk5PWFk5PofF+6kvK08n12hfFhu2 IS8gCXTSdBy2OfRJrI X-Received: by 2002:a05:600c:4f13:b0:485:30d4:6b9e with SMTP id 5b1f17b1804b1-48fe6328bb7mr24011305e9.21.1778809373538; Thu, 14 May 2026 18:42:53 -0700 (PDT) Received: from airbuntu ([185.253.98.51]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48fea52acb6sm4097865e9.0.2026.05.14.18.42.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 14 May 2026 18:42:52 -0700 (PDT) Date: Fri, 15 May 2026 02:42:50 +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: <20260515014250.tueinbuk7ldttdop@airbuntu> References: <20260504020003.71306-1-qyousef@layalina.io> <7a4f4e3f4caea5cac2a2b7b5994a97ee.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: <7a4f4e3f4caea5cac2a2b7b5994a97ee.tomge68@gmail.com> Hi Tom On 05/13/26 17:09, Tom Gebhardt wrote: > Hi Qais, > > I tested your v2 12/13 (sched/fair: Call update_util_est() after > dequeue_entities()) and RFC 13/13 (sched/pelt: Always allow load updates) > on ARM (Raspberry Pi 5, Cortex-A76, 4-core), combined with Peter > Zijlstra's ttwu series (rebased to 7.0.y by marioroy). > > Both patches applied cleanly on top of rpi-7.0.y + 10 ttwu patches > without conflicts. > > Results using stress-ng 0.15.06 pipe stressor (4 workers, 20s): > > Kernel Clock pipe bogo ops/s D vs. 6.6 > ---------------------------------- --------- ---------------- ---------- > 6.6.78-v8-16k+ 2800 MHz 2 487 746 +/-0% (ref) > 7.0.0-v8-16k+ stock 2400 MHz 1 694 011 -31.9% > 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 -26.2% > 7.0.0 + ttwu only (10 patches) 2800 MHz 1 934 076 -22.3% > 7.0.0 + ttwu + your 2 Qais patches 2400 MHz 1 996 002 -19.8% > 7.0.0 + ttwu + your 2 Qais patches 2800 MHz 2 342 144 -5.9% > > The ttwu-only set recovers ~3-4% of the regression on ARM. Adding your > two patches brings a much larger improvement -- especially under > overclocking, where the combined set recovers roughly 94% of the 6.6 > baseline. The remaining ~6% gap may be related to ARM-specific > DELAY_DEQUEUE interactions. Hmm this is an interesting impact. Did you get a chance to verify if you need the 2 patches or only one of them is enough? Only 12/13 is actually a fix for a change in behavior from 6.6. The last patch is a new addition for a behavior that has always been there. You have SMP system, so utilization can't be impacting your task placement to potentially being stuck on a little core. And looking at raspberry pi code, it seems they ship with ondemand governor as the default cpufreq governor. Are you using the default one? Assuming yes and you're not using schedutil, then these patches making things better is not expected. Are you familiar with perfetto? Can you use sched-analyzer [1] to capture a trace and inspect how the pattern changes when things are good and bad? Output of sched-analyzer-pp --sched-states $TASK_NAME --freq-residency-task $TASK_NAME \ sched-analyzer.perfetto-trace would be useful to share. I suspect you have a subtle change of sched pattern that I hope you might be able to visualize directly in ui.perfetto.dev, but the above stats might be a good way to see potential difference between good and bad runs. Thanks! [1] https://github.com/qais-yousef/sched-analyzer > > Device: Raspberry Pi 5 (8 GB, C1-stepping), Bookworm arm64, rpi-7.0.y. > Background: https://github.com/raspberrypi/linux/issues/7308 > > Thanks for the series -- the ARM results look very promising. > > Tom