From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BACD423D281 for ; Mon, 12 Jan 2026 09:57:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.50.34 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768211864; cv=none; b=SWXnUtDZSbo+VWuNOGe1c9Cb5v3bS7UjhR8OVfTP5BYQ9LT3UL530xIw7wMmYNvXBjgJca/ghns2HBAKqko20oyRY6gbNdJB/+CFpQ3oe+EQjRhiCRqnRWMMugbcn6kCLssenQmf2oOi7se2K+0UpBiaine/DsF/vzls5F3920E= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768211864; c=relaxed/simple; bh=DD63a30N4ItTnwO/o7EAo2rv+hya5gM3Fq2+dO1qsjk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=j+bsg7m+jFBdVT9j2ZFnMLLmFHGhM7OyDV6KPYU9kl191ieL80JPqXrm5PAfVwjylC6ahWNtfs34dbrANTsCoNo9p943rVNHuX65F28iyMWdHWWvbMu/D3FcdppX9v2TQPQFzBuPXBo6C7H++U5K3q8Lp/S/5yi1YetZkGZGF9g= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org; spf=none smtp.mailfrom=infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=gZrSKzDB; arc=none smtp.client-ip=90.155.50.34 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="gZrSKzDB" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=n4kD+FKVIqkgEt9OifrxCtzTL3f4Nw3n3fPE4wKDmtk=; b=gZrSKzDBEDq1H9USSYj+25nTZE x00lap22uEsBMG+LTDkvZ0oo92EpQb0oxDYCa+03aANeaC4BUl1BtYUZHmoT/JQhHEi6dBciUlkeL P82of21Ufp7+xTkxt4gK/+Rpmho6wBQxhsCzTG7RfgrZs1zTkEbhu/yfvBM2rpHfCFtUXY/Oo5LKN Nzl7spCdwfL8uwr5QT5hhxx7Bz48/gfRN2sqJEqQTcb9/G7kYhQ2HMwjqRoJ14REBL8rc2S7+OW43 jW1VEFrC14Jbmr2XOnjY/RfUMo2CQEUsOM47Y7ii7lXXtGp4+OJ14XTbKeKbd67RQTsiIRNZjACrh E9J9NhhQ==; Received: from 77-249-17-252.cable.dynamic.v4.ziggo.nl ([77.249.17.252] helo=noisy.programming.kicks-ass.net) by casper.infradead.org with esmtpsa (Exim 4.98.2 #2 (Red Hat Linux)) id 1vfEfz-000000033fr-2N2D; Mon, 12 Jan 2026 09:57:31 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id 7565330057E; Mon, 12 Jan 2026 10:57:30 +0100 (CET) Date: Mon, 12 Jan 2026 10:57:30 +0100 From: Peter Zijlstra To: Ryan Roberts Cc: Mel Gorman , Dietmar Eggemann , x86@kernel.org, linux-kernel@vger.kernel.org, Aishwarya TCV Subject: Re: [REGRESSION] sched/fair: Reimplement NEXT_BUDDY to align with EEVDF goals Message-ID: <20260112095730.GD830755@noisy.programming.kicks-ass.net> 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> 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=us-ascii Content-Disposition: inline In-Reply-To: <5265d323-d627-45b1-8e3c-4456df680807@arm.com> 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.