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 79D8E2D7DE9 for ; Fri, 20 Mar 2026 10:00:00 +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=1774000802; cv=none; b=VnIJ9bxZFpZM6jwMKk5WNRCYBubUMi76cxIWV4zHCMFey8tqHvMmWn6jCuEkhM6kwAppj8MgrYYZCRAtIIYdiXutfIXGgUn57AMT3mB2/8upBMSm2BZyidWiJ2lLuYaesCnh5MEEwOFBq6UHsvrcilW65ijDhR1ySZYXmUuuBaQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774000802; c=relaxed/simple; bh=E8yPB7rRN1QAwtOJQ/LGKDU3I8byBcEcrSDWcGBs3QQ=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=oL9bDKuUOCLMTlGM0RJleRsVA+yeqWKtDg5qaCPMKpwfJ2mu/gJMuQJVitpeWoiwEw4BFPxcO8o5f6FdhCUpDIFWQByoaMzoA/P2MeVkjJgzMyH8epsNbQLOWPitcBqPsW5/seSQ8hM5k8WgFrMU8jHFcL5HEM/l94Ixtqb5Tog= 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=TxCF9lEO; 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="TxCF9lEO" 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=JxSJOfMUXSfAxpZ2xY/1N6d4lWuLRMS4vVESD7j0lSQ=; b=TxCF9lEOByHSyCnkzttZUG9M/j XRViken6n2JGfg9Ib9L87p+kir54IxNFLTK7ToI4cn/+d3bIlGL5wUbejLVNi/EX63q28SR/gQQPb ruZOjc5Lhtg/+YUqWZmNCeaovY3EJkac9b8w71s1kJFpWJ2TdLcf5TGZbvkQTVB3I1cq+TIuVUPwM VSq5Hg1YQdu7b/GbMsKmFE0bWTI0lxF7MLbxCaRFHBIsnmwlBnnmIyJXeWDzwe2RDLmP//rx84kzh Yl4HOg5bDdawRQa8JHOCV7455ivBAb93B+gl0hQW95Smy6DazMmfZcaVRIiziDelsZYklBCWAn4Cv +0UYCeIw==; 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 1w3We5-00000007aD9-0IgZ; Fri, 20 Mar 2026 09:59:57 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id A7F12301150; Fri, 20 Mar 2026 10:59:55 +0100 (CET) Date: Fri, 20 Mar 2026 10:59:55 +0100 From: Peter Zijlstra To: Pan Deng Cc: mingo@kernel.org, linux-kernel@vger.kernel.org, tianyou.li@intel.com, tim.c.chen@linux.intel.com, yu.c.chen@intel.com Subject: Re: [PATCH v2 0/4] sched/rt: mitigate root_domain cache line contention Message-ID: <20260320095955.GQ3738786@noisy.programming.kicks-ass.net> References: 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: On Mon, Jul 21, 2025 at 02:10:22PM +0800, Pan Deng wrote: > When running multi-instance FFmpeg workload in cloud environment, > cache line contention is severe during the access to root_domain data > structures, which significantly degrades performance. > > The SUT is a 2-socket machine with 240 physical cores and 480 logical What's a SUT? > CPUs. 60 FFmpeg instances are launched, each pinned to 4 physical cores > (8 logical CPUs) for transcoding tasks. Sub-threads use RT priority 99 > with FIFO scheduling. FPS(frame per second) is used as score. So I think we can do some of this, but that workload is hilariously poorly configured. You're pinning things but not partitioning, why? If you would have created 60 partitions, one for each FFmpeg thingy, then you wouldn't have needed any of this. You're running at FIFO99 (IOW prio-0) and then claiming prio-0 is used more heavily than others... will d0h. What priority assignment scheme led to this? Is there a sensible reason these must be 99?