From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1849EC02193 for ; Tue, 4 Feb 2025 15:31:10 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8D69B280002; Tue, 4 Feb 2025 10:31:10 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 886CD6B0088; Tue, 4 Feb 2025 10:31:10 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 74EF1280002; Tue, 4 Feb 2025 10:31:10 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 252826B0083 for ; Tue, 4 Feb 2025 10:31:10 -0500 (EST) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 968714A090 for ; Tue, 4 Feb 2025 15:31:09 +0000 (UTC) X-FDA: 83082650658.17.613DEAE Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) by imf28.hostedemail.com (Postfix) with ESMTP id 140F5C0005 for ; Tue, 4 Feb 2025 15:31:06 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=infradead.org header.s=desiato.20200630 header.b="pW/rqMmx"; spf=none (imf28.hostedemail.com: domain of peterz@infradead.org has no SPF policy when checking 90.155.92.199) smtp.mailfrom=peterz@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1738683067; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=yUBMLdid6p8J2t+8TyqgXCNeWZFR2eWp9+2MIB84uUM=; b=213EoLBWo+NdCPL8GuX+9LH0tWcuFAU+pCplOtCtvXCurVXfgL6euzXYDK3wlikKaKy4YP KZHYfCRcDHiuBcpMOBED4/xr0MgSjTsQAAxobJ3iJnJTv865hgrl7M1fDeOMRRewbSpytr OXllR4Nm0VBVaRLMVYifVIxtnCzwaP8= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=infradead.org header.s=desiato.20200630 header.b="pW/rqMmx"; spf=none (imf28.hostedemail.com: domain of peterz@infradead.org has no SPF policy when checking 90.155.92.199) smtp.mailfrom=peterz@infradead.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1738683067; a=rsa-sha256; cv=none; b=6m2aJstYjYfRWEPhvZ6fFw13GBiwUq+dc0GT3Ga++O5tY9cugc9yE5lIE/IPgfLHe3g6G7 DcC4Q+H9ZrfBlqBP2/UQwJEszrQ70ETbW77U1xIc/0AwUOJnkxOJn4Y3JPpT7R+9SR/+gx ph9b1/p84Tx90ujjj806uClRpPyFVk4= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=desiato.20200630; 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=yUBMLdid6p8J2t+8TyqgXCNeWZFR2eWp9+2MIB84uUM=; b=pW/rqMmxFYkdQlFK2u4+ErsxWP 1mFDlujBrVq2RFV3eAodLz7/q5UBbw8EliGapJlOs+PTtFwEoRVsMaXnZ0qfI40krCQnFTU6g+lDs 0S44+5RESQX8KFWglq+LBWlv8HAFxmDvSqk0a+3tdFxnQZkBJd2YpYLUJxYbsrz+QoyhJ933xKrnc 3vIFA2CENAeqlz3vN0Xb5dISF/WqhGpaD91kt9PZtEhW5qUhCY9z/lDyqkKzQGqy5Wfohu7y5OQlD ypwQQub3R9I/F4NvWGx0GlY8SqdAqLZsJMxgiHx20aWYZW9lL1HjelJ7rRh5m1DmPSKpY5rLWSRX1 e+WijXiQ==; Received: from 77-249-17-89.cable.dynamic.v4.ziggo.nl ([77.249.17.89] helo=noisy.programming.kicks-ass.net) by desiato.infradead.org with esmtpsa (Exim 4.98 #2 (Red Hat Linux)) id 1tfKt3-0000000GLGl-2NoB; Tue, 04 Feb 2025 15:30:53 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id 280653002CE; Tue, 4 Feb 2025 16:30:53 +0100 (CET) Date: Tue, 4 Feb 2025 16:30:53 +0100 From: Peter Zijlstra To: Steven Rostedt Cc: linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org, Thomas Gleixner , Ankur Arora , Linus Torvalds , linux-mm@kvack.org, x86@kernel.org, akpm@linux-foundation.org, luto@kernel.org, bp@alien8.de, dave.hansen@linux.intel.com, hpa@zytor.com, juri.lelli@redhat.com, vincent.guittot@linaro.org, willy@infradead.org, mgorman@suse.de, jon.grimm@amd.com, bharata@amd.com, raghavendra.kt@amd.com, boris.ostrovsky@oracle.com, konrad.wilk@oracle.com, jgross@suse.com, andrew.cooper3@citrix.com, Joel Fernandes , Vineeth Pillai , Suleiman Souhlal , Ingo Molnar , Mathieu Desnoyers , Clark Williams , bigeasy@linutronix.de, daniel.wagner@suse.com, joseph.salisbury@oracle.com, broonie@gmail.com Subject: Re: [RFC][PATCH 1/2] sched: Extended scheduler time slice Message-ID: <20250204153053.GX7145@noisy.programming.kicks-ass.net> References: <20250131225837.972218232@goodmis.org> <20250131225942.365475324@goodmis.org> <20250201115906.GB8256@noisy.programming.kicks-ass.net> <20250201181129.GA34937@noisy.programming.kicks-ass.net> <20250201180617.491ce087@batman.local.home> <20250203084306.GC505@noisy.programming.kicks-ass.net> <20250203114537.6a30c7c0@gandalf.local.home> <20250204091613.GQ7145@noisy.programming.kicks-ass.net> <20250204075100.3fcbfda8@gandalf.local.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250204075100.3fcbfda8@gandalf.local.home> X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 140F5C0005 X-Stat-Signature: 7x7omd5ic5uu5a4okrsfwmj74tawd6k3 X-Rspam-User: X-HE-Tag: 1738683066-620996 X-HE-Meta: U2FsdGVkX1/Bhj3P8QQQuFj4Rz25I6PQwgXKWOp3MPJrwWlc6QzAw6sSxtmp92bxsxs64pKclYl8I0dr3XsuceXMkefXa07ampXxbjgYlmJrUJozp4mPms7Izm9e+d5a2uoxbWncwDCoKut6UJ9e249xkwPMH00a9hSHL4EZnC9mRwd1nHi/y5wvyWmNm2rARoSwzc1h24+APdt025yApYZ+z1O4slcpuj4sAYushLo2BzOIY0mvZffNfFEyPaoo0Ho5NhyBedgm8qcvf32j+nBve+9N3PAiA9ZHEOuGGKXsWLyioavKeL2RA64UMm8NZfP6nnvkfD/+SbOfIg599NXGEeu4KbMJ3oyR2QpCxTIEIcAweHhSdfeV2PmOkmw9r4ttT1J7nIDlSGJYGceOzBj7IVbxE0cGZRIhimEvAR/Vwr0Mt6sTLcoNhqg1f8aL0S+gwqN3MV/kiU/E93V5ctMYP73TqMSf/HSJ+LwPyXZVADAyZs6w2H1fOUC6jj4uDazFMk12BRXzniX+OLjL8EbYUfn1RRqlLGO0qr3h2LgxuNbETeXxGgviInwNI1X+KpGs4cArsxnr9fMytxLT2YscO5NoX/spJLZLcltFxVFyCJQrMUfaUA36+swpz4m1VOAjfgzGCTNsYvh42EfGrGVi3J/F6skRX2t0SdlS4gNMrbEgBVbx5nEbIOpuP5ADbyYPUwnroDi4Q05Kj0w5MsjDqKU59Mk7F21+83qOtl37WO3LWtbVzn/QqdrTxsEBuBRr3iml+w/4pL0tZpAnXuIr3IP8i6LmTGshDNhw9VzTrh7H4UX3n3yOAy8AcIzodQjfPjSyAPpVTRatDzNy27KAQv4oIIukUv8evfLsJosCB32oBIXO0sRKLkop8JNPLpWHV/6LC9XfIXwJze/gsxGUYbkmwUQPhlfIYi7VnGLY3rOR4c83l6px452/a4680W/GKVjYqXmPYbnZH6Z /kc0/cwB oI2bZ0eEuqXboMjkhi4NH9NNBFu1hooDCF8jA3u3ugF8qdSClYGidNZZNtqI3uiHLPJq0xCBMGPA++dkks64hVFW+JxK4RS45mr2zkzftk0RIVJQ3P4iSkJB8P7SZ9ukRZj7RCNFQq0LZbiGH2EdYTHQ8EylwEgfxdlCP/4iEQBZs+X1rEKn6UtCS3dqPzFoLqPoklEAFv3U4FBko8vVB/VUZV3hcrj2jh8whHlIFhOtEXGga4q6KFcBe0+XyvAMOnBlBFNIyd0oLEbML9nW+27D+/YO9McsYnwcC8w0eaoIFuhKMdAjBSRWQhQI5RMLk8lbh X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Tue, Feb 04, 2025 at 07:51:00AM -0500, Steven Rostedt wrote: > On Tue, 4 Feb 2025 10:16:13 +0100 > Peter Zijlstra wrote: > > > And yes, you can still use the whole 'delay preemption' hint for RT > > tasks just fine. Spinlocks isn't the only thing. It can be used to make > > any RSEQ section more likely to succeed. > > > > > > > Patch 2 changes that to do what you wrote the last time. It has a max wait > > > time of 50us. > > > > I'm so confused, WTF do you then need the lazy crap? > > > > You're making things needlessly complicated again. > > Do we really want to delay an RT task by 50us? If you go back and reread that initial thread, you'll find the 50us is below the scheduling latency that random test box already had. I'm sure more modern systems will have a lower number, and slower systems will have a larger number, but we got to pick a number :/ I'm fine with making it 20us. Or whatever. Its just a stupid number. But yes. If we're going to be doing this, there is absolutely no reason not to allow DEADLINE/FIFO threads the same. Misbehaving FIFO is already a problem, and we can make DL-CBS enforcement punch through it if we have to. And less retries on the RSEQ for FIFO can equally improve performance. There is no difference between a 'malicious/broken' userspace consuming the entire window in userspace (50us, 20us whatever it will be) and doing a system call which we know will cause similar delays because it does in-kernel locking.