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 5C467345740
	for <linux-kernel@vger.kernel.org>; Mon, 12 Jan 2026 08:52:27 +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=1768207950; cv=none; b=rwIcFCsAiwfJjR7uTwlEI72elL1nZatCfkfnTrvW7GcmUNKXQjXqZwodzBC3djs445vCfX/XpGFvdrjhqTJOnakOUZ5gInqiVZLSBsCcMSRL9oENOq5XyfSSY2f5pz5f0X8gkg98A3UG/xaoNz1i7qJPcwzyeg7+PsXh+TkdVsA=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1768207950; c=relaxed/simple;
	bh=916i4s/Y9QfXbbWgqv3P11Y9RYAxXnois0FxW9X76nI=;
	h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:
	 In-Reply-To:Content-Type; b=BCwWBWgw5eUCL7OGJ5H4AByDQJ21NXFtQClFfFPUfHmStV61lVXtCW+lMb45tgGtv7kSS4BNuXZ1nD2E7Hpk/VsqrJmn43OXzMGK5dbd2AcPrLwNO6gROEV4yzL8OAST0XUvr0iCwaZgxe/OzEAbU3brfruSloriJVndMeu8Qik=
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; 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
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 A8DB9339;
	Mon, 12 Jan 2026 00:52:13 -0800 (PST)
Received: from [10.57.95.123] (unknown [10.57.95.123])
	by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 6EB0B3F694;
	Mon, 12 Jan 2026 00:52:19 -0800 (PST)
Message-ID: <5265d323-d627-45b1-8e3c-4456df680807@arm.com>
Date: Mon, 12 Jan 2026 08:52:17 +0000
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [REGRESSION] sched/fair: Reimplement NEXT_BUDDY to align with
 EEVDF goals
Content-Language: en-GB
To: Peter Zijlstra <peterz@infradead.org>
Cc: Mel Gorman <mgorman@techsingularity.net>,
 Dietmar Eggemann <dietmar.eggemann@arm.com>, x86@kernel.org,
 linux-kernel@vger.kernel.org, Aishwarya TCV <Aishwarya.TCV@arm.com>
References: <20251112122521.1331238-3-mgorman@techsingularity.net>
 <176339661525.498.7070393041762616565.tip-bot2@tip-bot2>
 <4b96909a-f1ac-49eb-b814-97b8adda6229@arm.com>
 <a33dc104-cfd3-4c29-976b-ea370f45e24d@arm.com>
 <756efd17-682f-4ffc-b8d9-dbb2517bc152@arm.com>
 <c111cc52-4133-4f57-b753-139a5ff2b395@arm.com>
 <051285c7-56c0-455d-ab3e-9959edb5d13f@arm.com>
 <kne2v4fhsql5fltb6q5wbsohh224fzs6mov4l324q4wppzpayk@4ayzckp6bs2p>
 <6c137b30-d5f7-4dd9-9699-d7e22c174285@arm.com>
 <63d22eb9-b309-4d11-aa56-3f1e7e12edb1@arm.com>
 <20260112074703.GB830755@noisy.programming.kicks-ass.net>
From: Ryan Roberts <ryan.roberts@arm.com>
In-Reply-To: <20260112074703.GB830755@noisy.programming.kicks-ass.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 12/01/2026 07:47, Peter Zijlstra wrote:
> On Fri, Jan 09, 2026 at 10:15:46AM +0000, Ryan Roberts wrote:
> 
>> Here are the updated results, now including column for "revert #1 & #2".
>>
>> 6-18-0 (base)		(baseline)
>> 6-19-0-rc1		(New NEXT_BUDDY implementation enabled)
>> revert #1 & #2		(NEXT_BUDDY disabled)
>> revert #2		(Old NEXT_BUDDY implementation enabled)
>>
>>
>> The regressions that are fixed by "revert #2" (as originally reported) are still 
>> fixed in "revert #1 & #2". Interestingly, performance actually improves further 
>> for the latter in the multi-node mysql benchmark (which is our VIP workload). 
>> There are a couple of hackbench cases (sockets with high thread counts) that 
>> showed an improvement with "revert #2" but which is gone with "revert #1 & #2".
>>
>> Let me know if I can usefully do anything else.
> 
> If its not too much bother, could you run 6.19-rc with SCHED_BATCH ? The
> defining characteristic of BATCH is that it fully ignores wakeup
> preemption.

Is there a way I can force all future tasks to use SCHED_BATCH at the system
level? (a Kconfig, cmdline arg or sysfs toggle?) If so that would be simple for
me to do. But if I need to invoke the top level command with chrt -b and hope
that nothing in the workload explicitly changes the scheduling policy that would
be both trickier for me to do and (I guess) higher risk that it ends up not
doing what I expected. Happy to give whatever you recommend a try...