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 508512773D3 for ; Mon, 12 Jan 2026 10:27:11 +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=1768213632; cv=none; b=mIZmbG0rWW/nZ28+xguXDvbru5Akmi53Ci88l9zYzj03oiuejFmrLpNonkzCmX/dEQhr8kQ1YpQ6vWri7H9FfVmhwfT/bk9ZYnbmwJlKQuluIj/bn6gdmLt5oKnHRHXO2MDRafVkmesm9ag459maPI9xQJLTF6AWOj2W2SHVFsM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768213632; c=relaxed/simple; bh=iplH3DYQO6pPOxw/OqY6Jslm6o6oQvj1KJSK3Hp5EdQ=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=fwHCvm7hJwn073uJktWw6NR1KBCBvqDYOH5POZPJwE3kqGvgrrXM9ujMbpm5SgE4xDLXUJGZM1xdEjfQGFYd6DNyHgD399qIfRawsvKARju3oT5Q4n7HnhPQ0n7raFrRcQKCrL3wr7pP6Uzqw81S+UcD5cVsyq2tqtw4TdDG24g= 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 042BC497; Mon, 12 Jan 2026 02:27:04 -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 BD4363F59E; Mon, 12 Jan 2026 02:27:09 -0800 (PST) Message-ID: <716d34c0-209b-42e3-a321-c2f78ba9c4b9@arm.com> Date: Mon, 12 Jan 2026 10:27:08 +0000 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: [REGRESSION] sched/fair: Reimplement NEXT_BUDDY to align with EEVDF goals Content-Language: en-GB To: Peter Zijlstra Cc: Mel Gorman , Dietmar Eggemann , x86@kernel.org, linux-kernel@vger.kernel.org, Aishwarya TCV References: <4b96909a-f1ac-49eb-b814-97b8adda6229@arm.com> <756efd17-682f-4ffc-b8d9-dbb2517bc152@arm.com> <051285c7-56c0-455d-ab3e-9959edb5d13f@arm.com> <6c137b30-d5f7-4dd9-9699-d7e22c174285@arm.com> <63d22eb9-b309-4d11-aa56-3f1e7e12edb1@arm.com> <20260112074703.GB830755@noisy.programming.kicks-ass.net> <5265d323-d627-45b1-8e3c-4456df680807@arm.com> <20260112095730.GD830755@noisy.programming.kicks-ass.net> From: Ryan Roberts In-Reply-To: <20260112095730.GD830755@noisy.programming.kicks-ass.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 12/01/2026 09:57, Peter Zijlstra wrote: > On Mon, Jan 12, 2026 at 08:52:17AM +0000, Ryan Roberts wrote: >> 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... > > No fancy things here, chrt/schedtool are it. OK I'll figure out how to butcher this into my workflow and get back to you with results. It probably won't be until Wednesday though. Thanks, Ryan